GNU bug report logs - #19479
Package manager vulnerable

Previous Next

Full log

Message #137 received at 19479 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: 19479 <at> debbugs.gnu.org
Subject: Re: bug#19479: Package manager vulnerable
Date: Mon, 7 Sep 2020 10:19:13 -0700

Kelly Dean <kelly <at> prtime.org> writes:

> Stop distributing elpa-key signatures of packages, since they're
> superfluous if you have package hashes in archive-contents and have
> elpa-key signatures of archive-contents, and you already have the
> latter.

I disagree with this part.

We should continue signing packages _at least_ until such a time that
there is likely to be zero users left who are using an Emacs version
without support for checking package hashes.

> Optional alternative timestamp handling, as Ivan pointed out that
> Debian does (at least sometimes): Instead of expiring archive-contents
> after some limit configured in Emacs, put an explicit expiration date
> in it. Personally, I don't like server-supplied expiration dates, kind
> of for a similar reason that RMS doesn't like server-supplied
> Javascript, or maybe just because I have too many irritating memories
> of expired SSL certs.

Is there any reason not to support both?  Package archives could decide
if they want to use this functionality or not, as could users.

> One more feature: include in each version of archive-contents a hash (and
> length) of the previous version of that file. This isn't necessary for
> preventing any of the vulnerabilities above, but it's easy insurance that
> slightly mitigates the disaster if the metadata signing key is compromised. It's
> pointless unless both the above problems are fixed, so it makes sense to put it
> here.

Does anyone understand how this would improve security in our case?
AFAIU, it can help with APT since they support distributing package
metadata in several files.  ELPA uses only one file, so I'm not sure it
would make much of a difference?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.