Re: Security issues in Emacs packages

[Jean Louis <bugs@gnu.support>]

* Tim Cross <theophilusx@gmail.com> [2020-11-27 01:21]:
> 
> 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).

Before some days or weeks we discussed this in a different thread, not
this mailing list. I think emacs-devel. Authors are by convention
writing their version numbers in their packages aligned to the Emacs
Lisp manual section on Packaging. MELPA is injecting their version
they are taking from git as commit number.

Thus MELPA does not use author's version number. It should be obvious
from package-list-packages that same version of the package in GNU
ELPA does not have same version number in MELPA, that is confusion
created for no good reason but to minimize programming efforts at
MELPA. 

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

Either way it could be good and depends what does the distribution
center do. If they are auditing packages and making sure of security
or are they just packaging without any audit. Maybe distribution
center verifies all PGP signatures and we may trust such center, maybe
not.

The OpenBSD software audits packages. It cannot ever be fully secure
but for base system one can rest assured that developers have put a
lot of effort in making it secure. Trust with users is then created
based on the relation and background of the OS distribution.

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

I wish that too.