Re: Breaking changes

[Werner Koch]

On Wed, 23 May 2018 15:45, m16+gn...@monksofcool.net said:

> 1. GPG is maintained by volunteers. If you have any complaint about how
> this maintenance is progressing, get off your behind and be a volunteer

That is fortunately not true.  I work full time on GnuPG and related
software, Gniibe is working at least half-time on it, Ben started to
work half-time and Andre spends most of his paid time on Gpg4win and
also GnuPG.

This is possible due to our generous donors as well as from a few
successful projects we did in the last 3 years.

> 2. GPG 1.4 will not suddenly vanish if it is no longer maintained.
> People can still use it like before. Maybe they shouldn't, but they can.

Right; we keep it - it is important to have a way to decrypt old data.
Some minor changes will be done over time but for example, mitigation's
against side-channel attacks and such won't happen.  It does not require
a lot of resources.

> What I percieve a lot in this thread are variations of "I wanna stay in
> bed for five more minutes mommy". I wonder if Werner and Robert should

:-)


Salam-Shalom,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgp_g3ouGxfYj.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

end-of-life announcements (was: Breaking changes)

[Werner Koch]

On Wed, 23 May 2018 13:56, d...@kegel.com said:

>> So when talking about EOL, gpg community should consider writing down a 
>> consistent EOL strategy, similar to those of Ubuntu, Linux kernel or others 
>> or something like I tried to argue for in the middle of 
>> https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060539.html
>
> Yes, exactly!

We announce EOL early.  Check the AUTHOR file of each package.  For
example Libgcrypt 1.7:

  Library: Libgcrypt
  [...]
  End-of-life: 2019-06-30

That was set with the last release (1.7.9) on 2017-08-27.  Two years are
pretty long given that even the new branches are ABI and API compatible.

For GnuPG 2.2 the things are not that easy.  We knew that we would need
a longer transition period, thus despite that 2.1.0 would have been a
development version, we urged people to start using 2.1 asap.  This was
due to the fact that many distributions still used the legacy 1.4 and
not the stable 2.0.

> To be kind to enterprise customers, GnuPG could pick one of
> those two dates as the EOL for 1.4.  Matching 16.04's EOL

There is no EOL planned for 1.4 but 1.4 shall not be used except when
you need compatiblity for the broken PGP 2 or you have a very exotic and
ancient platform.  But in the latter case you have all kind of other
problems than to care about gpg versions.

> Also, gnupg.org should add a web page like
> https://www.gnupg.org/release-end-of-life

Good idea.  However, I think it is better to add it to the download
page.  Which I just did:

   PackageBranch  Birth   End-of-life  EOL 
  -
   GnuPG  1.0 1999-09-07  2002-09-07   yes 
  1.2 2002-09-21  2005-01-01   yes 
  1.4 2004-12-16  (1)  
  2.0 2006-11-11  2017-12-31   yes 
  2.2 2014-11-06  tba  
   Libgcrypt  1.5 2011-06-29  2016-12-31   yes 
  1.6 2013-12-16  2017-06-30   yes 
  1.7 2016-04-15  2019-06-30   
  1.8 2017-07-18  tba  

  tba: To be announced.
  (1): Legacy version; see remarks above.


Shalom-Salam,

   Werner


-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgp2WAdp2UY1a.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

AW: Breaking changes

[Fiedler Roman]

> Von: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] Im Auftrag von
> Ralph Seichter
> 
> This thread really has me pulling my hair--what's left of it. Some core
> aspects from where I am standing:
> 
> 1. GPG is maintained by volunteers. If you have any complaint about how
> this maintenance is progressing, get off your behind and be a volunteer
> yourself, or failing that, provide an incentive--money would be nice--to
> existing volunteers. See also: Gift horses, not looking in the mouth of.
> ...
> Get off your collective bums and out of bed, children! ;-)

Well, I quite invested some time in trying to argue for optimization of 
different parts of the gnupg product strategy. I also tried to offer to 
participate in writing down use-cases, do requirement engineering and EOL 
procedure optimization, e.g. see bottom of [1]. Maybe you do not know, what 
effort is behind that, or maybe you do but such offers are of no value for 
gnupg community, as they do not match the current strategy or maybe there is 
some other reason I do not know about (but I am interested in) for your 
replying that way. 

LG Roman

[1] https://www.mail-archive.com/gnupg-users@gnupg.org/msg35222.html
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Breaking changes

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Tuesday 22 May 2018 at 3:34:40 AM, in
, Mirimir wrote:-



> So is there anything that gpg v2.2 won't decrypt with
> the option
> "--ignore-mdc-error" specified? Or perhaps, with also
> other "Doing
> things one usually doesn't want to do." options?


Yes. All support for v3 (PGP 2) keys was dropped with the release of
GnuPG 2.1.0 in 2014.


- --
Best regards

MFPA  

Teamwork is essential - it allows you to blame someone else
-BEGIN PGP SIGNATURE-

iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCWwX4cF8UgAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw
Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju
+uo3AQCtMeZYELrt0dxPJ2/982wdfTnO04wIIvGd7gtwQcfApAD9EeznreV3NAt7
S30relocNw+jc1UXdI6iIIeCYIuz+gaJApMEAQEKAH0WIQRSX6konxd5jbM7JygT
DfUWES/A/wUCWwX4cF8UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw
REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/z/RD/94TwkqVhjVBEzkoyHBu8EmY1XZ
86jLu/RBpuZGwLsmh45nfv69+MiiZz7IH89QbFZg5LSgQoJfJYzEbekLuPpnYgX2
+sA11NOd7hHaYtWQUsxx+YvfiMgf9jQxQ+SqSR/KfB8L7pJfHt3Ncwx12yDTzH/o
OzTxxDjmxtDLn/HtJgEIiYE/N0rCSgu03wUm4gEBTHlvWS0t8VUq9Dtany5AErA9
myiCRGQh4xokjKxp6W3kOS+v9YK6tGHl0WfZ5i93waQgw8A/8TDmt5//GuXHlkBv
STovntaIsy5ff6CGvCiKJzJF45ZmZA8CY/8jhc6y1rLNAgcIL4BA3NlAEajnht7e
qv86I8SHt/vHlf93iFENuBzzDntQAoaTZN3+YF2q7zx7aW4+eUAksJVLMWZcu9vG
LojOo3E9EBAcCqGodocI4i3mILxmwpGgsuJ3hJyQIg7D6j5vZ5jibj3ZXxv0Lt88
5THKVL3cF3/opENbTMPwZyG7x3R4lpuXjhZW0e80ZACIGKUJpTuQzViCw+KvDXi1
KrfTU+51zeHwmvS/FM9Hc+6udgEYH0kGnb0Q1Xued5FFciqy6vHBCM2ufxXi0zJZ
Gw2bxiFaZAZMzLfJCl5qwFoNe3U9O7d814/fFvv91pGLwxZENzEEuF44SaXMKOAb
ep3TVC9W8Tls03P8Ag==
=kSU/
-END PGP SIGNATURE-


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Breaking changes

[Robert J. Hansen]

> What I percieve a lot in this thread are variations of "I wanna stay in
> bed for five more minutes mommy". I wonder if Werner and Robert should
> charge 5 EUR for every incident of whining to secure some funds?

First, I am in *no way* important to GnuPG's future.  I maintain a FAQ,
field questions, and for the last couple of weeks have been a PR flack.
Many other people do more for GnuPG than I do, and Werner does the most.
 Please, keep that in mind.  :)

Second, 1.4 isn't requiring huge resources to maintain -- it's a fairly
small drain.  But when problems occur, suddenly we have to track them
down, fix them, test them, and release them in two branches, not one.
So it's when dev time is most important -- security problems -- that the
continued existence of 1.4 is most taxing.  Just a thought to consider.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Breaking changes

[Ralph Seichter]

This thread really has me pulling my hair--what's left of it. Some core
aspects from where I am standing:

1. GPG is maintained by volunteers. If you have any complaint about how
this maintenance is progressing, get off your behind and be a volunteer
yourself, or failing that, provide an incentive--money would be nice--to
existing volunteers. See also: Gift horses, not looking in the mouth of.

2. GPG 1.4 will not suddenly vanish if it is no longer maintained.
People can still use it like before. Maybe they shouldn't, but they can.

3. GPG 1.4 has been outdated for what amounts to ages in terms of
software life cycles. Whoever has not migrated so far will also not
migrate if you give him another 6 or 12 months. While everybody is free
to stick with 1.4, nobody is required to waste resources on maintenance
efforts, unless it gives him some strange pleasure to do so. I think
that only a fait accompli in the form of dropping version 1.4 support
will push the procrastinators in management to release necessary funds.

What I percieve a lot in this thread are variations of "I wanna stay in
bed for five more minutes mommy". I wonder if Werner and Robert should
charge 5 EUR for every incident of whining to secure some funds?

Get off your collective bums and out of bed, children! ;-)

-Ralph

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Breaking changes

[Dan Kegel]

On Tue, May 22, 2018 at 10:24 PM, Fiedler Roman  wrote:
>> https://en.wikipedia.org/wiki/GNU_Privacy_Guard
>> already give an end-of-life date for 2.0, but none for 1.4.
>> And since Ubuntu 16.04 includes 1.4, there are likely
>> to still be a few vocal 1.4 users out there.
>>
>> How about announcing an end-of-life date for 1.4 that
>> is in the future (say, by 3 to 6 months)?
>
> In my opinion, just "announcing" EOL (especially with such a short notice) is 
> quite bad practice for products aiming to be used in production setups also. 
> This quite negatively affects trust into the product as your costs may change 
> quite rapidly. You might argue, that companies should be used to paying for 
> things. They are, but they want to have some planning when they are expected 
> to pay. Would you like your car manufacturer announce, that your car is not 
> secure any more in 6 month and that you have to pay for non-standard 
> maintenance, if you still want to operate it securely?
>
> Apart from that: some companies using open source software are non-profit 
> companies, like mine in research business. If our software strategy is bad - 
> e.g. because upstream forces us suddenly to switch/pay, where we did not 
> expect it - research funding money (mostly from the society) has to be used 
> to keep the projects running.
>
> So when talking about EOL, gpg community should consider writing down a 
> consistent EOL strategy, similar to those of Ubuntu, Linux kernel or others 
> or something like I tried to argue for in the middle of 
> https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060539.html

Yes, exactly!

And taking a look at https://www.ubuntu.com/info/release-end-of-life,
one sees that Ubuntu 12.04 and 14.04 have a final end of life in about
February 2019;
16.04 lives until Feb 2021.

To be kind to enterprise customers, GnuPG could pick one of
those two dates as the EOL for 1.4.  Matching 16.04's EOL
would strand the fewest users, but even just matching 14.04's
would make sense to a lot of people.

Also, gnupg.org should add a web page like
https://www.gnupg.org/release-end-of-life
that lays out the EOL for all released versions;
the only one with a clear EOL is 2.0.x, and that's a bit buried in
text on the front page.
- Dan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

AW: Breaking changes

[Fiedler Roman]

> Von: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] Im Auftrag von
>
> Lessee...
> https://en.wikipedia.org/wiki/GNU_Privacy_Guard
> already give an end-of-life date for 2.0, but none for 1.4.
> And since Ubuntu 16.04 includes 1.4, there are likely
> to still be a few vocal 1.4 users out there.
>
> How about announcing an end-of-life date for 1.4 that
> is in the future (say, by 3 to 6 months)?
> ...

In my opinion, just "announcing" EOL (especially with such a short notice) is 
quite bad practice for products aiming to be used in production setups also. 
This quite negatively affects trust into the product as your costs may change 
quite rapidly. You might argue, that companies should be used to paying for 
things. They are, but they want to have some planning when they are expected to 
pay. Would you like your car manufacturer announce, that your car is not secure 
any more in 6 month and that you have to pay for non-standard maintenance, if 
you still want to operate it securely?

Apart from that: some companies using open source software are non-profit 
companies, like mine in research business. If our software strategy is bad - 
e.g. because upstream forces us suddenly to switch/pay, where we did not expect 
it - research funding money (mostly from the society) has to be used to keep 
the projects running.

So when talking about EOL, gpg community should consider writing down a 
consistent EOL strategy, similar to those of Ubuntu, Linux kernel or others or 
something like I tried to argue for in the middle of 
https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060539.html


As another poster already argued on boosting migration by pushing stronger for 
elliptic curve cryptography: This is very likely to motivate end users to 
migrate. For businesses it might be not so much: ECC within gpg is not yet 
approved for all kind of applications (no in-depth audit reports available 
yet), so RSA use will still be common for quite a time. Apart from that: due to 
the missing EOL strategy (see above) and the growing gpg complexity (and 
risks), for example we are currently experimenting using ECC without GPG for 
automation purposes (using the underlying crypto libraries more directly).

Maybe production use of gnupg might not be a priority for gnupg in future. This 
might free resources otherwise needed for thinking about a sensible 
EOL-strategy or migration pathes. On the other hand, you might also lose 
feedback from audit reports/pen-testing/bug reports, which is sometimes only 
available from production (how many end user can reliable capture a crash every 
10k hours of continued operation and distinguish it (with acceptable 
probabilities) from a hardware-related, hosting/virtualization infrastructure 
or silent kernel data corruption issue).


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Breaking changes

[Ben McGinnes]

On Tue, May 22, 2018 at 05:47:43AM -0400, Robert J. Hansen wrote:
> > Get real. These people are long-time GnuPG users and now you want to
> > throw them under the bus because... well, because you prefer it that
> > way.
> 
> 1.4 was deprecated the instant 2.0 was released.  After much pushback it
> was agreed to continue supporting 1.4.

To be fair, 2.0 wasn't so happy on all platforms ... which is why I
completely skipped it (save for one attempt to use 2.0 somewhere in
the middle and one subsequent attempt to use 2.0's gpg-agent with 1.4;
the former failed and the latter worked for a bit and then imploded)
and only migrated once 2.1 was a thing.

> But after fourteen years it's time to end it so that Werner's
> limited time can be fully devoted to the 2.3 branch.

Yes, well that's fair.

> > Err... the specialised solution surely is GnuPG 1.4.
> 
> Yes.  And the code will still be around.  It will just no longer be
> maintained.  If it's that important to you, you should consider
> maintaining it yourself or paying someone to maintain it.

Well, if the use case is solely accessing archived data (my use case
for keeping it to hand or the code handy) then it's less a matter of
maintaining the code base and more a case of, "as long as it compiles
from now until whenever and behaves as it did, then it can access the
data I need it for" and anything beyond that is just a bonus.

> Well... no.  It doesn't work that way.  Werner gets to work on what he
> wants to work on, and I think the best bang for the buck,
> community-wise, is 2.3.

Yep.

> But if Werner were to say tomorrow, "I'm done, guys, I'm going to go
> sell ice cream on the beach," I'd just say thank you, wish him well, and
> wonder where the beaches were in Germany.

Well it depends on which river, I guess.  No one said beaches had to
be by the seaside; that's just a conceit which has been largely
supported by English literature.

> > Isn't that effectively equivalent to commercial sponsors taking
> > previously open source code base private? It's hardly a popular move
> > when it happens.
> 
> Nope.  1.4 will still be out there, just unsupported.

Not to mention the little fact that all this code has been released
under the current dual licenses for a *very* long time and those
licenses aren't going to be broken now.

> No.  I'm well past the point where I care about how vocal a fringe
> minority is.  It's unwise to make engineering decisions based on the
> volume made by a small number of people.

Plus while some of us may even still have certain archives which do
require the possibility of using old keys, we also generally knew
about it for quite a while and thus were already aware that 1.4 was
the solution and maintenance was infrequent with no guarantees.  The
solution was to use it on that basis and/or migrate data and if the
latter isn't possible (e.g. for legal or historical preservation
reasons) then make sure you know what you're doing in house with the
code that is available.

From my POV, as someone who still has a working copy of his original
v2 key; even EOL'ing 1.4 would change nothing.  I can think of some
reasons why it might do bad things, but the flip side to that is the
1.4 code is a lot simpler (and self-contained), so anyone with a
really scary need to maintain it should hire g10code or their own
dedicated in house specialists (or both).

I expect national archives and libraries will also keep copies handy
for the performance of their legally mandated tasks in preserving the
historical record (and if a public archive of a mailing list includes
messages with signatures from v2 keys, that's the ball game from their
POV and the law is the law).  Still, those types of organisations are
used to employing specialists in accessing legacy formats and properly
archiving data, so I doubt they'll complain.

It's hard to care about anything beyond that, though and I'm sure it
will be a very long time before we see 1.4 not compiling on
something at all.  Maybe double-check after January, 2038 just in
case, but otherwise — meh.


Regards,
Ben


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Breaking changes

[Ben McGinnes]

On Wed, May 23, 2018 at 01:22:41AM +0200, Leo Gaspard via Gnupg-users wrote:
> On 05/22/2018 11:48 PM, Dennis Clarke wrote:
> > On 05/22/2018 05:38 PM, Dan Kegel wrote:
> >> Lessee...
> >> https://en.wikipedia.org/wiki/GNU_Privacy_Guard
> >> already give an end-of-life date for 2.0, but none for 1.4.
> >> And since Ubuntu 16.04 includes 1.4, there are likely
> >> to still be a few vocal 1.4 users out there.
> >>
> >> How about announcing an end-of-life date for 1.4 that
> >> is in the future (say, by 3 to 6 months)?
> > 
> > Too fast. Think 12 months as a minimum. There is prod code
> > out there running for years and a timeline that allows proper
> > project schedule/costing/testing would be better.
> 
> If the announced end-of-life is 12 months, then people will complain for
> 9 months, and maybe start working on migrating during the last 3 months.

Depends on the size of the organisation really, but yes there would be
complaints if the code retained explicitly for accessing pre PGP 5
keys and data as well as running on certain types of headless systems
(e.g. routers) were to be terminated in a short period of time.

Which is why I doubt 1.4 will be EOL'd, but the existing policy of not
updating it without a massively hugely justified reason and the
ongoing and strong encouragement of migrating to 2.2.

Anyway, even if this wish to expunge 1.4 were to be realised, it still
would remain available in some form no matter what.  This is because
the GnuPG Project uses git and the 1.4 code, the 2.0 code, the 2.1
code and the 2.2 code is all in the same repo with different branches
and tags and so on.  Anyone even vaguely worried about losing 1.4
(don't worry, we're not revisionists) only needs to clone the whole
repo somewhere and git being git, that's the entire job done.

> I mean, I'm still seeing people actively developing python2 code
> bases without even thinking of migrating to python3 *now*, and
> retirement was initially announced for 2015…

Yeah, the Py2 EOL extension was a bit excessive.  Frankly it should've
just been pegged to when Twisted was migrated and then paying them to
do it faster.

At least with GPGME's Python stuff when faced with a 2 versus 3
decision it was pretty simple: we're going with 3, albeit with a
degree of support for 2.7 (i.e. it works in 2.7, but all the examples
and instructions are written for 3).

> The longer you leave people with maintenance, the longer they will want
> maintenance past the deadline.

Well, I can't argue with that after seeing what Sun's customers did.

> I think 3-6 months is more than enough, and if people can't manage to
> update their production code in this time frame they can live with an
> un-maintained GnuPG until they finish migrating (unless they want to pay
> for paid support for continued 1.4 maintenance, that is).

I think you might be overestimating your familiarity with all
industries which might be running it and any cases where hardware
limitations or certification requirements are a factor expecially if
that includes organisations which aren't, strictly speaking, standard
commercial or non-profit organisations.  Plus I would be rather
unsurprised to learn that there were live systems utilising 1.4 in
some way which really needed to remain running no matter what and if
it didn't then the people in the relevant region might legitimately
complain about losing power or water supply or whatever.

Do I know that sort of thing is going to be a guaranteed case?  No.
Still, as you say, 1.4 has been active for a long time and has no
doubt spread to all sorts of interesting use cases by now.  In this
case setting a short EOL to try to force change may not produce the
result you wanted.

> I don't have a personal opinion, but dropping 1.4 appears to have two
> advantages to me: first, it reduces the voluntary maintenance
> burden,

Given how little that active burden currently is, it may not save that
much and appears to be mostly backports of certain major issues which
were first fixed in a more recent release.

> and second, it may help gather funding for work on 2.3, if people choose
> to contract with g10code for continued maintenance.

That sounds rather deceptive; charging someone for maintenance of a
specific product and instead of spending that on the thing they're
paying for then spending it on a totally different thing that they're
willing to pay to avoid having to migrate to.

> GunPG 1.4 has been out for way longer than necessary, and people are
> never going to migrate out of it unless they are forced to.

There's a far easier way to ensure that migration without
disadvantaging legitimate archival needs and it will be largely pushed
by the other end users: that being when the shift to elliptic curve
keys becomes standard and possibly even if it becomes a default
configuration (though I expect to see more hybrid keys such as RSA
primary keys and either curve subkeys or a mix of curves and
asymmetric subkeys first).


Regards,
Ben



si

Re: Breaking changes

[Dennis Clarke]

On 05/22/2018 08:21 PM, Robert J. Hansen wrote:

If the announced end-of-life is 12 months, then people will complain for
9 months, and maybe start working on migrating during the last 3 months.


You're an optimist.  For any EOL date, a vast number of users ...


The real issue is the vast gulf between management and tech people and
there needs to be a middle layer with decades of experience to keep the
whole show functional.

Dennis


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Breaking changes

[Robert J. Hansen]

> If the announced end-of-life is 12 months, then people will complain for
> 9 months, and maybe start working on migrating during the last 3 months.

You're an optimist.  For any EOL date, a vast number of users will
simply *not migrate* until they stop getting updates.  The reason why is
they're not subscribed to mailing lists.  We could announce tomorrow's
lottery numbers and they wouldn't notice.

I'm fine with a 12-month EOL date.  It's more important that an EOL date
be made and enforced than it be any particular date.  Whether it's three
months, six months, twelve, I don't care, *so long as it gets done*.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Breaking changes

[Leo Gaspard via Gnupg-users]

On 05/23/2018 01:40 AM, Dennis Clarke wrote:>> The longer you leave
people with maintenance, the longer they will want
>> maintenance past the deadline.
>>
> 
> [1] Then a service org should exist that charges fees.

This service org already exists, is named in the message you replied to,
and is called g10code.

>> I think 3-6 months is more than enough, and if people can't manage to
>> update their production code in this time frame 
> 
> Perhaps you don't understand the complexity of a multi-tier prod env
> with many architectures and vendors and a lot of transaction sensitive
> code in place.

I think I do. Such large production environments can afford paying for
maintenance of what is currently GnuPG 1.4 until they complete migration.

> ps: see [1] as a purchase order happens real fast sometimes with the
>  right people involved. If Bruce Schneier says $250k then fine
>  it gets done. Business as usual.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Breaking changes

[Dennis Clarke]

How about announcing an end-of-life date for 1.4 that
is in the future (say, by 3 to 6 months)?


Too fast. Think 12 months as a minimum. There is prod code
out there running for years and a timeline that allows proper
project schedule/costing/testing would be better.


If the announced end-of-life is 12 months, then people will complain for
9 months, and maybe start working on migrating during the last 3 months.



Not interested.



I mean, I'm still seeing people actively developing python2 code bases
without even thinking of migrating to python3 *now*, and retirement was
initially announced for 2015…


off topic.



The longer you leave people with maintenance, the longer they will want
maintenance past the deadline.



[1] Then a service org should exist that charges fees.


I think 3-6 months is more than enough, and if people can't manage to
update their production code in this time frame 


Perhaps you don't understand the complexity of a multi-tier prod env
with many architectures and vendors and a lot of transaction sensitive
code in place.

Dennis

ps: see [1] as a purchase order happens real fast sometimes with the
 right people involved. If Bruce Schneier says $250k then fine
 it gets done. Business as usual.




___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Breaking changes

[Leo Gaspard via Gnupg-users]

On 05/22/2018 11:48 PM, Dennis Clarke wrote:
> On 05/22/2018 05:38 PM, Dan Kegel wrote:
>> Lessee...
>> https://en.wikipedia.org/wiki/GNU_Privacy_Guard
>> already give an end-of-life date for 2.0, but none for 1.4.
>> And since Ubuntu 16.04 includes 1.4, there are likely
>> to still be a few vocal 1.4 users out there.
>>
>> How about announcing an end-of-life date for 1.4 that
>> is in the future (say, by 3 to 6 months)?
> 
> Too fast. Think 12 months as a minimum. There is prod code
> out there running for years and a timeline that allows proper
> project schedule/costing/testing would be better.

If the announced end-of-life is 12 months, then people will complain for
9 months, and maybe start working on migrating during the last 3 months.

I mean, I'm still seeing people actively developing python2 code bases
without even thinking of migrating to python3 *now*, and retirement was
initially announced for 2015…

The longer you leave people with maintenance, the longer they will want
maintenance past the deadline.

I think 3-6 months is more than enough, and if people can't manage to
update their production code in this time frame they can live with an
un-maintained GnuPG until they finish migrating (unless they want to pay
for paid support for continued 1.4 maintenance, that is).

I don't have a personal opinion, but dropping 1.4 appears to have two
advantages to me: first, it reduces the voluntary maintenance burden,
and second, it may help gather funding for work on 2.3, if people choose
to contract with g10code for continued maintenance.

GunPG 1.4 has been out for way longer than necessary, and people are
never going to migrate out of it unless they are forced to.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Breaking changes

[Dennis Clarke]

On 05/22/2018 05:38 PM, Dan Kegel wrote:

Lessee...
https://en.wikipedia.org/wiki/GNU_Privacy_Guard
already give an end-of-life date for 2.0, but none for 1.4.
And since Ubuntu 16.04 includes 1.4, there are likely
to still be a few vocal 1.4 users out there.

How about announcing an end-of-life date for 1.4 that
is in the future (say, by 3 to 6 months)?


Too fast. Think 12 months as a minimum. There is prod code
out there running for years and a timeline that allows proper
project schedule/costing/testing would be better.

Dennis

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Breaking changes

[Dan Kegel]

Lessee...
https://en.wikipedia.org/wiki/GNU_Privacy_Guard
already give an end-of-life date for 2.0, but none for 1.4.
And since Ubuntu 16.04 includes 1.4, there are likely
to still be a few vocal 1.4 users out there.

How about announcing an end-of-life date for 1.4 that
is in the future (say, by 3 to 6 months)?

That would avoid poking classic users in the eye too hard,
and give time for them to get used to the idea.
- Dan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

AW: Breaking changes

[Ernst-Udo Wallenborn]

> -Ursprüngliche Nachricht-
> Von: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] Im Auftrag von Ralph 
> Seichter
> Gesendet: Dienstag, 22. Mai 2018 12:59
>
> On 22.05.18 03:42, Mark Rousell wrote:
> 
> > Preventing users from encrypting new data using legacy encryption does
> > NOT need to mean that other users have to be prevented from (quite
> > legitimately) accessing archived data using legacy encryption with
> > maintained software.
> 
> Who said "have to be prevented"? Please keep in mind that GPG is
> maintained on a voluntary basis. If the people who do the actual work
> decide to not maintain outdated software anymore, so they can focus
> their limited resources on current releases, they are completely free
> to do so and don't deserve to be chastised for the decision.


I'd favour a pragmatic approach, drawing the line depending on the state of 
technology: we all know that encryption does not provide absolute security; it 
provides relative security for a limited time. Relative because it depends on 
the means the adversary has, and limited time because of technological progress.

Old files encrypted with a method that is trivially crackable today are 
actually not encrypted, they're just encoded in a fancy way. Users with such 
files should reevaluate their encryption strategy, and not depend on gnupg to 
be a permanent decoding tool. But on the other hand, email encryption can never 
clean up as radically as TLS1.3, because it has to provide protection for 
data-at-rest, too, which TLS doesn't have to address. So unless an algorithm is 
completely broken, it should stay supported, at least for decryption.

-- 
Ernst-Udo Wallenborn
Pgp   22FB 1CB2 82D8 A903 A289 053B 4015 1361 6040 82F7




___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Breaking changes

[Ralph Seichter]

On 22.05.18 03:42, Mark Rousell wrote:

> Preventing users from encrypting new data using legacy encryption does
> NOT need to mean that other users have to be prevented from (quite
> legitimately) accessing archived data using legacy encryption with
> maintained software.

Who said "have to be prevented"? Please keep in mind that GPG is
maintained on a voluntary basis. If the people who do the actual work
decide to not maintain outdated software anymore, so they can focus
their limited resources on current releases, they are completely free
to do so and don't deserve to be chastised for the decision.

If somebody wants support for old GPG versions, they can damn well pay
people for that. In more than three decades in this business I have seen
too many users who think that paying for software licenses and upkeep
is an inconvenience, and who take open source software for an all-you-
can-gobble buffet without a thought for the authors. I am not implying
you are one of these people, mind you.

-Ralph

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Breaking changes

[Robert J. Hansen]

> Get real. These people are long-time GnuPG users and now you want to
> throw them under the bus because... well, because you prefer it that
> way.

1.4 was deprecated the instant 2.0 was released.  After much pushback it
was agreed to continue supporting 1.4.  But after fourteen years it's
time to end it so that Werner's limited time can be fully devoted to the
2.3 branch.

> Err... the specialised solution surely is GnuPG 1.4.

Yes.  And the code will still be around.  It will just no longer be
maintained.  If it's that important to you, you should consider
maintaining it yourself or paying someone to maintain it.

> So you are saying that long-time users should be deprived of an open
> source ongoing-maintained solution to their entirely valid present day
> use case to benefit a private company.

Why do you feel you have the right to make Werner work for you for free?

That's what you're saying here.  "I'm not paying a dime and I insist on
my legacy package getting highly professional work done on it for free."

Well... no.  It doesn't work that way.  Werner gets to work on what he
wants to work on, and I think the best bang for the buck,
community-wise, is 2.3.

But if Werner were to say tomorrow, "I'm done, guys, I'm going to go
sell ice cream on the beach," I'd just say thank you, wish him well, and
wonder where the beaches were in Germany.

> Isn't that effectively equivalent to commercial sponsors taking
> previously open source code base private? It's hardly a popular move
> when it happens.

Nope.  1.4 will still be out there, just unsupported.

> Surely if you can recognise that people will start screaming then you
> must also understand that it is entirely the wrong thing to do.

No.  I'm well past the point where I care about how vocal a fringe
minority is.  It's unwise to make engineering decisions based on the
volume made by a small number of people.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Breaking changes

[Mirimir]

On 05/21/2018 02:57 PM, Mark Rousell wrote:
> On 22/05/2018 02:39, Mark Rousell wrote:
>> Get real. These people are long-time GnuPG users and now you want to
>> throw them under the bus because... well, because you prefer it that
>> way. No, that's not a fair, it's not reasonable, it's not ethical, or
>> it's even professional. [etc etc]
> 
> On re-reading the above message, I apologise if the language I used was
> provocative. However, the points I made are nevertheless valid in my
> opinion.

Hey :)

> Proposing cutting off maintenance of the only maintained route to
> decrypt certain data is provocative, of course. ;-) As I observed, it is
> not necessary to cut off maintained ability to decrypt historical data
> (surely a valid real world use case) in order to prevent users from
> encrypting new data with legacy standards.

So is there anything that gpg v2.2 won't decrypt with the option
"--ignore-mdc-error" specified? Or perhaps, with also other "Doing
things one usually doesn't want to do." options? That is, are older
versions really necessary?

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Breaking changes

[Mark Rousell]

On 22/05/2018 02:39, Mark Rousell wrote:
> Get real. These people are long-time GnuPG users and now you want to
> throw them under the bus because... well, because you prefer it that
> way. No, that's not a fair, it's not reasonable, it's not ethical, or
> it's even professional. [etc etc]

On re-reading the above message, I apologise if the language I used was
provocative. However, the points I made are nevertheless valid in my
opinion.

Proposing cutting off maintenance of the only maintained route to
decrypt certain data is provocative, of course. ;-) As I observed, it is
not necessary to cut off maintained ability to decrypt historical data
(surely a valid real world use case) in order to prevent users from
encrypting new data with legacy standards.



-- 
Mark Rousell

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Breaking changes

[Mark Rousell]

On 21/05/2018 10:46, Ralph Seichter wrote:
> On 21.05.18 07:20, Robert J. Hansen wrote:
>
>> We should keep the 1.4 source code available, but wash our hands of it
>> and say it will receive *no* future fixes, not even for security
>> issues -- and we need to stand on that when people start screaming.
> I agree. In my experience, this stance--publicly documented--will allow
> people to say to their bosses "support has ended, and for security
> reasons we now need a budget to finance a move away from this outdated
> software". I have seen similar situations often enough; nobody would
> spend money as long as the old software horse was still twitching.
>
> Discontinue version 1.4 right away, quoting Efail as a trigger if you
> wish, and set an EOL for version 2.0 in a few months, as you suggested.

It's not that simple. There are more use cases to take into account.
Whilst what you say is true for people still encrypting new data with
1.4 (and I agree that they should be prevented from doing so), there are
other people (perhaps even more people) who have a legitimate need to
access historical/archival encrypted data.

Preventing users from encrypting new data using legacy encryption does
NOT need to mean that other users have to be prevented from (quite
legitimately) accessing archived data using legacy encryption with
maintained software.

-- 
Mark Rousell

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Breaking changes

[Mark Rousell]

On 21/05/2018 06:20, Robert J. Hansen wrote:
> Here's my own set of suggestions for breaking changes to GnuPG:
>
> 1.  End-of-life 1.4 already.
>
> Yes, it's the only option for PGP 2.6.  Yes, it's the only option for
> old and out-of-date stuff.  Yes, there will be people who need to
> decrypt this stuff.  All of that is true, but *we* don't need to be the
> people who cater to their needs.

Get real. These people are long-time GnuPG users and now you want to
throw them under the bus because... well, because you prefer it that
way. No, that's not a fair, it's not reasonable, it's not ethical, or
it's even professional.

> At this point if you need pre-Web
> crypto (which, I remind people, is pretty much what PGP 2.6 is), you
> have a specialized need and you need to talk to someone about a custom
> solution.

Err... the specialised solution surely is GnuPG 1.4.

> There are companies that specialize in this sort of thing
> (like, say, g10 Code).

So you are saying that long-time users should be deprived of an open
source ongoing-maintained solution to their entirely valid present day
use case to benefit a private company.

Isn't that effectively equivalent to commercial sponsors taking
previously open source code base private? It's hardly a popular move
when it happens.

Yes, I know that the scenario you are proposing is not /exactly/ the
same but people will, quite understandably, treat it as such.

> We should keep the 1.4 source code available, but wash our hands of it
> and say it will receive *no* future fixes, not even for security issues
> -- and we need to stand on that when people start screaming.

Surely if you can recognise that people will start screaming then you
must also understand that it is entirely the wrong thing to do.

> Rationale: as long as we keep GnuPG 1.4 around and even semi-supported,
> people will insist on not upgrading.

If you drop maintenance of code that can handle the data that some
people need to cope with then they will naturally have to stay with old,
unmaintained code anyway. So dropping maintenance of 1.x will only cause
a problem in this respect, not cure on.

If you are (understandably) concerned about people still use 1.4 for
encryption of new data then the sensible choice is surely to do what
people have suggested in this thread: That is to produce a
decryption-only maintained version that still allows users who need to
access archived legacy-encrypted data to do so.

Clearly you are concerned with preventing people using legacy encryption
for new data and I agree with this concern. But there is no need to
throw present day, long-time users who must handle legacy-encrypted data
under the bus to do so.


-- 
Mark Rousell

PGP public key: http://www.signal100.com/markr/pgp
Key ID: C9C5C162
 
 
 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Breaking changes

[Ralph Seichter]

On 21.05.18 07:20, Robert J. Hansen wrote:

> We should keep the 1.4 source code available, but wash our hands of it
> and say it will receive *no* future fixes, not even for security
> issues -- and we need to stand on that when people start screaming.

I agree. In my experience, this stance--publicly documented--will allow
people to say to their bosses "support has ended, and for security
reasons we now need a budget to finance a move away from this outdated
software". I have seen similar situations often enough; nobody would
spend money as long as the old software horse was still twitching.

Discontinue version 1.4 right away, quoting Efail as a trigger if you
wish, and set an EOL for version 2.0 in a few months, as you suggested.

> Let's get all the breaking pain over at once, and put GnuPG on track
> for the future.

People are going to be (temporarily) very annoyed anyway, so go all the
way. Like Ferdinand von Schill said: "Lieber ein Ende mit Schrecken als
ein Schrecken ohne Ende."

-Ralph

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Breaking changes

[Damien Goutte-Gattat via Gnupg-users]

On 05/21/2018 06:20 AM, Robert J. Hansen wrote:
> 2.  End-of-life 2.0.

That one at least is already done. The 2.0 branch reached EOL with the
2.0.31 release on December 29, 2017. I believe Werner stated clearly
enough that there will be *no* further point release on that branch, not
even for critical security fixes. If a distro is currently shipping a
2.0.x version, backporting any such security fix will be left to the
packagers/maintainers for that distro.

The last release of the 2.0.x branch is not even listed anymore on
gnupg.org's download page.


Damien



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Breaking changes

[Robert J. Hansen]

Here's my own set of suggestions for breaking changes to GnuPG:

1.  End-of-life 1.4 already.

Yes, it's the only option for PGP 2.6.  Yes, it's the only option for
old and out-of-date stuff.  Yes, there will be people who need to
decrypt this stuff.  All of that is true, but *we* don't need to be the
people who cater to their needs.  At this point if you need pre-Web
crypto (which, I remind people, is pretty much what PGP 2.6 is), you
have a specialized need and you need to talk to someone about a custom
solution.  There are companies that specialize in this sort of thing
(like, say, g10 Code).

We should keep the 1.4 source code available, but wash our hands of it
and say it will receive *no* future fixes, not even for security issues
-- and we need to stand on that when people start screaming.

Rationale: as long as we keep GnuPG 1.4 around and even semi-supported,
people will insist on not upgrading.

2.  End-of-life 2.0.

2.2 is the replacement branch for 2.0, and it's been around for ten
months.  Yes, some major distros have incorporated 2.0 into their
long-term support releases.  That's on them, *not* us.  State, "we're
going to continue to give security fixes to 2.0 but that will end
December 31, 2018."

Rationale: 2.3 will be coming out soon.  I can understand supporting 2.2
and 2.3 simultaneously, but 2.0, 2.2, and 2.3 simultaneously seems like
we're dropping 1.4 just to pick up another boat anchor.

3.  In 2.3, make RFC4880bis04 the default.

There's a lot of good stuff in bis04.  Unfortunately, until the WG
restarts there's little in the way of implementations of it.  But it
still exists, and it's the safest thing we've got so far, so let's make
the cutover.  Include an --rfc4880 option for interoperability with
clients that aren't -bis04 compliant.

Rationale: we may only get one chance to make serious breaking changes,
so let's go big or go home.


Let me make it clear: these changes are extreme.  Some knowledgeable
people will say they're too extreme.  I disagree.  Let's get all the
breaking pain over at once, and put GnuPG on track for the future.  And
if defaulting to -bis04 puts pressure on other implementations to
support it, and/or puts pressure on the WG to approve it, well -- I'm
fine with that.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users