Why 2.1 is delayed for so long

[Ximin Luo]

On 23/09/14 16:36, Robert J. Hansen wrote:
>> Yes, it would seem you're not learning *enough* from this history.
>> New laws are being passed that make it legal (hah!) for intelligence
>> services to hack into computers. I would rather different keys for
>> different purposes be separated, and my master key moved offline. If
>> my signature key gets compromised, at least they can only write
>> emails claiming to be me, not sign fake keys on my behalf.
> 
> And for you, that makes perfect sense.  But that's not the normal use
> case, mostly because the difficulties that arise from using an offline
> master key are large enough to make GnuPG an insurmountable obstacle for
> users.
> 
> GnuPG already has a learning curve like the Matterhorn.  Let's not make
> it harder or worse, okay?
> 
> I know, I know.  "But my proposal doesn't make it any worse!  It only
> makes it possible for those who want to do this, to do this, without any
> tweaking of their certificates!"  Sure.  But to reach that one user in a
> thousand who wants to store a certification key offline, you're talking
> about making the system more complicated for the other nine hundred
> ninety-nine users.  I don't think that's a win.  I think that's a loss.
> 

How is this "more complicated"? And how is this different from the single-key to double-key switch? Most people will never get RIPA notices, either.

Why not make the default master key C+S+A instead of C+S, then?

>> In the future, it should be easy to put your master key offline.
> 
> An excellent observation.  (No, I'm not being sarcastic.)  So why not
> work on that problem?  If you come up with an easy way for people to do
> it, then I'm sure Werner will re-evaluate his decision to not support this.
> 

I *have* been working on that problem. It involves making caff much easier to use in the offline case.

>> So it is better to
>> prepare for that situation now, instead of asking everyone to
>> generate a new key and refresh everyone else's key when the time
>> comes.
> 
> It is amazing how many things that "everyone knew" would come to pass
> never came to pass at all.  It is good to be cautious about writing code
> to support things that "everyone knows" will come to pass.  Most of it
> turns out to be code written in support of vaporware.
> 

Well, then don't give me history lessons. Hindsight is useless, unless you use it to guide your future decisions.

>> Be careful what you wish for.
>> http://lkml.iu.edu//hypermail/linux/kernel/0210.1/1834.html
> 
> Not sarcastic, but humorous, yes --
> 
> Holy crap, you mean that by telling you 'no' to your idea we could wind
> up getting something as neat, as cool, and as genuinely useful as Git?
> Man.  Umm.  How am I supposed to ... ah, right.
> 
> 
> NNN   NN   OOOOO    !!!
> NNNN  NN OOO   OOO  !!!
> NN NN NN OO     OO  !!!
> NN  NNNN OOO   OOO
> NN   NNN   OOOOO     !
> 
> 
> Implicitly threatening to replace GnuPG with something better?  Man, you
> must be new here.  This is the sort of thing that leads me to dance
> around hollering, "Bring it, O Lord!  Let Thy Kingdom come!"
> 
> GnuPG does a pretty good job in a pretty hard area, but like any
> software project it has a finite lifespan.  Someday it will be
> unmaintained.  All we can hope for is that what comes after GnuPG learns
> from GnuPG's experiences, that the code is free and respects people's
> rights to learn and understand and share, and that it is more useful and
> better for people than GnuPG was.  If you can deliver on that promise
> I'm pretty sure you'll have a long line of people waiting to buy you a
> beer, and I'll be at the front with the Dortmunder.  :)
> 

If that does come to pass, I would still consider it a loss for society, because it would have been easier to just tweak GPG, and I could have spent that effort on other things.

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140923/945a2167/attachment-0001.sig>