Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installed directly from VCS

[Philip Kaludercic]

Tim Cross <theophilusx@gmail.com> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> - The ability to install a package directly from source using
>>>   `package-vc-fetch' (aliased to `package-checkout').  This
>>>   functionality is ideally VC generic.
>>>
>>> - The ability to update a package using `package-upgrade'[0]
>>>
>>> - Package metadata can either be inferred from the package URL (see
>>>   `package-vc-heusitic-alist') or via explicit hints from an ELPA
>>>   server.  I plan to add the necessary features to GNU and NonGNU ELPA
>>>   in time so that the heuristics can be avoided.
>>>
>>> - The ability to (i) contact, (ii) send bug reports and (iii) patches
>>>   (using the new `vc-patch-prepare') to package maintainers.
>>
>> Sounds like great functionality, but I wonder whether the security
>> implications have been discussed?  Today, we use GNU ELPA as a filter of
>> sorts and people rely on code there not being compromised.
>>
>> I assume "hints from an ELPA server" is basically a list of links to git
>> repositories?  If that's the case, then we may well end up with pointing
>> users towards repos that have been compromised.
>>
>> If we don't have such a list, then adding the basic functionality sounds
>> useful anyway -- that is, allowing users to say `M-x
>> package-install-from-repo' or something and then they type in the URL of
>> that repo -- that's fine, and leaves the security implications to the
>> user (where they already are today for people that install from external
>> repos).
>>
>> But if we list these repos in `M-x list-packages', that's a very
>> different issue.
>
>
> I think it is very dangerous to suggest there is ANY security here, even
> with GNU ELPA packages.
>
> - There is no formal security review of packages
> - There is no review before packages are updated. If a repository is
>   compromised and that compromise has not been detected, an update can
>   still occur and introduced compromised code into GNU ELPA. 
>
> Far better to just educate users that ANY package they install could
> contain malicious code.

Is this feasible?  Should this be a (long-)term goal, or will ELPA
always be a "use at your own risk" kind of thing?

Also, could you clarify what you mean by "formal security review"?