On Aug 12, 2014, at 3:33 AM, Werner Koch <w...@gnupg.org> wrote: > On Tue, 12 Aug 2014 00:08, ds...@jabberwocky.com said: > >> Rather than fixing RFC-1991 support, why not go in the other direction >> and make it clear that it isn't supported, and won't work? I did a >> bunch of work to make --pgp2 work well and interoperate with PGP 2.x >> over a decade ago. Even then it was intended as a stopgap measure >> until people finally stopped using PGP 2.x. Over 10 years later, it's >> well past time to kill it. > > I fully agree. Do you mean to document it or to remove the function and > change the options to print a warning message that they don't do > anything? For 2.1.
How about remove the functions in 2.1, and add a warning (in the docs, and perhaps upon use in the code) that the functions will be going away in 2.0? That might be aggressive, but then, 2.1 isn't officially released yet, so it's not unreasonable to make a larger change there. What do you think? I need to look at the code and see if there are any places where removal of --pgp2 (or --pgpX in general) will leave things in a messy state. One place that comes to mind is in --gen-revoke. GPG can import a bare revocation certificate. No version of PGP can, so there is code to push out a minimal public key before the revocation certificate. We'd need to add some sort of flag to indicate to include the minimal public key, and that's sort of reinventing --pgp again. Maybe the answer is to remove the things to generate PGP 2 messages specifically, and leave the other stuff? That feels a bit messy. > What about --compress-keys and --compress-sigs? These are GnuPG only > features which predate OpenPGP and have been introduced only to allow > that old accidental behaviour of GnuPG. I'd remove them as well. They're much easier to remove than --pgp2 as they only affect very specific (and few) places in the code. David _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
