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

[Philip Kaludercic <philipk@posteo.net>]

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.

It seems to me that fetching a package from source is no more dangerous
than fetching a tarball, seeing as the tarball is automatically
generated from the repository.

But I might be mistaken, in which case I'd be interested in what should
be done to improve security.

> I assume "hints from an ELPA server" is basically a list of links to git
> repositories?  

The hints would be an entry in the package property list consisting of
the following items:

    (VC-BACKEND REPOSITORY DIRECTORY BRANCH)

Packages with either this metadata or that are caught by the heuristic
are automatically proposed as completion options when invoking
`package-vc-fetch'.  Of course it is also possible to give an arbitrary
URL, but at that point you should know what you are doing.

>                If that's the case, then we may well end up with pointing
> users towards repos that have been compromised.

Just so that we are on the same page, what are we talking about when
using the term "compromised"?  In what sense would this not affect a
package that we fetch directly from source but not a tarball?

> 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).

Yes.

> But if we list these repos in `M-x list-packages', that's a very
> different issue.

No, the list-packages would still only list packages that are listed in
the package archive + packages that have already been installed
using `package-vc-fetch'.