Re: Security issues in Emacs packages

[Tim Cross]

Greg Minshall <minshall@umich.edu> writes:

> Tim,
>
>> I think you missed my point. There is no benefit in MELPA adopting
>> signed packages because there is no formal code review and no vetting
>> of the individuals who submit the code.
>
> it occurs to me there might be one benefit: if George, whom you trust,
> says, "I've been running version 1.2.3 of package xYandZ from MELPA and
> i have a lot of confidence in it", then if you find that version of that
> package with a trusted MELPA signature, you maybe know that you and
> George are running the same software.  i.e., it helps with the "web of
> trust" (if people still talk of that).
>
> (so, the requirement for this is not audited packages, but a solid,
> "secure", release procedure by MELPA.)
>

It could, but to get that level of assurance, you not only have to
verify the signature is valid (something which is automated if enabled),
you also need to verify that both packages have the exact same
signature, which is pretty much a manual process. So in addition to
telling you the version number, George would also need to communicate
the signature and that would need to be compared to the signature you
have in the package you downloaded to know that the packages are in fact
the same (you cannot rely on version numbers for any real verification).

Signatures are a good thing and MELPA should implement them. However,
what they are really useful for is ensuring the package you have
downloaded has not been modified since it was created and signed.

--
Tim Cross