Re: Security issues in Emacs packages

[Tim Cross]

Greg Minshall <minshall@umich.edu> writes:

> Tim,
>
>> 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).
>
> if MELPA's release procedure prevented two separate releases of version
> 1.2.3 of package xYandZ from being released, wouldn't that obviate the
> requirement for George to give me signatures?  that was my thought as to
> why a signed (MELPA, version number, package name) would be enough.
> (i've no idea if MELPA's procedures would actually conform to my
> "requirement".)
>

Possibly, but I'm not sure it does/can. From my limited understanding,
the version number is determined by the git tag (for stable packages - I
think the date is used for unstable). This is as it should be as it
should be the package maintainer who controls the version number, not
the packaging service (especially for maintainers who use semantic
versioning where the version number actually conveys information about
the package).

At the end of the day, this is essentially a supply chain problem. To
really have confidence, you need confidence in the whole supply chain,
not just the distribution centre.

Personally, I wish both GNU and Melpa had adopted a push mechanism for
package release. Something similar to npmjs.com where the package
author/maintainer would submit a signed package (publish) to the
repository. This would make it producers of the package code we trust,
not the distribution center (repository). Main downside with that
approach is you would also need a reliable mechanism for retrieving the
public keys (there would be a lot more of them to manage). I also think
this would be a model that is a lot easier to scale (something I think
GNU will have problems with under their current model.

--
Tim Cross