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: A postmortem on Efail

[Ben McGinnes]

On Mon, May 21, 2018 at 11:19:18AM -1100, Mirimir wrote:
> On 05/21/2018 02:31 AM, Ben McGinnes wrote:
>> 
>> https://ssd.eff.org/en/blog/pgp-and-efail-frequently-asked-questions
>> 
>> “What if I keep getting PGP emails?
>> 
>> You can decrypt these emails via the command line. If you prefer not
>> to, notify your contacts that PGP is, for the time being, no longer
>> safe to use in email clients and decide whether the conversation can
>> continue over another end-to-end encrypted platform, such as Signal.”
>> 
>> Because that couldn't possibly create a Chinese Whispers style
>> situation of self-perpetuating FUD … 🤦
> 
> I hadn't seen that. Pretty stupid :(

I can understand not having wanted to look too much farther after the
articles on the Deep Links blog, especially the second one on the
14th.  I'd been concentrating on something else and only paid it more
attention a bit later, so by that stage the article also included a
link at the end about the SSD updates and onward I clicked (with a
sense of dread).


Regards,
Ben


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

Re: A postmortem on Efail

[Ben McGinnes]

On Wed, May 23, 2018 at 12:15:58AM +0200, Steffen Nurpmeso wrote:
> 
> I only use v1.4, and i will never never never never use anything
> newer because that is very large and consists of an immense amount
> of components that i really do not need.  I receive keys via hkps://
> and sign, verify, encrypt and decrypt.  Having no pinentry is a bit
> of a problem, also because ~/ expansion is not possible in gpg.conf;
> but i have a small mkfifo program that feeds in the passphrase as
> appropriate, so this works for me.

Which is fine as long as no one you correspond with uses an elliptic
curve key when corresponding with you.  1.4 has no support for any of
the curves and they're not being backported to it.  In fact the last
time I tried doing anything at all with a key containing a curve even
just what was supposed to be optional subkeys, 1.4 had significant
problems doing anything with those keys.

That sort of thing is part of the reason for maintaining a separate
~/.gnupg1 directory which was my original, pre-migration directory
(combined with some shell scripts as wrappers which invoke the right
version with the right configuration and enabling this:

bash-4.4$ gpg1 --version
gpg (GnuPG) 1.4.22
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /Users/ben/.gnupg1
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
bash-4.4$ gpg --version
gpg (GnuPG) 2.2.7
libgcrypt 1.8.2
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /Users/ben/.gnupg2
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
bash-4.4$

Though I believe 1.4 may have been slightly modified and/or using
whatever was last added to its branch rather than actually be 1.4.22's
stable release.

Anyway, even though my current key doesn't yet include any of the
curves, I do still need more than a few components of the current
branches.  There are people I correspond with who use keys with
curves, I also definitely need GPGME and the its Python bindings (not
having them would make my work very tricky indeed).  Plus the boss is
a huge proponent of the modern branch and arguably its greatest
advocate.  😉


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

[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: A postmortem on Efail

[Steffen Nurpmeso]

Ben McGinnes  wrote:
 |On Tue, May 22, 2018 at 02:19:37AM +0100, Mark Rousell wrote:
 |> On 21/05/2018 13:34, Ben McGinnes wrote:
 |> 
 |>> I agree with most of the article and largely with the need to break
 ...
 |Mine too, it's why I keep a copy of 1.4 installed at all.  It's been a

I only use v1.4, and i will never never never never use anything
newer because that is very large and consists of an immense amount
of components that i really do not need.  I receive keys via
hkps:// and sign, verify, encrypt and decrypt.  Having no pinentry
is a bit of a problem, also because ~/ expansion is not possible
in gpg.conf; but i have a small mkfifo program that feeds in the
passphrase as appropriate, so this works for me.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

___
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

Re: A postmortem on Efail

[Ben McGinnes]

On Tue, May 22, 2018 at 02:19:37AM +0100, Mark Rousell wrote:
> On 21/05/2018 13:34, Ben McGinnes wrote:
> 
>> I agree with most of the article and largely with the need to break
>> compatibility to an ancient flawed design.  Particularly since we
>> still have a means of accessing those ancient formats if we have to in
>> the form of the GPG 1.4 branch.  The ancient archives are as safe as
>> they've ever been (for whatever definition of "safe" is being implied
>> by the user/archivist).
> 
> Indeed, this satisfies my archive retrieval concerns.

Mine too, it's why I keep a copy of 1.4 installed at all.  It's been a
while since I've needed to access something encrypted to the first key I
ever made way back in 1995, but I know there are archives which might
require it and possibly even some which have not already been migrated
to a newer key and encryption method.

That's okay, though and it doesn't need current dev practices to
retain those functions since there is a means of still opening that
door, even if I'm no longer using DOS and thus PGP 2.3a for DOS is no
longer available.  No doubt the worst issue would be sanitizing such
an old file of carriage returns or something like that.

Depending on what it was, though there may even be WordPerfect 5.1
files buried in those archives and IIRC LibreOffice dropped support
for those files a while back.  I suspect that sort of issue is more
likely to be a cause of angst for people needing to access old data
than whether they need to run GPG 1.4.x manually to decrypt it first.

>> There is, however, one aspect of this issue that you touched on
>> lightly, but didn't really delve into and which is at the centre of
>> my, mostly unvoiced (until this email), criticism of the Efail team.
>> That being the *incredibly* unhelpful and likely actively harmful
>> recommendation to remove encryption and decryption functionality from
>> vulnerable MUAs.
>>
>> To say, “we have this edge case scenario that really needs an active
>> targeted attack on a case by case basis, so everyone should just stop
>> integrating encryption” is the kind of thing that can get people
>> killed.
> 
> This has been commented on by a few people on this list, myself
> included: [1]

It gets mentioned here periodically, usually in conjunction with
discussions of differing threat models.

The EFF even have a great big section on their SSD site about
conducting your own risk or threat assessment and that these things
will be different for people in different circumstances.  Then they
decided to ignore their own advice in its entirety.

> To my mind, it reeks of slanted propaganda for Signal, and there
> does seem to be a lot of it around at the moment.

Hmm, maybe, but I'm not entirely certain that's instigated by Signal
or Whisper Systems.  No doubt they're enjoying it, but I think there's
another reason for that.

> Signal has security benefits but it's not (yet?) a replacement for
> encrypted email,

It's completely incapable of replacing either email or OpenPGP.  Here
are two things I do regularly or constantly which Signal is
fundamentally incapable of:

 1. Running my own server which enables me to set certain types of
 controls or filters on my own server and not shared with any third
 party (including Moxie).

 2. Encrypt files which are not intended to be sent to anyone and
 never were intended to be so.  The same is true of certain files
 which are digitally signed and archived in a way which lets me prove
 when they were written later (it's a copyright thing and set to
 specifically circumvent a particular niche of morons that are
 unrelated to the issue at hand).  Mostly, however, I mean things like
 keeping a journal and making damn sure that it won't be used against
 me.

Signal can't do any of that.  At all.  It also can't provide a genuine
means of establishing a pseudonymous identity unless you live in a
country that lets you buy lots of cheap "burner" phones and/or SIMs.

Maybe that is easy in the USA, maybe even elsewhere too.  It's pretty
much impossible in Australia.

So if there were something I needed to raise somewhere pseudonymously,
say via Tor and some web forum, what does the EFF suggest I use?
Signal?  How?

> whereas a number of commentators seem to treat it as if all email,
> encrypted or not, should be deprecated in favour of Signal. This is
> not sensible or good advice without considering individual use cases
> (regardless of Efail).

Absolutely!

I'm guessing that none of these commentators have ever actually
personally faced a threat which threatened their lives, especially as
part of some kind of minority, where the threat is both targeted and
impersonal simultaneously.  There are still millions of people in the
world facing torture or even death just because of something they were
born with (even something which may not be apparent until they reach a
certain point after birth).

In fact one minority I'm aware of is still so greatly at risk that
there's only on

Re: I just got an odd message

[Mirimir]

On 05/22/2018 12:41 AM, Andrew Gallagher wrote:
> On 22/05/18 07:30, Mirimir wrote:
>> Those are just screwed-up text-encoded images, right?
> 
> Without seeing the full email, it's hard to tell. They don't appear to
> represent any well-known file type when run through a base64 decoder.

I tried that too, for the full blocks, using online decoders, and got
nothing interpretable.

> Most uses of such constructions are hacks to get emails to display
> differently depending on the idiosyncracies of different readers, and I
> see plenty of them. But the text-encoded data does look odd.

In Thunderbird text mode, "DMMAwGuf 1hTVhVG5 OI0QBVgA ... cROBNJ3k
q9IZYLZM rP0GExKW RS" appeared as the message header. Where an image
might normally be.

The body is:

| BusinessStorage tank
|
| Dear Sir,.
|
| We are a foreign trading corporation with actual strength in Chengdu,
| We need to order many of Storage tank now.. I'd like to send
| you the picture of our need by’ the form of accessory, please find
| the attached file and offer us the Preferential price by the
| specifications of our picture..After receiving your offer price, I
| will contact you ASAP,and Negotiation cooperation details,I also hope
| that we can establish a long term cooperative relationship from now.
|
| Product : Storage tank ( name )
| Quantity: 50
|
| Please contact me by email if you need the specification of products’
| picture, I will send it to you because I often like to send message
| through email……Thanks
|
| We look forward to having a successful cooperation...F

So he _does_ refer to images.

> I grepped the last 500 days of my spam folder and found one instance
> from a long time back that closely matches the pattern of yours. It is
> missing the leading dashes and whitespace chunking but otherwise looks
> almost the same. It includes the domain name "wei wei gift dot com".
> 
> I see nothing in my example that screams "efail", but even so I am
> reluctant to open it in an HTML renderer to find out. ;-) It may simply
> be garbage intended to confound bayesian analysis.
> 
> YMMV

Thanks for checking. I'm curious enough that I'll put the HTML in a
LiveCD VM with no network connection, and see what Firefox does with it.

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

Re: Duplicate personal key in keyring

[Justin Hibbits]

Hi DIrk,

(Not subscribed to the list, so copied initial reply.  Top-posting so
mail readers will more easily filter)

My backup was simply a full copy of my .gnupg directory, so that I
could easily just destroy the new one and restore if anything failed.

I'll try your suggestion, thanks!

- Justin


Hello Justin.

Am Montag, den 21.05.2018, 11:25 -0500 schrieb Justin Hibbits:
> Through some unknown series of events, I now have two copies of my
> personal gpg key in my keyring.  I double-checked to see if GPG is
> seeing the same key in two keyrings (maybe reading a backup), but
> both
> keys are being read from the same keyring.

> This leads me to two questions:

> 1) How could this happen in the first place?

I had a similar problem a while ago. In my case the key database was
corrupted.


> 2) How can I fix this, short of generating a new key and revoking the
> existing key?

In my case I exported the public and the private keys of my own keys,
then exported the complete public key ring, both ascii armored.

Then I simply deleted the key database file(s) and re-imported the
exports.

GPG imports keys only once, so the duplicates should vanish when re-
importing.

> I've tried backing up the keyring and deleting one copy, but it
> deleted both copies.  I searched online for anyone else who had a
> similar issue, and came up empty, except for one person who was
> seeing the same key from two files.

Did you make an ascii armored export, or what kind of Backup do you
mean?

Regards,
Dirk

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

Break backwards compatibility already: itʼs time. Ignore the haters. I trust you.

[Reid Thompson]

Break backwards compatibility already: it’s time. Ignore the haters. I trust 
you.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Break backwards compatibility already: it’s time. Ignore the haters. I trust you.

[Reid Thompson]

Break backwards compatibility already: it’s time. Ignore the haters. I trust 
you.
___
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: A postmortem on Efail

[Mark H. Wood]

On Tue, May 22, 2018 at 01:42:07AM +0100, Mark Rousell wrote:
> On 21/05/2018 15:17, Mark H. Wood wrote:
> >> Break backwards compatibility already: it’s time. Ignore the haters. I
> >> trust you.
> > (I understand that that's a quote of a discussion-opener from the write-up.)
> >
> > I'd like to first see how many haters can be won over by selling the
> > necessary changes.
> >
> > By "selling" I mean addressing the concerns of those who aren't
> > convinced that they want something:
> >
> > o  Why this is important *to you*, even though its importance was not
> >immediately obvious.
> 
> To my mind it is at the outset counter-productive to refer to "haters".
> To use the term "haters" implies that anyone who does not share one's
> own view is somehow wrong and/or that their arguments can potentially be
> dismissed on the grounds or emotionalism rather than rationality.

*sigh*  Imagine that I wore a wry expression as I wrote that.  I think
 we are mostly in violent agreement.  I tend to play off of the
 wording of a previous statement when replying, especially when I want
 to bend the discussion in a different direction.

> In practice, those like myself who recognise that the ability to decrypt
> legacy-encrypted data is a basic requirement for many users with
> archival needs do not "hate" anything. We just recognise that decryption
> of legacy-encrypted data is a real world requirement right now and will
> continue to be for many years, and so I think it is right and proper for
> this project to continue to support this activity with maintained
> software (albeit with a requirement for users to make some changes to
> support such activity).

Yes.  I, too, have encrypted stuff from way back that I would like to
be able to read.  Addressing such needs is part of selling the
selected way forward.

Another part of selling is dialogue.  I see lots of confident
assertions about what we should do.  Is anyone taking this back to the
affected users to see if any of it makes sense to them?

> > o  What we have done, and are doing, to keep *your* cost down.
> 
> If the aim is to keep end-users' costs down then do not completely
> remove legacy features that are still needed in the real world.
> Decryption of legacy-encrypted data is one of those features, like it or
> not.

Yes, but don't just do it silently; tell people who need this that it
is being done, because of their concerns, and how it is being done.
Sell it.

> > o  What else would we need to do, to make this something *you* want?
> 
> Go back in time and change history!  [snip]

I was hoping for practical ideas which show that the community
understands the needs of all its members and is working to minimize
the cost of necessary evolution.  I'd like to be one community, but
apparently at the moment we are two.

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu


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

Re: I just got an odd message

[Andrew Gallagher]

On 22/05/18 07:30, Mirimir wrote:
> Those are just screwed-up text-encoded images, right?

Without seeing the full email, it's hard to tell. They don't appear to
represent any well-known file type when run through a base64 decoder.

Most uses of such constructions are hacks to get emails to display
differently depending on the idiosyncracies of different readers, and I
see plenty of them. But the text-encoded data does look odd.

I grepped the last 500 days of my spam folder and found one instance
from a long time back that closely matches the pattern of yours. It is
missing the leading dashes and whitespace chunking but otherwise looks
almost the same. It includes the domain name "wei wei gift dot com".

I see nothing in my example that screams "efail", but even so I am
reluctant to open it in an HTML renderer to find out. ;-) It may simply
be garbage intended to confound bayesian analysis.

YMMV

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
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

AW: AW: Break backwards compatibility already: it’s time. Ignore the haters. I trust you.

[Fiedler Roman]

> Von: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] Im Auftrag von
> 
> On 22/05/18 10:44, Fiedler Roman wrote:
> > Such a tool might then e.g. be used on a MitM message reencryption
> > gateway: the old machines still send messages with old
> > (deprecated/legacy options), they are transformed by "gpg-archive":
> > The full data (old message, old decrypt report, reencrypted
> > plaintext) go to the auditing storages, the reencrypted plaintext to
> > the standard (before MitM) receiver (who does not need to support
> > legacy/deprecated from now on anymore).
> 
> I don't think we should be encouraging the automated or transparent use
> of legacy crypto upgrades, particularly in an online setting such as a
> mail gateway. All this does is launder the obviously-dangerous bad
> ciphertext into an apparently-safe new ciphertext.

Agreed, but I did not mean "e-mail" when writing "message". "Message" would 
more some encoded data block from a remote device, that has to be pushed to a 
central system from time to time, e.g. for auditing. Thus the gateway exactly 
knows the sender's key (usually it is only one for all systems with the same 
security level/in the same security zone) and re-encrypts it with a single key 
also known to the recipient. Usually the recipient has all the trusted keys 
hardcoded.

For "e-mail" type messages, as you noted, a transparent re-encryption would be 
more risk than benefit in many cases. Still, it might be useful for 
semi-automated migration scenarios, e.g.

* User clicks on a very old e-mail message

* Gnupg fails decrypting it, referring to the migration tool and asking for 
confirmation

* The migration tool migrates/replaces that single message if the user wants 
that. For e-mail, creating a mime-tree might come in handy, e.g.

- plaintext message (reencrypted)

- decryption/migration protocol (encrypted)

- old message (full old mime structure, also encrypted but without decrypting 
it first - thus providing data at rest protection while still preserving all 
the old structures for traceability)
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: AW: Break backwards compatibility already: it’s time. Ignore the haters. I trust you.

[Andrew Gallagher]

On 22/05/18 10:44, Fiedler Roman wrote:
> Such a tool might then e.g. be used on a MitM message reencryption
> gateway: the old machines still send messages with old
> (deprecated/legacy options), they are transformed by "gpg-archive":
> The full data (old message, old decrypt report, reencrypted
> plaintext) go to the auditing storages, the reencrypted plaintext to
> the standard (before MitM) receiver (who does not need to support
> legacy/deprecated from now on anymore).

I don't think we should be encouraging the automated or transparent use
of legacy crypto upgrades, particularly in an online setting such as a
mail gateway. All this does is launder the obviously-dangerous bad
ciphertext into an apparently-safe new ciphertext.

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
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

AW: Break backwards compatibility already: it’s time. Ignore the haters. I trust you.

[Fiedler Roman]

Hello list,

I failed to decide, which message would be the best to reply to, so I took one 
with a title, rational humanists could be proud of. Ignoring the title, many of 
the messages had valid arguments for both sides. From my point of view the main 
difference seems to be, what is believed to be valid use cases and hence 
requirements for GnuPG. As I do not know of any requirements engineering 
documentation for GnuPG (also did not search for it yet), I just skimmed over 
the various use cases, that would be affected by fully dropping legacy support 
from GnuPG in the hardest way (both en/decrypt).

Foreword: The arguments from below are ONLY from the mostly fully automated, 
non-mail, gnupg use-cases I currently have and their implications on backward 
compatibility. Those use cases might not be representative for automated 
use-cases or not worth to be considered in gnupg future. If they are not 
regarded important for gnupg , that would also be OK for me. It is all just 
about making the decision if gnupg will be the preferred encryption tool for 
the next 5-10yrs in our setups.


To stick to logics, here are my assumptions for reasoning:

* A:LegacyBad: Legacy support is more a security risk than a usability benefit, 
so it should be removed (or at least disabled) in the current version.

* A:LateAdoptersPay: The burden on migrating legacy systems should be mostly on 
the side of those owning them - their lifecycle strategy decision was to 
minimize their costs, this should also have included a prediction, where 
software development/features/availability will move to. If done wrong, it is 
their fault.

* A:MigrationPathes GnuPG on the other side has to provide simple and clear 
data/function migration pathes, so that long term users have trust in gnupg to 
be a solution for longer time.

* A:NonStdBenefits: Non-standard use case support (e.g. non-mail) is a benefit 
for both parties: gnupg software gets also non-standard testing (thus 
security-relevant bugs might be discovered, that would not show up in standard 
use case) while other party can use software that is 80% fit to their purpose, 
so that system integration can be done much faster.

* A:MachineTurnaround: Turn-around time of server software is about 5yrs, not 
all machines are migrated at once. So there will be a transition phase, where 
legacy and non-legacy systems will have to work together.

* A:NoArchiveReencrypt: Full reading and reencryption of old tape archives 
(some that have to be stored/copied for 20yrs+) is not an option, both 
regarding efforts plus auditing support.

* A:LateAdopterIsolate: As legacy software might not be able to tackle modern 
threats, that part of threat mitigation has to be dealt with by the operator, 
meaning: while gpg1.4 might have been suitable to decrypt in online (networked) 
setups back then, a backward compatibility setting might do that only in a 
state of the art 2018 64bit OS-release virtual machine with GnuPG running in an 
old i386, unprivileged, minimal,  fully hardened LXC-container.

* A:AttackSurface: While in desktop setups, more complex gnupg might not be the 
largest part of attack surface, the size of the gnupg-attack surface might be 
relevant in hardened, automated setups. If gnupg cannot be run in a simple, 
auditable, automatable minimal configuration, this will also affect trust in 
the future usability of gnupg.


Considering all those assumptions, I would hope that following strategy would 
be somewhere in the direction of the optimal point for splitting costs between 
legacy operators and development (hopefully both for mail and automation):

* Have 3 categories of features to ease long-term planning, both for dev and 
users (mail and automation):

"recent": those just work

"deprecated": not insecure, but something considered to be removed over the 
next 5-10 years. They can be enabled by "--deprecated" without any known, 
current security risks.

"legacy": In an ideal world, they would not even be in the main code line.

Having those levels would ease coordination of migration pathes between devs 
and users within timeline as required for [A:MachineTurnaround]. As soon as one 
of your tools requires "--deprecated", you should start prioritizing/handling 
that with your devops team.


* While running a mixed setup [A:MachineTurnaround], [A:MigrationPathes] should 
be available, to reduce the amount of data produced with "deprecated" (or even 
"legacy" features) while obsolescence is already dawning.

As the producing systems might not be changed without breaking warranty while 
[A:MachineTurnaround] is not over yet, but operators may already have increased 
costs according to [A:LateAdoptersPay], GnuPG tool support for migration of 
data in use therefore would be nice. This should be quite easy to use to tackle 
"deprected" features (also to motivate users to migrate in steps). For "legacy" 
the effort on integration might be much higher, which is OK. This could go even

Re: Break backwards compatibility already: it’s time. Ignore the haters. I trust you.

[Robert J. Hansen]

Guys, especially in the wake of Efail, *please* stop sending HTML mail
to the list.

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

Relocating pubring.kbx in gpg.conf

[Damien Goutte-Gattat via Gnupg-users]

On 05/22/2018 07:58 AM, Konstantin Boyandin via Gnupg-users wrote:
> primary-keyring ~/mounted/gnupg/pubring.gpg
> secret-keyring ~/mounted/gnupg/secring.gpg
> trustdb-name ~/mounted/gnupg/trustdb.gpg 
> keyring ~/mounted/gnupg/pubring.gpg
> but I see no obvious directives to relocate pubring.kbx

You can use the keyring option as well, which works both for the old
keyring format (.gpg) and the new keybox format (.kbx). You might want
to combine that with the 'no-default-keyring' option, to prevent GnuPG
from systematically create the default $GNUPGHOME/pubring.kbx.

Note, however, that with GnuPG ≥ 2.1 the 'secret-keyring' option no
longer has any effect. Modern GnuPG no longer uses a secret keyring
file, private keys are handled by the Agent which always store them in
$GNUPGHOME/private-keys-v1.d.


> - my only option, so it seems, remains relocating the entire
> configuration directory.

Given that in your current configuration your private keys are *not*
stored where you think they are (because 'secret-keyring' is ignored as
stated above), this is indeed as far as I know your only option.


Damien



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

Relocating pubring.kbx in gpg.conf

[Konstantin Boyandin via Gnupg-users]

Hello,

GnuPG: 2.2.7 (built from sources), OS: Ubuntu 16.04.4 (64-bit).

Problem: file pubring.kbx is by default created in GnuPG default config 
directory. If some other files I can efficiently relocate in gpg.conf, 
i.e. by using something like


primary-keyring ~/mounted/gnupg/pubring.gpg
secret-keyring ~/mounted/gnupg/secring.gpg
trustdb-name ~/mounted/gnupg/trustdb.gpg
keyring ~/mounted/gnupg/pubring.gpg

but I see no obvious directives to relocate pubring.kbx - my only 
option, so it seems, remains relocating the entire configuration 
directory.


Is there a less total way to relocate pubring.kbx ?

Thanks.

Sincerely,
Konstantin

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

Re: Break backwards compatibility

[Michael Kesper]

Hi Mark,

Am Dienstag, den 22.05.2018, 02:25 +0100 schrieb Mark Rousell:
> On 21/05/2018 08:53, Michael Kesper wrote:
> > I think it might be best to put that functionality into a separate
> > GnuPG version called gpg-legacy.
> > Make it clear in all man pages of this tool, the --version and --
> > help
> > options that this only exists to decrypt existing but now obsolete
> > encrypted material and that it can't be used to create such
> > material
> > anymore.
>  
> Seems reasonable to me, although does GnuPG 1.x already effectively
> fulfil that role?

Yes, did read so after writing my mail. :)

Michael
--
Michael Kesper
Supporter of FSFE https://fsfe.org/about
GPG Fingerprint: F035 8BD9 D0C2 0E6A 85B5  6A60 4208 05C6 8907 4FAD

signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users