emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installe


From: Tim Cross
Subject: Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installed directly from VCS
Date: Sun, 09 Oct 2022 06:02:12 +1100
User-agent: mu4e 1.9.0; emacs 29.0.50

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]