bug#19479: Package manager vulnerable

classic Classic list List threaded Threaded
45 messages Options
123
Reply | Threaded
Open this post in threaded view
|

bug#19479: Package manager vulnerable

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



Reply | Threaded
Open this post in threaded view
|

bug#19479: Package manager vulnerable

Stefan Monnier
> 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



Reply | Threaded
Open this post in threaded view
|

bug#19479: Package manager vulnerable

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



Reply | Threaded
Open this post in threaded view
|

bug#19479: Package manager vulnerable

Stefan Monnier
> 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



Reply | Threaded
Open this post in threaded view
|

bug#19479: [PATCH] Re: bug#19479: Package manager vulnerable

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

--- 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))))))
Reply | Threaded
Open this post in threaded view
|

bug#19479: [PATCH] Re: bug#19479: Package manager vulnerable

Glenn Morris-3

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)



Reply | Threaded
Open this post in threaded view
|

bug#19479: Package manager vulnerable

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



Reply | Threaded
Open this post in threaded view
|

bug#19479: Package manager vulnerable

Kelly Dean
In reply to this post by Kelly Dean
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.



Reply | Threaded
Open this post in threaded view
|

bug#19479: Package manager vulnerable

Stefan Monnier
In reply to this post by Kelly Dean
> 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



Reply | Threaded
Open this post in threaded view
|

bug#19479: Package manager vulnerable

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



Reply | Threaded
Open this post in threaded view
|

bug#19479: Package manager vulnerable

Stefan Monnier
>> 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



Reply | Threaded
Open this post in threaded view
|

bug#19479: Copyright issue (was: Re: bug#19479: Package manager vulnerable)

Kelly Dean
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 [hidden email], 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 [hidden email] or [hidden email] mailing lists, to [hidden email], 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 [hidden email], my current email address of [hidden email], 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
[hidden email]
January 8, 2015


gnu-disclaimer.pdf (39K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#19479: Copyright issue

Stefan Monnier
> 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



Reply | Threaded
Open this post in threaded view
|

bug#19479: Copyright issue

David Kastrup
Stefan Monnier <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

bug#19479: Copyright issue

Kelly Dean
In reply to this post by Stefan Monnier
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.



Reply | Threaded
Open this post in threaded view
|

bug#19479: Copyright issue

Glenn Morris-3

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@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@gnu says.



Reply | Threaded
Open this post in threaded view
|

bug#19479: Copyright issue

Glenn Morris-3
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.



Reply | Threaded
Open this post in threaded view
|

bug#19479: Copyright issue

Kelly Dean
In reply to this post by David Kastrup
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.



Reply | Threaded
Open this post in threaded view
|

bug#19479: Copyright issue

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



Reply | Threaded
Open this post in threaded view
|

bug#19479: Copyright issue

Stefan Monnier
All this arguing just to try and avoid signing the standard document
baffles me,


        Stefan


>>>>> "Kelly" == Kelly Dean <[hidden email]> 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.





123