GNU bug report logs -
#19479
Package manager vulnerable
Previous Next
To reply to this bug, email your comments to 19479 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Thu, 01 Jan 2015 12:40:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Kelly Dean <kelly <at> prtime.org>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 01 Jan 2015 12:40:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Ivan Shmakov requested that I send this message to the bug list.
For details, see my message with subject ⌜Emacs package manager vulnerable to replay attacks⌝ to emacs-devel on 30 Dec 2014:
https://lists.gnu.org/archive/html/emacs-devel/2014-12/msg02319.html
Executive summary to fix the vulnerabilities:
0. Include a hash and length of each package's content in the package's record in archive-contents, rather than only including the package name and version number in that file as Emacs currently does. Barf if a package hash doesn't verify, regardless of whether any signatures verify.
(Length technically not necessary, but still generally useful, e.g. if there's a length mismatch then you know there's a content mismatch and you don't have to bother checking the hash.)
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.
1. Include a timestamp of archive-contents in that file itself (so that the signature in archive-contents.sig depends on the timestamp, so that the timestamp can't be forged), and have Emacs ignore any new archive-contents that's older than the latest valid one that Emacs has already seen or is older than some specified limit. One thing I forgot to mention in my original message: have Emacs signal a warning if it ever sees an archive-contents dated in the future, which indicates misconfiguration of the client or server (or of course, some kind of mischief).
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.
Ivan suggested maybe filing those as separate bug reports, but it's pointless to fix either of them unless both are fixed, so it makes more sense to include them together.
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.
BTW, check whether Emacs is vulnerable to endless-data attack. (I haven't.) If it is, then the length field mentioned above (which is a good idea in any case) will assist in early detection of this attack. This belongs here because... well no it doesn't, but I don't want to file a separate bug report for it because the report would be bogus if it turns out Emacs isn't vulnerable, and I've already filled my bogusness quota for the week.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Sun, 04 Jan 2015 20:01:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 19479 <at> debbugs.gnu.org (full text, mbox):
> For details, see my message with subject ⌜Emacs package manager vulnerable
> to replay attacks⌝ to emacs-devel on 30 Dec 2014:
> https://lists.gnu.org/archive/html/emacs-devel/2014-12/msg02319.html
AFAICT, this vulnerability also applies to the way GNU packages are
distributed in ftp.gnu.org (i.e. as a tarball plus a .sig file).
Is that right?
> Executive summary to fix the vulnerabilities:
Another way to attack the problem is to include the file name along with
its content in "the thing that gets signed".
I.e. the signature shouldn't apply to the output of "cat <foo>" but to
the output of "echo <foo>; cat <foo>".
This way an attacker can't take <vulnerable>.tar along with
<vulnerable>.tar.sig and send them off as <safe>.tar along with
<safe>.tar.sig.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Mon, 05 Jan 2015 01:13:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 19479 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier wrote:
> AFAICT, this vulnerability also applies to the way GNU packages are
> distributed in ftp.gnu.org (i.e. as a tarball plus a .sig file).
>
> Is that right?
Yes, because there are no hashes in, or signatures on, http://ftp.gnu.org/find.txt.gz or http://ftp.gnu.org/ls-lrRt.txt.gz
They used to do it right; see
http://ftp.gnu.org/before-2003-08-01.md5sums.asc
But it looks like they stopped.
Having to redo a huge monolithic metadata file whenever any data file changes is inefficient; it's more efficient for the metadata for each directory to just have the hash of each file in the directory and the hash of the metadata of each subdirectory, like Git does. But either way will prevent package replay attacks.
>> Executive summary to fix the vulnerabilities:
>
> Another way to attack the problem is to include the file name along with
> its content in "the thing that gets signed".
> I.e. the signature shouldn't apply to the output of "cat <foo>" but to
> the output of "echo <foo>; cat <foo>".
>
> This way an attacker can't take <vulnerable>.tar along with
> <vulnerable>.tar.sig and send them off as <safe>.tar along with
> <safe>.tar.sig.
If filenames include version numbers and the version numbers are never reused, then your solution does prevent package replay attacks. Since Emacs packages already include a Version header (and the package name), you could actually do your proposed verification using that header, without changing the way signatures are currently made, which is a solution I addressed in my original emacs-devel message.
But having a list of hashes of all the packages (and even better, chaining together all the versions of that list) makes changes to any package more conspicuous, which makes the attacker's job harder, as I explained. And if you do that, then the elpa key no longer needs to sign individual packages at all. Git, Fossil, and Debian's apt-get use hash lists, and Git and Fossil also chain together the lists, so there's good precedence. Both are simple to do for Emacs: in the archive-contents file, include the hash of each package and the hash of the previous version of archive-contents.
But remember, none of the above prevents metadata replay attacks. If the user himself is specifying the metadata (e.g. you manually request Emacs 24.4 because you know that's the latest version), then verification to prevent metadata replay attacks isn't the computer's job. But when the user just says to update some package(s) to the latest version, without specifying the version, then it is the computer's job. For this, put a timestamp of the archive-contents file into the file itself.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Mon, 05 Jan 2015 02:17:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 19479 <at> debbugs.gnu.org (full text, mbox):
> If filenames include version numbers and the version numbers are never
> reused,
The ELPA system in general does not enforce that. But the GNU ELPA
scripts do, and other ELPA servers work in a way that should generally
make sure this is also the case.
> then your solution does prevent package replay attacks. Since Emacs
> packages already include a Version header (and the package name), you could
> actually do your proposed verification using that header, without changing
> the way signatures are currently made, which is a solution I addressed in my
> original emacs-devel message.
Indeed, I realized this just after I sent my message.
So we can fix this problem simply by changing package.el so as to check
that the name&version of the downloaded file match the name&version
contained therein.
Patch welcome.
> But remember, none of the above prevents metadata replay attacks. If the
> user himself is specifying the metadata (e.g. you manually request Emacs
> 24.4 because you know that's the latest version), then verification to
> prevent metadata replay attacks isn't the computer's job. But when the user
> just says to update some package(s) to the latest version, without
> specifying the version, then it is the computer's job. For this,
> put a timestamp of the archive-contents file into the file itself.
Agreed. It should be fairly easy to add a timestamp in there without
causing any backward incompatibility.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Tue, 06 Jan 2015 06:40:03 GMT)
Full text and
rfc822 format available.
Message #17 received at 19479 <at> debbugs.gnu.org (full text, mbox):
Richard Stallman wrote:
> What do we need to do on ftp.gnu.org to avoid these dangers?
It depends on what you expect the user's responsibility to be.
If you expect him to know the latest version number of a package (without relying on the gnu.org webserver to find out, in case it's compromised), and you expect him to manually verify that his download is the latest version (in addition to verifying the signature, of course), and you give him the ability to do this by always including both the name and the version number in your packages (so far as I'm aware, you already do) and never re-using version numbers (I think you're ok here too), then you have no problem, so there's nothing you need to do.
Otherwise, the problems and solution are the same as for package distribution systems in general, as detailed at
https://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html
https://www.cs.arizona.edu/stork/packagemanagersecurity/otherattacks.html
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Wed, 07 Jan 2015 04:28:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 19479 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> If you expect him to know the latest version number of a package
> (without relying on the gnu.org webserver to find out, in case
> it's compromised),
It is normal for users to find the latest version based on gnu.org.
So we don't expect that.
> and you expect him to manually verify that his download is the
> latest version (in addition to verifying the signature, of
> course),
The file name has the version in it.
So it seems we have a problem to fix. Would you like to help
us fix it?
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
Use Ekiga or an ordinary phone call.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Thu, 08 Jan 2015 03:33:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 19479 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Stefan Monnier wrote:
> > If filenames include version numbers and the version numbers are never
> > reused,
>
> The ELPA system in general does not enforce that. But the GNU ELPA
> scripts do, and other ELPA servers work in a way that should generally
> make sure this is also the case.
But having security rely on that makes it easier than necessary to accidentally open a window of vulnerability by failing to enforce that constraint. It's a brittle solution.
>> then your solution does prevent package replay attacks. Since Emacs
>> packages already include a Version header (and the package name), you could
>> actually do your proposed verification using that header, without changing
>> the way signatures are currently made, which is a solution I addressed in my
>> original emacs-devel message.
>
> Indeed, I realized this just after I sent my message.
> So we can fix this problem simply by changing package.el so as to check
> that the name&version of the downloaded file match the name&version
> contained therein.
> Patch welcome.
Ok, but as I explained in my original message, that solution still makes the attacker's job easier than necessary in some cases. Verifying the hash is a more robust solution than verifying the version number, so my patch below verifies the hash.
This is forward compatible. You can install this now and start putting archive-contents with hashes on elpa (and melpa and marmalade), and old clients will simply ignore the hashes and operate as usual.
BTW, one happy side effect of properly fixing this vulnerability is eliminating melpa's incentive to mangle package version numbers (they're mangled apparently to deal with the problem of package maintainers reusing version numbers).
> It should be fairly easy to add a timestamp in there without
> causing any backward incompatibility.
Unfortunately, I don't see how to add timestamps to archive-contents without breaking old clients, so the metadata replay vulnerability will have to remain open until you decide how to handle the compatibility problem. My patch here only fixes the package replay vulnerability.
[package-replay-vuln.patch (text/x-diff, inline)]
--- emacs-24.4/lisp/emacs-lisp/package.el
+++ emacs-24.4/lisp/emacs-lisp/package.el
@@ -314,6 +314,11 @@
(defvar package--default-summary "No description available.")
+(defvar package-hashfun 'sha256 "Function for secure hashing.")
+
+(defvar package-acceptable-hashfuns '(sha256)
+ "Past and current `package-hashfun' functions that are still secure.")
+
(cl-defstruct (package-desc
;; Rename the default constructor from `make-package-desc'.
(:constructor package-desc-create)
@@ -843,6 +848,20 @@
(epg-context-result-for context 'verify)))
good-signatures))))
+(defun package--check-size (pkg-desc)
+ (eq (cdr (assoc :size (package-desc-extras pkg-desc)))
+ (pcase (package-desc-kind pkg-desc)
+ (`single (string-bytes (buffer-string)))
+ (`tar (buffer-size)) ; Because insert-file-contents mangled the literal
+ (kind (error "Unknown package kind: %s" kind)))))
+
+(defun package--check-hash (pkg-desc)
+ (let* ((x (cdr (assoc :hash (package-desc-extras pkg-desc))))
+ (hashfun (car x)) ; Avoid Git's shortsightedness
+ (hash (cadr x)))
+ (and (memq hashfun package-acceptable-hashfuns)
+ (string= hash (secure-hash hashfun (current-buffer))))))
+
(defun package-install-from-archive (pkg-desc)
"Download and install a tar package."
(let* ((location (package-archive-base pkg-desc))
@@ -859,6 +878,10 @@
(unless (eq package-check-signature 'allow-unsigned)
(error "Unsigned package: `%s'"
(package-desc-name pkg-desc)))))
+ (unless (package--check-size pkg-desc)
+ (error "File size not correct: %s" (package-desc-name pkg-desc)))
+ (unless (package--check-hash pkg-desc)
+ (error "Failed to verify hash: %s" (package-desc-name pkg-desc)))
(package-unpack pkg-desc))
;; Here the package has been installed successfully, mark it as
;; signed if appropriate.
@@ -1172,7 +1195,10 @@
(package--prepare-dependencies
(package-read-from-string requires-str)))
:kind 'single
- :url homepage))))
+ :url homepage
+ :size (string-bytes (buffer-string))
+ :hash (list package-hashfun
+ (secure-hash package-hashfun (current-buffer)))))))
(declare-function tar-get-file-descriptor "tar-mode" (file))
(declare-function tar--extract "tar-mode" (descriptor))
@@ -1184,7 +1210,10 @@
(let* ((dir-name (file-name-directory
(tar-header-name (car tar-parse-info))))
(desc-file (package--description-file dir-name))
- (tar-desc (tar-get-file-descriptor (concat dir-name desc-file))))
+ (tar-desc (tar-get-file-descriptor (concat dir-name desc-file)))
+ (size (buffer-size tar-data-buffer))
+ (hash (list package-hashfun
+ (secure-hash package-hashfun tar-data-buffer))))
(unless tar-desc
(error "No package descriptor file found"))
(with-current-buffer (tar--extract tar-desc)
@@ -1196,7 +1225,8 @@
(error "Can't find define-package in %s"
(tar-header-name tar-desc))
(apply #'package-desc-from-define
- (append (cdr pkg-def-parsed))))))
+ (append (cdr pkg-def-parsed)
+ (list :size size :hash hash))))))
(setf (package-desc-kind pkg-desc) 'tar)
pkg-desc)
(kill-buffer (current-buffer))))))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Thu, 08 Jan 2015 03:45:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 19479 <at> debbugs.gnu.org (full text, mbox):
I appreciate the spirit of wanting to provide a patch, but unless you
have changed your position on the Emacs copyright assignment, I don't
see that this patch can be used by Emacs.
(Ref: http://debbugs.gnu.org/14492#19)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Thu, 08 Jan 2015 05:31:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 19479 <at> debbugs.gnu.org (full text, mbox):
Glenn Morris wrote:
> I appreciate the spirit of wanting to provide a patch, but unless you
> have changed your position on the Emacs copyright assignment, I don't
> see that this patch can be used by Emacs.
I did do what you requested: submit a bug report, but not a patch. But this isn't just a bug; it's a security vulnerability, and Stefan invited me to submit a patch to fix it. So then I did.
Regarding the copyright issue, please don't conflate two separate issues like your copyright clerk tried to.
The first issue is: does the FSF want any more public domain code in Emacs than is already there? The answer is ‟no”, as explained by Donald R Robertson III, your copyright clerk, on February 19, 2013. When explaining why the FSF wouldn't accept my PD code, he wrote, ‟It really is more beneficial for our enforcement efforts if we get the work assigned instead of 'disclaimed'. We will only accept a disclaimer instead of an assignment in particular circumstances.”
Of course, he's right; PD code isn't useful for your enforcement efforts, but it's absurd to say it's an issue for my patches, which even including this latest one, amount to no more than a few parts per million of the Emacs code base. Obviously it doesn't hurt your efforts; no copyright judge is going to care if Emacs has a few lines of Hamlet or any other PD information in it. The judge will let you sue people for GPL violations just the same.
Anyway, the first issue is clear: new PD code is unwelcome in Emacs. Emacs is your project, not mine, so regardless of how silly I think your exclusion of PD code is, I abided (and still abide) by your wishes. I submitted this patch because Stefan invited me to. Maybe Stefan just forgot that you asked me not to submit any more patches, but I assumed he invited this patch because a security vulnerability counted as a ‟particular circumstance” that your copyright clerk mentioned.
The second issue is: is my code in the public domain? The answer is ‟yes”; the author of SQLite says that's PD, and it is, the author of Qmail says that's PD, and it is, and I'm simply doing the same thing they are. My code is in the public domain. If you want, I can PGP-sign and publish on my website a statement that my patches are PD, even though that's more than the authors of SQLite and Qmail deemed necessary for their code.
Your clerk wrote, ‟placing a work in the public domain is difficult/may not be possible”. But that's obviously false, as proven by his statement that you do (sometimes) accept disclaimers, and as proven by the general legal acceptance of other people's statements that their work is PD, including highly respected authors such as Richard Hipp.
It's clear that the second issue is not an issue, especially in the United States, which is where I am, and the only purpose served by the FSF bringing it up is clouding the first issue, which is the only real issue.
I recommend not rejecting a patch to fix a security vulnerability just for the sake of keeping 29 lines of new PD code out of Emacs. If it really is too much PD code, then I recommend deleting feedmail.el (PD) to compensate.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Thu, 08 Jan 2015 11:42:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 19479 <at> debbugs.gnu.org (full text, mbox):
BTW, Stefan mentioned (see bug #19536) that you don't use package-x for elpa.gnu.org, and instead use some other scripts, so it just occurred to me that you might not immediately notice that my patch not only verifies hashes, but also generates them, so there's nothing extra you need to do.
Just use package-upload-file from package-x.el, and it will automatically add the appropriate entry (including hash) for the package to the archive-contents file.
Apply the fix for bug #19536 if you want package-upload-file to correctly add tar files to the archive's package directory. (It already correctly adds single-file packages.)
GNU elpa, Melpa, and Marmalade can start using the new archive-contents now. Old clients will still work fine, and simply ignore the hashes. New clients will verify them.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Thu, 08 Jan 2015 14:40:03 GMT)
Full text and
rfc822 format available.
Message #35 received at 19479 <at> debbugs.gnu.org (full text, mbox):
> of PD code is, I abided (and still abide) by your wishes. I submitted this
> patch because Stefan invited me to. Maybe Stefan just forgot that you asked
> me not to submit any more patches,
Indeed, that's the case. You're one of the very rare oddballs who can't
be bothered to sign a trivial document to get this out of the way, but
for the life of me, I can't remember the names of the handful of
oddballs, so I keep repeating this error.
> but I assumed he invited this patch because a security vulnerability
> counted as a ‟particular circumstance” that your copyright
> clerk mentioned.
Emacs is full of vulnerabilities and has barely started using encryption
technology to try and eliminate some of them, so no, it's definitely not
"special" in this sense. And in any case the "special"ness usually
doesn't refer to the usefulness of the code but rather to the fact that
it'd be difficult to get this code some other way (i.e. it's both
important/useful code and it'd take a while to rewrite it).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Thu, 08 Jan 2015 21:14:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 19479 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier wrote:
> You're one of the very rare oddballs who can't
> be bothered to sign a trivial document to get this out of the way
That's not true. I offered to sign a document saying my work is PD.
The following say that's an option:
http://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/disclaim.manual
http://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/disclaim.changes.manual
http://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/disclaim.program
The copyright clerk declined my offer.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Fri, 09 Jan 2015 02:38:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 19479 <at> debbugs.gnu.org (full text, mbox):
>> You're one of the very rare oddballs who can't
>> be bothered to sign a trivial document to get this out of the way
> That's not true. I offered to sign a document saying my work is PD.
I didn't mean "a trivial document" in the sense "any trivial document",
but rather "the particular trivial document that everybody else signed".
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Fri, 09 Jan 2015 07:01:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 19479 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Stefan Monnier wrote:
>>> You're one of the very rare oddballs who can't
>>> be bothered to sign a trivial document to get this out of the way
>> That's not true. I offered to sign a document saying my work is PD.
>
> I didn't mean "a trivial document" in the sense "any trivial document",
> but rather "the particular trivial document that everybody else signed".
The FSF doesn't have just one document for contributors; it has multiples, three of which I linked to in my previous message, and at least two more that are for assignment instead of disclaimer (one for only past contributions, and one for past and future contributions).
More than two years ago, I asked the copyright clerk to send me a disclaimer form to sign. He refused. This is the _only_ reason that the FSF doesn't already have a disclaimer on file for me.
If I sign an assignment document (i.e. saying that I own intellectual property for my work and that I'm assigning that ownership to the FSF), then I would just be committing perjury, because I don't own PD works. Nothing I sign can remove anything from the public domain.
Again, please don't conflate two separate issues:
0. The FSF is refusing new PD code in Emacs. (I would be happy to learn that I'm mistaken about this.)
1. My code is PD. (In case the FSF disputes this fact, I'm attaching a signed document to establish it.)
Because the clerk refused to send me anything to sign that would establish #1 to the FSF's satisfaction, today I printed, signed, and scanned the attached document based on the disclaimer forms the FSF has published, to make it abundantly clear that my work is PD and that the FSF is free to use my work with no legal restrictions whatsoever.
I'm also CCing it to assign <at> gnu.org, even though at this point I assume the clerk will come up with some excuse to reject it.
If the clerk feels this doesn't make #1 clear enough, then please tell me what needs to change. Even better, send me the exact disclaimer form you want me to sign, which I asked for in the first place.
I repeat: nothing I sign can remove anything from the public domain. So nothing I sign can assign to the FSF ownership of my work; if assignment is what the FSF insists on, then it's asking for the impossible.
The attached document is to establish #1 to the FSF's satisfaction. The FSF alone has the ability to solve #0; it has nothing to do with me.
Here's the text of the attached document:
This document is derived from the following sources:
http://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/disclaim.manual
http://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/disclaim.program
I, Kelly Dean, American citizen and resident, hereby disclaim all patent, copyright, and all other forms of intellectual property ownership of and interest in all of my patches, software manuals, software programs, source code, documentation, revisions thereof, and all other works, past, present, and future, that I sent or will send to the emacs-devel <at> gnu.org or bug-gnu-emacs <at> gnu.org mailing lists, to 19479 <at> debbugs.gnu.org, to any other mailing list or email address at gnu.org or any subdomain thereof, or to any developer or maintainer of GNU Emacs or any other GNU software, from my previous (no longer active) email address of kellydeanch <at> yahoo.com, my current email address of kelly <at> prtime.org, or any other email address.
I affirm that I have no other proprietary interest that would undermine this release, and will do nothing to undermine it in the future. I represent that all of the aforementioned works are my own and not a copy of someone else's work, except where sources are cited. Patches include citations and partial copies of the works to which the patches apply.
I created all of the works exclusively on my own time. They are not works made for hire, and there's no educational institution, employer, or any other organization or person who owns them. I do not have any agreement with any person or organization saying he or it owns programs I write, and I did not have any such agreement when I created any of the aforementioned works.
All of the works are permanently and irrevocably in the public domain.
Kelly Dean
kelly <at> prtime.org
January 8, 2015
[gnu-disclaimer.pdf (application/pdf, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Fri, 09 Jan 2015 15:18:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 19479 <at> debbugs.gnu.org (full text, mbox):
> 1. My code is PD. (In case the FSF disputes this fact, I'm attaching
> a signed document to establish it.)
It can't be PD. You're simply confused about it. It will only be PD 75
years after your death (or something like that). Until then, all you
can do is sign paperworks, and currently for Emacs contributions we
require this paperwork to be a copyright assignment rather than
a disclaimer.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Fri, 09 Jan 2015 15:30:03 GMT)
Full text and
rfc822 format available.
Message #50 received at 19479 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:
>> 1. My code is PD. (In case the FSF disputes this fact, I'm attaching
>> a signed document to establish it.)
>
> It can't be PD. You're simply confused about it. It will only be PD
> 75 years after your death (or something like that).
If I remember correctly, if he is living in the U.S.A. and registers a
specific work with the U.S. copyright office as being released by him
into the public domain, then the work will indeed be in the public
domain within the U.S.A. We need to bother with more than the U.S.A.,
however, and one can only register specific works which means it is not
possible to register them before they are even created.
--
David Kastrup
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Fri, 09 Jan 2015 20:07:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 19479 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier wrote:
>> 1. My code is PD. (In case the FSF disputes this fact, I'm attaching
>> a signed document to establish it.)
>
> It can't be PD. You're simply confused about it. It will only be PD 75
> years after your death (or something like that). Until then, all you
> can do is sign paperworks, and currently for Emacs contributions we
> require this paperwork to be a copyright assignment rather than
> a disclaimer.
GNU's own website says it can be PD. The documents at the three links I sent you start with:
⌜I'd like to ask you to sign a disclaimer for the manual, thus putting it in the public domain.⌝
⌜I'd like to ask you to sign a disclaimer for the program, thus putting it in the public domain.⌝
⌜I'd like to ask you to sign a disclaimer for your changes, thus putting them in the public domain.⌝
Notice the ⌜thus putting them in the public domain⌝.
Also, do you claim that SQLite is not PD? The author, Richard Hipp, says it's PD, and the many millions of users of SQLite, including many major companies with lots of copyright lawyers, accept the legal fact that it's PD. And Richard Hipp is not dead.
Also, do you claim that feedmail.el is not PD? The first lines of it are:
;;; feedmail.el --- assist other email packages to massage outgoing messages
;;; This file is in the public domain.
;; This file is part of GNU Emacs.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Fri, 09 Jan 2015 20:25:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 19479 <at> debbugs.gnu.org (full text, mbox):
I must say, that it was not my impression that disclaimers were not
accaptable for Emacs. Only that the FSF does not offer a "past and
future" option for disclaimers like it does for assignments, so a new
disclaimer would have to be completed for every new change. I thought
this was not worth bothering with, so I advised you not to send more patches.
But I certainly don't know, I just go with whatever assign <at> gnu says.
I don't see much point discussing this on emacs-devel. None of us are
lawyers so our opinions are pretty irrelevant. We need to wait and see
what assign <at> gnu says.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Fri, 09 Jan 2015 20:33:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 19479 <at> debbugs.gnu.org (full text, mbox):
Glenn Morris wrote:
> I must say, that it was not my impression that disclaimers were not
> accaptable for Emacs. Only that the FSF does not offer a "past and
> future" option for disclaimers like it does for assignments, so a new
> disclaimer would have to be completed for every new change. I thought
> this was not worth bothering with, so I advised you not to send more patches.
PS but yes, for a non-trivial security issue like 19479 it did seem
worth it to me, so I was on the verge of saying, would you be willing to
complete a disclaimer for this change. But then Stefan said disclaimers
were not viable, so I didn't bother to say it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Fri, 09 Jan 2015 21:02:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 19479 <at> debbugs.gnu.org (full text, mbox):
David Kastrup wrote:
> We need to bother with more than the U.S.A.,
> however
Does this mean that all PD code, including feedmail.el, needs to be deleted from Emacs? The authors of that code don't satisfy the not-USA countries' supposed requirements of having been dead for 75 years or so.
> one can only register specific works which means it is not
> possible to register them before they are even created.
Ouch. Unfortunately, I've been busy and have had no time for proper preparation, so I'll parry your blow next week. ;-)
Anyway, my patch that Glenn objected to was created in the past, not the future, so at least that one is ok.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Fri, 09 Jan 2015 21:51:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 19479 <at> debbugs.gnu.org (full text, mbox):
I wrote:
> Anyway, my patch that Glenn objected to was created in the past, not the future, so at least that one is ok.
Actually my future patches are ok too.
http://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/disclaim.program says:
⌜Digital Stimulation Corporation hereby disclaims all copyright interest
in the program "seduce" (a program to direct assemblers to make passes at
compilers under GNU Emacs) written by Hugh Heffner, including both the
present version of the program and his/her future changes and
enhancements to it.⌝
Notice the disclaimer applies to future work. Which means my disclaimer applying to future work is effective.
If the FSF thinks it has to register those PD works (which would be absurd, but absurdity has never stopped lawyers), that's a separate issue from the one-time disclaimer (covering past and future work) that the disclaim.program file shows that the FSF does accept. It isn't any extra burden for the FSF compared to assignment, since obviously the FSF can only register intellectual property ownership of assigned works after those works are created too, so the FSF still has to constantly (or annually or whatever) send new paperwork to the copyright office even for contributors who have signed an assignment form. IOW, Stefan keeps the lawyers a lot busier than I do. ;-)
But again, even if for some weird reason the lawyers think my disclaimer for future work isn't effective, it certainly is effective for my previous work, including my patch for bug #19479. (And if it isn't, then they're welcome to point out what's wrong with it, and send me a disclaimer form that _is_ effective, which I asked for already in 2012). If necessary, I can re-date and re-sign it in the future to cover new work, which is fine since my contributions to Emacs are infrequent.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Fri, 09 Jan 2015 23:48:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 19479 <at> debbugs.gnu.org (full text, mbox):
All this arguing just to try and avoid signing the standard document
baffles me,
Stefan
>>>>> "Kelly" == Kelly Dean <kelly <at> prtime.org> writes:
> I wrote:
>> Anyway, my patch that Glenn objected to was created in the past, not the
>> future, so at least that one is ok.
> Actually my future patches are ok too.
> http://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/disclaim.program says:
> ⌜Digital Stimulation Corporation hereby disclaims all copyright interest
> in the program "seduce" (a program to direct assemblers to make passes at
> compilers under GNU Emacs) written by Hugh Heffner, including both the
> present version of the program and his/her future changes and
> enhancements to it.⌝
> Notice the disclaimer applies to future work. Which means my disclaimer
> applying to future work is effective.
> If the FSF thinks it has to register those PD works (which would be absurd,
> but absurdity has never stopped lawyers), that's a separate issue from the
> one-time disclaimer (covering past and future work) that the
> disclaim.program file shows that the FSF does accept. It isn't any extra
> burden for the FSF compared to assignment, since obviously the FSF can only
> register intellectual property ownership of assigned works after those works
> are created too, so the FSF still has to constantly (or annually or
> whatever) send new paperwork to the copyright office even for contributors
> who have signed an assignment form. IOW, Stefan keeps the lawyers a lot
> busier than I do. ;-)
> But again, even if for some weird reason the lawyers think my disclaimer for
> future work isn't effective, it certainly is effective for my previous work,
> including my patch for bug #19479. (And if it isn't, then they're welcome to
> point out what's wrong with it, and send me a disclaimer form that _is_
> effective, which I asked for already in 2012). If necessary, I can re-date
> and re-sign it in the future to cover new work, which is fine since my
> contributions to Emacs are infrequent.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Sat, 10 Jan 2015 01:19:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 19479 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier wrote:
> All this arguing just to try and avoid signing the standard document
> baffles me
If I sign an assignment document, then I would be committing perjury. Possibly in the legal sense, and at least in the moral sense.
And there isn't just one standard document. There are at least five; three for disclaimers, and two for assignments. I asked the clerk to choose the correct disclaimer for me. If he'd done it, none of this arguing would be necessary.
All of which I already pointed out, so I'm baffled by your bafflement.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Sat, 10 Jan 2015 19:30:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 19479 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
In general, we do accept code whose copyright has been disclaimed by
the author. That is not our preference, but it is ok.
Would you please discuss this privately with me and the copyright clerk?
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
Use Ekiga or an ordinary phone call.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Sun, 11 Jan 2015 01:40:03 GMT)
Full text and
rfc822 format available.
Message #77 received at 19479 <at> debbugs.gnu.org (full text, mbox):
> If I sign an assignment document, then I would be committing perjury.
No, the assignment document is just for the Emacs code you wrote and
whose copyright you own. It simply doesn't apply to the code whose
copyright you don't own (which normally only happens when the copyright
is owned by your employer).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Sun, 11 Jan 2015 02:58:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 19479 <at> debbugs.gnu.org (full text, mbox):
Back on topic...
I found a good way to add timestamps to prevent metadata replay (the other vulnerability), and to further harden the package manager's security, but of course I'll wait until we hear from the clerk before trying to implement it.
The reason I said there's a compatibility problem for timestamps is that archive-contents is a list consisting just of a version number followed by a bunch of package records; the list's format isn't extensible (though the package record format is extensible). There's no way to insert a timestamp without changing the list's format (and thus, the version number), but if you do that, then old clients can't understand archive-contents anymore.
Even worse, old clients become stuck because they store the new-format (incompatible) file before checking the version number, then barf on it and refuse to accept even an old-format (compatible) file to replace it until you manually delete the stored one.
I see four possible solutions:
0. Have a flag day, on which all the elpas switch to the new format, and on or before which everybody must upgrade to Emacs 25 or his package manager will stop working.
1. Have the server check the User-Agent header, and send the old-format file if it's ⌜URL/Emacs⌝, and the new-format if it's ⌜URL/Emacs-25⌝ or later.
2. Use a different URL for the new-format file.
3. Keep the old format, and put the timestamp in a different file.
#0 obviously isn't an option.
I advise against #1, for reasons which everybody here already knows.
#2 would work, but is inelegant, since you would still have to retain the old-format file for the sake of old clients, and it's inefficient, since new clients would have to periodically re-download the entire file (fairly big, in Melpa's case) even if nothing but the timestamp changed (and clients have to demand fresh timestamps in order to prevent metadata replay attacks).
#3 looks like the best solution. The timestamp file includes the timestamp and the hash of archive-contents. Sign the timestamp file for the sake of new clients.
Old clients would ignore the timestamp file. If archive-contents is unchanged, then new clients would only have to periodically re-download the timestamp file and signature--the minimal amount of data necessary. They'd see that the current hash of archive-contents matches the version they already have stored. IOW, to whoever made archive-contents inextensible: thank you! You've forced the right solution to timestamping. ;-)
Combined with my previous patch, this leaves the timestamp-file's signature as the only one that's necessary to secure the entire archive (packages and metadata, including timestamp) and prevent both package and metadata replay attacks. IMHO, this simplicity makes it practical to insist that all elpas provide this signature, so Emacs 25 could enforce it by default.
Optionally continue signing archive-contents for the sake of 24.4 clients, but since 25 won't need that signature, nothing before 24.4 is capable of checking it, 24.4 doesn't enforce it by default, Melpa doesn't even provide it IIUC (GNU Elpa does), and 24.4 is vulnerable to package and metadata replay anyway, you might as well not. The kind of people who have changed package-check-signature to t will upgrade to 25 anyway.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Sun, 11 Jan 2015 03:22:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 19479 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier wrote:
>> If I sign an assignment document, then I would be committing perjury.
>
> No, the assignment document is just for the Emacs code you wrote and
> whose copyright you own. It simply doesn't apply to the code whose
> copyright you don't own (which normally only happens when the copyright
> is owned by your employer).
I don't have a copy of it handy, but if that's the way it's worded, then you're right, it wouldn't be illegal for me to sign it. It would only be immoral. It would be legally vacuous, and deceptive, leading to doubt about my intent.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Sun, 11 Jan 2015 06:34:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 19479 <at> debbugs.gnu.org (full text, mbox):
>> No, the assignment document is just for the Emacs code you wrote
>> and whose copyright you own. It simply doesn't apply to the code
>> whose copyright you don't own (which normally only happens when the
>> copyright is owned by your employer).
>
> I don't have a copy of it handy, but if that's the way it's worded,
> then you're right, it wouldn't be illegal for me to sign it. It
> would only be immoral. It would be legally vacuous, and deceptive,
> leading to doubt about my intent.
Perhaps slightly off-topic, but quite relevant IMHO in a global
perspective:
It is *not* possible to create not-copyrighted code in some
jurisdictions like Germany. Whatever you write, it is by default
copyrighted by you (regardless whether there is a `public domain' line
or not), and you have to explicitly disclaim or reassign the
copyright.
For this reason, it is *much* better to use a license like CC0 instead
of a public domain notice, since this covers the `public domain' idea
in virtually all countries. Actually, this is what the FSF recommends
(https://www.gnu.org/licenses/license-list.en.html#CC0), and I guess
this works for emacs also, since it works already for GNU (according
to https://gcc.gnu.org/contribute.html#legal).
Werner
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Mon, 12 Jan 2015 15:39:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 19479 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
Instead of having a discussion here, please let me get this worked out
between Kelly and our clerk, with the help of lawyers when needed.
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
Use Ekiga or an ordinary phone call.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Tue, 20 Jan 2015 21:25:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 19479 <at> debbugs.gnu.org (full text, mbox):
The FSF has accepted my disclaimer and added me to their records. You can install my patches if you find them satisfactory on technical grounds.
Added indication that bug 19479 blocks19759
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Tue, 03 Feb 2015 21:24:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Tue, 24 Feb 2015 08:49:02 GMT)
Full text and
rfc822 format available.
Message #97 received at 19479 <at> debbugs.gnu.org (full text, mbox):
Note, I'm not implementing the metadata-replay fix, because it's unlikely my patch would be accepted, so somebody else will need to do it. See my January 11th message to bug #19479 for a description of how to do it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Tue, 24 Feb 2015 18:12:01 GMT)
Full text and
rfc822 format available.
Message #100 received at 19479 <at> debbugs.gnu.org (full text, mbox):
So, I don't want to get into this discussion, but I've always assumed
that disclaimers do not/cannot apply to future changes. I asked
assign <at> gnu.org, and they confirmed "Disclaimers are not valid for future
contributions".
I mention this because AFAICS you are sending new patches.
Your disclaimer is dated 2015-1-8. AFAICS we cannot apply anything after
that. Someone should also check the several patches from you that have
been applied recently to make sure they originated before this date.
Sorry, I don't have time/inclination to discuss special cases.
Maybe you want to take it up with rms and/or assign <at> gnu.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Tue, 24 Feb 2015 23:04:02 GMT)
Full text and
rfc822 format available.
Message #103 received at 19479 <at> debbugs.gnu.org (full text, mbox):
> So, I don't want to get into this discussion,
And yet you chose to dig it back up, even after everybody else was satisfied that it was resolved more than a month ago. The copyright clerk's exact words on January 20th were, ‟We've accepted the public domain disclaimer and added you to our records”, not ‟we've accepted part of the disclaimer, but rejected another part”.
The disclaimer covers future changes, and everybody's comments about that part had already been CCed to the clerk, and his answer was, ‟We've accepted the public domain disclaimer”.
> but I've always assumed
> that disclaimers do not/cannot apply to future changes. I asked
> assign <at> gnu.org, and they confirmed "Disclaimers are not valid for future
> contributions".
Good luck finding a copyright judge anywhere in America who would agree with your absurd claim that my work since January 8th is not in the public domain, despite my signed statement that it is.
Or if you admit it is PD, I'm sure you can dream up some rationalization of why PD code isn't allowed in Emacs, and then try to remove it all, which is a lot more than just my code.
Either way, I'm done trying to work on Emacs. This B.S. isn't worth my time.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Wed, 25 Feb 2015 21:11:02 GMT)
Full text and
rfc822 format available.
Message #106 received at 19479 <at> debbugs.gnu.org (full text, mbox):
Kelly Dean wrote:
>> So, I don't want to get into this discussion,
>
> And yet you chose to dig it back up, even after everybody else was
> satisfied that it was resolved more than a month ago.
I've been largely on a break from Emacs. I always thought there was
something strange here, and I just happened to get motivated enough now
to ask assign <at> gnu for clarification when I saw patches were still arriving.
> The copyright clerk's exact words on January 20th were, ‟We've
> accepted the public domain disclaimer and added you to our records",
> not ‟we've accepted part of the disclaimer, but rejected another
> part".
I specifically mentioned you by name in the question I asked assign <at> gnu,
and the reply I got (one day ago) was, in totality:
Disclaimers are not valid for future contributions. Thanks for checking in.
Like I said, you can take it up with them if you disagree.
I'be glad to be corrected, but it all seems pretty clear to me.
I am not trying to be the bad guy and I am not out to get you.
I applied several patches from you and would have been happy to apply more.
I am just trying to ensure Emacs follows the FSF's procedures,
which seem pretty clear to me.
Vibhav Pant wrote:
> Well, what about
> http://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future?
> This is the form to request documents for assigning past and future
> works, which according to you isn't possible.
That's not what I said.
I said: I am told *disclaimers* cannot apply to future changes.
You will note that there are separate documents for *assigning* past
changes (request-assign.changes), and past-and-future changes
(request-assign.future). But for *disclaimers* there is only
request-disclaim.changes. There is no request-disclaim.future.
If you read
http://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright/request-disclaim.changes
it quite clearly states that it only applies to past, finished changes.
I am not a lawyer (AFAIK, neither is anyone else on this list) and
have no interest in discussing why these things are different.
They just are.
I said the first time we went through this that it was my
understanding that disclaimers worked this way. I said it again here:
https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00198.html
I have now had this confirmed by assign <at> gnu.
If you (the generic you) want to contribute to Emacs, there is a
well-defined, simple procedure that hundreds of people have followed
with no problem.
If you don't want to follow the procedure, then fine, that's your
prerogative. Then you can't contribute.
But please don't start arguing with us about what the procedure is, or
should be, or what you think a judge might say, or why you need to be an
exception. We don't set the rules here at Emacs, and it just isn't a
productive use of anyone's time.
Removed indication that bug 19479 blocks
Request was from
Dmitry Gutov <dgutov <at> yandex.ru>
to
control <at> debbugs.gnu.org.
(Sat, 14 May 2016 23:06:01 GMT)
Full text and
rfc822 format available.
Added indication that bug 19479 blocks21966
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Mon, 23 May 2016 00:13:01 GMT)
Full text and
rfc822 format available.
Removed indication that bug 19479 blocks
Request was from
Eli Zaretskii <eliz <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Mon, 10 Oct 2016 10:36:02 GMT)
Full text and
rfc822 format available.
Added indication that bug 19479 blocks24655
Request was from
Eli Zaretskii <eliz <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Mon, 10 Oct 2016 10:36:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Sat, 02 Sep 2017 12:25:01 GMT)
Full text and
rfc822 format available.
Message #117 received at 19479 <at> debbugs.gnu.org (full text, mbox):
unblock 24655 by 19479
thanks
> From: Glenn Morris <rgm <at> gnu.org>
> Date: Wed, 25 Feb 2015 16:09:57 -0500
> Cc: 19479 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
>
> I am not a lawyer (AFAIK, neither is anyone else on this list) and
> have no interest in discussing why these things are different.
> They just are.
>
> I said the first time we went through this that it was my
> understanding that disclaimers worked this way. I said it again here:
> https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00198.html
>
> I have now had this confirmed by assign <at> gnu.
>
>
> If you (the generic you) want to contribute to Emacs, there is a
> well-defined, simple procedure that hundreds of people have followed
> with no problem.
>
> If you don't want to follow the procedure, then fine, that's your
> prerogative. Then you can't contribute.
>
> But please don't start arguing with us about what the procedure is, or
> should be, or what you think a judge might say, or why you need to be an
> exception. We don't set the rules here at Emacs, and it just isn't a
> productive use of anyone's time.
Two and a half years later, with no one complaining about this, it
doesn't sound right for this issue to block the release of Emacs 26.1.
Removed indication that bug 19479 blocks
Request was from
Eli Zaretskii <eliz <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Sat, 02 Sep 2017 12:26:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Sun, 03 Sep 2017 01:11:01 GMT)
Full text and
rfc822 format available.
Message #122 received at 19479 <at> debbugs.gnu.org (full text, mbox):
[Dropping emacs-devel, since that seems unlikely to be productive given
the lack of context.]
Eli Zaretskii wrote:
> Two and a half years later, with no one complaining about this, it
> doesn't sound right for this issue to block the release of Emacs 26.1.
The context here was security vulnerabilities in the package manager.
Personally I'm uneasy with saying "we've ignored this for X years so
let's continue to ignore it.". But I don't have anything substantive to
add.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Fri, 04 Oct 2019 09:51:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 19479 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Kelly Dean <kelly <at> prtime.org> writes:
> Ivan Shmakov requested that I send this message to the bug list.
>
> For details, see my message with subject ⌜Emacs package manager vulnerable to replay attacks⌝ to emacs-devel on 30 Dec 2014:
> https://lists.gnu.org/archive/html/emacs-devel/2014-12/msg02319.html
>
> Executive summary to fix the vulnerabilities:
>
> 0. Include a hash and length of each package's content in the package's record
> in archive-contents, rather than only including the package name and version
> number in that file as Emacs currently does. Barf if a package hash doesn't
> verify, regardless of whether any signatures verify.
> (Length technically not necessary, but still generally useful, e.g. if
> there's a length mismatch then you know there's a content mismatch and
> you don't have to bother checking the hash.)
I have implemented the first part of the protection against metadata
replay attacks in the attached patch: support for checksum (or hash)
verification. This change is backwards-compatible; the new fields can
be added to "archive-contents" file without impacting old clients.
I've not yet updated documentation, NEWS, etc. but will get to that
next.
I introduce a new user option `package-verify-checksums' that controls
this new behaviour. The default is 'allow-missing', which only
carries out this check if there are checksums in "archive-contents",
and does nothing otherwise. In itself, this does nothing to protect
against metadata replay attacks (but might protect against data
corruption). You need to set `package-verify-checksums' to t, and
implement timestamping (discussed below).
I still suggest to stick with this default for Emacs 27.1, or at least
until common package archives can catch up. Once this is implemented
in GNU ELPA and MELPA, it makes more sense to move to a stricter
default. Otherwise, the transition will be very bumpy. I therefore
suggest to discuss stricter defaults later.
(BTW, I didn't bother fixing the package-x.el code for this patch,
since it seems like it's not that widely used. It will work as
before, but lack support for adding the checksums automatically.)
> 1. Include a timestamp of archive-contents in that file itself (so that the
> signature in archive-contents.sig depends on the timestamp, so that the
> timestamp can't be forged), and have Emacs ignore any new archive-contents
> that's older than the latest valid one that Emacs has already seen or is older
> than some specified limit. One thing I forgot to mention in my original message:
> have Emacs signal a warning if it ever sees an archive-contents dated in the
> future, which indicates misconfiguration of the client or server (or of course,
> some kind of mischief).
To protect against metadata replay attacks, it is correct that we need
timestamps too. I haven't done that in this first patch, but I hope
to do it in a following patch. I wanted to get this first part done
before I started working on that.
My current best idea for how to do it is one which AFAICT haven't been
raised in this thread before: to add a comment with an RFC3339
timestamp to the top of the "archive-contents" file:
;; Last-Updated: 2019-10-01T15:32:55.000Z
This will be ignored by older versions of Emacs, since package.el uses
(read (current-buffer)) to read this file. New versions will have
an easy time parsing this header, caching the value, and refusing to
update the package cache if the timestamp is older than one we have
already seen. With that, we would have implemented protection
against metadata replay attacks.
I think it would be highly beneficial if this could go in before Emacs
27, not least so that package archives can start implementing support
for this.
Comments on all this are obviously more than welcome.
Best regards,
Stefan Kangas
PS. Note that the original thread ended up highly off-topic discussing
copyright issues, because one potential contributor refused to sign
the standard copyright assignment. The eventual outcome was that we
could not use a patch written by that person. I have therefore
deliberately not looked at that persons patch in order to avoid any
copyright issues. I have implemented this from scratch based solely
on the below link, and the discussion in this thread:
https://www2.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html
[0001-Support-package-checksum-verification.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Wed, 06 May 2020 00:57:01 GMT)
Full text and
rfc822 format available.
Message #128 received at 19479 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefan <at> marxist.se> writes:
> Subject: [PATCH] Support package checksum verification
>
> This is the first step towards protecting users of package.el against
> metadata replay attacks.
> +(define-error 'bad-checksum "Failed to verify checksum")
Would it be useful to have bad-signature and this one share a parent?
(by the way, I kind of wonder why it's not called
package-bad-signature).
> + (cl-flet*
> + ((supported-hashes
> + (lambda ()
Is this a function (rather than a variable) just so it can be in the
same cl-flet* as do-check?
> + (or (seq-filter (lambda (h) (memql (car h) (secure-hash-algorithms)))
The list returned by secure-hash-algorithms includes sha1 and md5. This
is a problem if we're going to rely on signing them. We should at least
plan to have some way of filtering out some functions.
> + (a (cdr hash))
> + (b (secure-hash algorithm (current-buffer))))
> + (when-let ((a (package-desc-size pkg-desc))
> + (b (string-bytes (buffer-string))))
I risk descending into trivial nitpicking, but I think 'a' and 'b' are
bit too generic. Something like 'expected' and 'actual' would make it
harder to mix them up.
> +(defmacro run-verify-checksums-test (verify-checksums checksums)
> + "Run a test for `package-verify-checksums'."
> +(ert-deftest package-test--verify-package-checksums-nil/ignore-invalid ()
I think run-verify-checksums-test should be prefixed with package-test
(whereas the individual test names could be prefixed with just package).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Mon, 07 Sep 2020 00:00:02 GMT)
Full text and
rfc822 format available.
Message #131 received at 19479 <at> debbugs.gnu.org (full text, mbox):
Noam Postavsky <npostavs <at> gmail.com> writes:
> Stefan Kangas <stefan <at> marxist.se> writes:
>
>> Subject: [PATCH] Support package checksum verification
>>
>> This is the first step towards protecting users of package.el against
>> metadata replay attacks.
>
>> +(define-error 'bad-checksum "Failed to verify checksum")
>
> Would it be useful to have bad-signature and this one share a parent?
> (by the way, I kind of wonder why it's not called
> package-bad-signature).
Indeed, I fixed that.
>> + (cl-flet*
>> + ((supported-hashes
>> + (lambda ()
>
> Is this a function (rather than a variable) just so it can be in the
> same cl-flet* as do-check?
I'm not sure I understand; it should be a function instead of a variable
because there is logic in there to match `(secure-hash-algorithms)'
against `(package-desc-checksums pkg-desc)' and signal an error.
>> + (or (seq-filter (lambda (h) (memql (car h) (secure-hash-algorithms)))
>
> The list returned by secure-hash-algorithms includes sha1 and md5. This
> is a problem if we're going to rely on signing them. We should at least
> plan to have some way of filtering out some functions.
Yes, we currently would place the onus on the package archives to not
use those algorithms. We could choose to filter them out as completely
unacceptable, I think that makes sense.
>> + (a (cdr hash))
>> + (b (secure-hash algorithm (current-buffer))))
>
>> + (when-let ((a (package-desc-size pkg-desc))
>> + (b (string-bytes (buffer-string))))
>
> I risk descending into trivial nitpicking, but I think 'a' and 'b' are
> bit too generic. Something like 'expected' and 'actual' would make it
> harder to mix them up.
Thanks, fixed.
>> +(defmacro run-verify-checksums-test (verify-checksums checksums)
>> + "Run a test for `package-verify-checksums'."
>
>> +(ert-deftest package-test--verify-package-checksums-nil/ignore-invalid ()
>
> I think run-verify-checksums-test should be prefixed with package-test
> (whereas the individual test names could be prefixed with just package).
That's true. Fixed.
Thanks for the review!
Best regards,
Stefan Kangas
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Mon, 07 Sep 2020 14:16:02 GMT)
Full text and
rfc822 format available.
Message #134 received at 19479 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefan <at> marxist.se> writes:
>> Is this a function (rather than a variable) just so it can be in the
>> same cl-flet* as do-check?
>
> I'm not sure I understand; it should be a function instead of a variable
> because there is logic in there to match `(secure-hash-algorithms)'
> against `(package-desc-checksums pkg-desc)' and signal an error.
Ah, I think had forgotten about/was confused by cl-flet's (FUNC (lambda
ARGLIST ...)) syntax when I wrote that. Although I suppose you could
make it a plain variable by moving it inside do-check's lambda (not sure
if that's an improvement)?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Mon, 07 Sep 2020 17:20:02 GMT)
Full text and
rfc822 format available.
Message #137 received at 19479 <at> debbugs.gnu.org (full text, mbox):
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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Mon, 07 Sep 2020 18:12:01 GMT)
Full text and
rfc822 format available.
Message #140 received at 19479 <at> debbugs.gnu.org (full text, mbox):
Noam Postavsky <npostavs <at> gmail.com> writes:
> Stefan Kangas <stefan <at> marxist.se> writes:
>
>>> Is this a function (rather than a variable) just so it can be in the
>>> same cl-flet* as do-check?
>>
>> I'm not sure I understand; it should be a function instead of a variable
>> because there is logic in there to match `(secure-hash-algorithms)'
>> against `(package-desc-checksums pkg-desc)' and signal an error.
>
> Ah, I think had forgotten about/was confused by cl-flet's (FUNC (lambda
> ARGLIST ...)) syntax when I wrote that. Although I suppose you could
> make it a plain variable by moving it inside do-check's lambda (not sure
> if that's an improvement)?
Sure, you could do that. I guess it's mostly down to style, but I
personally feel like that change would make the code a little bit harder
to read here.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Mon, 07 Sep 2020 23:55:01 GMT)
Full text and
rfc822 format available.
Message #143 received at 19479 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefan <at> marxist.se> writes:
>
>> One more feature: include in each version of archive-contents a hash
[...]
> 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?
Not entirely, but there's a bit more detail on the emacs-devel thread
linked from the OP:
One final feature that isn't necessary for preventing any of the
vulnerabilities above, but still is helpful to make the historical record even
more clear, is to include in each version of archive-contents a hash (and
length) of the previous version of that file. This further constrains an
attacker who has compromised the elpa key; he can still launch attacks, but
it's harder to keep the attacks secret for very long, since he's forced to
cause a fork in what's supposed to be a linear hash chain.
I think the idea is that if the attacker has the signing key and sends
out a bad version of archive-contents, it will be revealed as soon as
the victim gets a "good" version, since its previous-version hash won't
match. Except that only works if the user can expect to get all
versions of archive-contents, so maybe I've missed something.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Tue, 08 Sep 2020 08:12:02 GMT)
Full text and
rfc822 format available.
Message #146 received at 19479 <at> debbugs.gnu.org (full text, mbox):
Noam Postavsky <npostavs <at> gmail.com> writes:
> I think the idea is that if the attacker has the signing key and sends
> out a bad version of archive-contents, it will be revealed as soon as
> the victim gets a "good" version, since its previous-version hash won't
> match.
Yes, this is what I understood to be the case as well.
> Except that only works if the user can expect to get all versions of
> archive-contents, so maybe I've missed something.
Exactly my point. So we can't rely on it to bail out if the hashes
don't match up, I think.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Sat, 21 Nov 2020 23:52:02 GMT)
Full text and
rfc822 format available.
Message #149 received at 19479 <at> debbugs.gnu.org (full text, mbox):
I have just pushed the branch scratch/package-security with proper
support for timestamps, as discussed below. More details are in the
commit messages and the proposed documentation changes. Once this is
merged, I hope to work on adding support for this to both GNU ELPA and
NonGNU ELPA.
I would like to merge this change to the master branch. Is it
sufficient to ask for reviews and comments here first, or is there
anything else I should do in addition?
Any comments and feedback on all this is of course more than welcome.
Please also see my previous message about this change below.
Stefan Kangas <stefan <at> marxist.se> writes:
> Kelly Dean <kelly <at> prtime.org> writes:
>
>> Ivan Shmakov requested that I send this message to the bug list.
>>
>> For details, see my message with subject ⌜Emacs package manager vulnerable to replay attacks⌝ to emacs-devel on 30 Dec 2014:
>> https://lists.gnu.org/archive/html/emacs-devel/2014-12/msg02319.html
>>
>> Executive summary to fix the vulnerabilities:
>>
>> 0. Include a hash and length of each package's content in the package's record
>> in archive-contents, rather than only including the package name and version
>> number in that file as Emacs currently does. Barf if a package hash doesn't
>> verify, regardless of whether any signatures verify.
>> (Length technically not necessary, but still generally useful, e.g. if
>> there's a length mismatch then you know there's a content mismatch and
>> you don't have to bother checking the hash.)
>
> I have implemented the first part of the protection against metadata
> replay attacks in the attached patch: support for checksum (or hash)
> verification. This change is backwards-compatible; the new fields can
> be added to "archive-contents" file without impacting old clients.
> I've not yet updated documentation, NEWS, etc. but will get to that
> next.
>
> I introduce a new user option `package-verify-checksums' that controls
> this new behaviour. The default is 'allow-missing', which only
> carries out this check if there are checksums in "archive-contents",
> and does nothing otherwise. In itself, this does nothing to protect
> against metadata replay attacks (but might protect against data
> corruption). You need to set `package-verify-checksums' to t, and
> implement timestamping (discussed below).
>
> I still suggest to stick with this default for Emacs 27.1, or at least
> until common package archives can catch up. Once this is implemented
> in GNU ELPA and MELPA, it makes more sense to move to a stricter
> default. Otherwise, the transition will be very bumpy. I therefore
> suggest to discuss stricter defaults later.
>
> (BTW, I didn't bother fixing the package-x.el code for this patch,
> since it seems like it's not that widely used. It will work as
> before, but lack support for adding the checksums automatically.)
>
>> 1. Include a timestamp of archive-contents in that file itself (so that the
>> signature in archive-contents.sig depends on the timestamp, so that the
>> timestamp can't be forged), and have Emacs ignore any new archive-contents
>> that's older than the latest valid one that Emacs has already seen or is older
>> than some specified limit. One thing I forgot to mention in my original message:
>> have Emacs signal a warning if it ever sees an archive-contents dated in the
>> future, which indicates misconfiguration of the client or server (or of course,
>> some kind of mischief).
>
> To protect against metadata replay attacks, it is correct that we need
> timestamps too. I haven't done that in this first patch, but I hope
> to do it in a following patch. I wanted to get this first part done
> before I started working on that.
>
> My current best idea for how to do it is one which AFAICT haven't been
> raised in this thread before: to add a comment with an RFC3339
> timestamp to the top of the "archive-contents" file:
>
> ;; Last-Updated: 2019-10-01T15:32:55.000Z
>
> This will be ignored by older versions of Emacs, since package.el uses
> (read (current-buffer)) to read this file. New versions will have
> an easy time parsing this header, caching the value, and refusing to
> update the package cache if the timestamp is older than one we have
> already seen. With that, we would have implemented protection
> against metadata replay attacks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Thu, 26 Nov 2020 00:44:01 GMT)
Full text and
rfc822 format available.
Message #152 received at 19479 <at> debbugs.gnu.org (full text, mbox):
> I have just pushed the branch scratch/package-security with proper
> support for timestamps, as discussed below. More details are in the
> commit messages and the proposed documentation changes. Once this is
> merged, I hope to work on adding support for this to both GNU ELPA and
> NonGNU ELPA.
Do we need this hash-checksum, really?
AFAICT, I think if we want to avoid replay attacks we need indeed
a monotone "counter" (e.g. a timestamp) on the `archive-contents` and
then a way to verify that the tarballs are what they claim to be.
We can already verify that they are what they claim to be since the
tarball includes the version number inside the `<pkg>-pkg.el` file.
So, I think all we need is to verify the contents of `<pkg>-pkg.el`
after unpacking a tarball, to make sure it is indeed the package and
version its name claimed to be. This check would be welcome in any case
to detect packaging errors.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Thu, 26 Nov 2020 02:07:02 GMT)
Full text and
rfc822 format available.
Message #155 received at 19479 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> Do we need this hash-checksum, really?
AFAIK, a cryptographic hash is the generally accepted solution for
securely verifying the contents of a file. That is, when you worry
about that file having been tampered with by a hostile actor.
> AFAICT, I think if we want to avoid replay attacks we need indeed
> a monotone "counter" (e.g. a timestamp) on the `archive-contents` and
> then a way to verify that the tarballs are what they claim to be.
We also need to sign `archive-contents', of course. But otherwise
correct: we need to know that the metadata is not out-of-date, and we
need to have a (secure) mapping from the package metadata to individual
packages.
> We can already verify that they are what they claim to be since the
> tarball includes the version number inside the `<pkg>-pkg.el` file.
>
> So, I think all we need is to verify the contents of `<pkg>-pkg.el`
> after unpacking a tarball, to make sure it is indeed the package and
> version its name claimed to be. This check would be welcome in any case
> to detect packaging errors.
I think the question here is: how do we securely map from the (signed)
package metadata to an individual package?
While not perfect, with a secure hash function, collisions are hard
enough to find that we for our purposes (like the rest of the world) can
happily not worry about it. In comparison, it is immeasurably easier to
fake a version number than having to defeat a hash function. I think
this is a significant drawback of what you propose.
We would need to add in a number of assumptions (e.g. packages are
individually signed, we never accidentally sign an old package with a
newer version number, etc.), to gain more confidence in a simple version
number check.
But even then the security it provides will not be as strong, and much
more brittle; there are just more moving parts where things could go
wrong. And I'm not sure what we would gain. Importantly, I don't think
it would simplify our implementation in Emacs (or GNU/NonGNU ELPA)
significantly.
But we could of course also check that the version number is correct.
That sounds like a useful sanity check to do.
Thanks for taking a look at this!
PS. Note that if we add a checksum, there will no longer be any need to
sign individual packages for future versions of Emacs. We would
then only need to sign the metadata.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Thu, 26 Nov 2020 02:31:01 GMT)
Full text and
rfc822 format available.
Message #158 received at 19479 <at> debbugs.gnu.org (full text, mbox):
> While not perfect, with a secure hash function, collisions are hard
> enough to find that we for our purposes (like the rest of the world) can
> happily not worry about it. In comparison, it is immeasurably easier to
> fake a version number than having to defeat a hash function. I think
> this is a significant drawback of what you propose.
I'm not sure what you mean by it being easier: since the tarballs are
cryptographically signed, just like `archive-contents`, if
`archive-contents` points to `foo-42.1.tar` and that tarball has
a correct signature and its content says that it is indeed the package
`foo-42.1`, then I'm not sure which easy attack would be applicable.
AFAICT you'd have to find some old signed tarball which we accidentally
built with an incorrect content? But presumably if we ever mess up
a tarball like that (which is indeed possible), we'd then want to be
careful not to "reuse" that version number, no?
> We would need to add in a number of assumptions (e.g. packages are
> individually signed,
Which they already are.
> we never accidentally sign an old package with a newer version number,
> etc.),
That's indeed the case as well.
> to gain more confidence in a simple version
> number check.
I think it's comparable: the main failings wold require some error on
our side in how we build and sign packages, and in most such cases
I think we'd end up with holes with either scheme.
> But we could of course also check that the version number is correct.
> That sounds like a useful sanity check to do.
Exactly.
> PS. Note that if we add a checksum, there will no longer be any need to
> sign individual packages for future versions of Emacs. We would
> then only need to sign the metadata.
I think we'd want to keep the signatures anyway, e.g. they can still be
checked manually for old tarballs which aren't listed in
`archive-contents` any more. And more generally they allow
authenticating the origin of a package without having to look it up in
`archive-contents`.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Thu, 26 Nov 2020 03:03:02 GMT)
Full text and
rfc822 format available.
Message #161 received at 19479 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> While not perfect, with a secure hash function, collisions are hard
>> enough to find that we for our purposes (like the rest of the world) can
>> happily not worry about it. In comparison, it is immeasurably easier to
>> fake a version number than having to defeat a hash function. I think
>> this is a significant drawback of what you propose.
>
> I'm not sure what you mean by it being easier: since the tarballs are
> cryptographically signed, just like `archive-contents`, if
> `archive-contents` points to `foo-42.1.tar` and that tarball has
> a correct signature and its content says that it is indeed the package
> `foo-42.1`, then I'm not sure which easy attack would be applicable.
I guess it's in the nature of attacks that we generally don't know or
think about them in advance. This is precisely why, when it comes to
security, it IMO a good idea to use battle-tested and generally accepted
solutions.
> AFAICT you'd have to find some old signed tarball which we accidentally
> built with an incorrect content? But presumably if we ever mess up
> a tarball like that (which is indeed possible), we'd then want to be
> careful not to "reuse" that version number, no?
I'm not sure we can assume that we would always detect when we mess up.
But yes, this sounds like one possible attack vector.
> I think it's comparable: the main failings wold require some error on
> our side in how we build and sign packages, and in most such cases
> I think we'd end up with holes with either scheme.
Agreed, we could make mistakes in implementing either scheme.
FWIW, I think that with the version number idea, there are more places
where we could make important mistakes, since more code would be
involved. There are also more assumptions that we need to ensure hold
true under all circumstances. (But see below.)
>> But we could of course also check that the version number is correct.
>> That sounds like a useful sanity check to do.
>
> Exactly.
How about adding this check in addition to the checksum check? Having
two separate checks together should surely bring more confidence than
either of them would separately. That sounds like good "defense in
depth" thinking to me.
> I think we'd want to keep the signatures anyway, e.g. they can still be
> checked manually for old tarballs which aren't listed in
> `archive-contents` any more. And more generally they allow
> authenticating the origin of a package without having to look it up in
> `archive-contents`.
Valid points. Let's keep them indefinitely.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Thu, 26 Nov 2020 03:12:01 GMT)
Full text and
rfc822 format available.
Message #164 received at 19479 <at> debbugs.gnu.org (full text, mbox):
> How about adding this check in addition to the checksum check?
I think we should add this check in any case, yes.
> Having two separate checks together should surely bring more
> confidence than either of them would separately. That sounds like
> good "defense in depth" thinking to me.
I'm not sure the added hash is needed, but it seems reasonably harmless.
>> I think we'd want to keep the signatures anyway, e.g. they can still be
>> checked manually for old tarballs which aren't listed in
>> `archive-contents` any more. And more generally they allow
>> authenticating the origin of a package without having to look it up in
>> `archive-contents`.
> Valid points. Let's keep them indefinitely.
Especially since some people seem interested to add commands to
`package.el` to programatically install old packages.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19479; Package
emacs.
(Thu, 26 Nov 2020 05:08:02 GMT)
Full text and
rfc822 format available.
Message #167 received at 19479 <at> debbugs.gnu.org (full text, mbox):
* Stefan Kangas <stefan <at> marxist.se> [2020-11-26 05:07]:
> PS. Note that if we add a checksum, there will no longer be any need to
> sign individual packages for future versions of Emacs. We would
> then only need to sign the metadata.
I do not know internals as I did not see yet signed package. But if
signed package fetched from GNU ELPA then such is verified against
official key on user's computer, right?
Now take in account that signed packages will be distributed through
mirrors and mirrors already exist.
If archive-contents or meta data is signed and can be technically used
by mirror, that would be fine. If archive-contents need to be changed
or mirror wants to mirror only specific packages then package need to
be signed.
This bug report was last modified 4 years and 202 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.