[Pkg-gnupg-maint] Bug#739424: gnupg dies with "gpg: out of secure memory [...]" since 1.4.16-1

[Marc Lehmann]

On Tue, Sep 30, 2014 at 09:17:02AM +0200, Werner Koch <wk at gnupg.org> wrote:
> Please read the FAQ and if you disagree, feel free to re-open the
> discussion for yet another round on gnupg-users.

Werner, again - nothing in the FAQ can change the fact that you are wrong
in claiming that these key sizes are stupid, when _actual_ crypto experts
disagree.

> I am more than tired of the those key size matters discussions.

Key size clearly matters, which is why people no longer use rsa-512 or
DES, and which is why people movew away from (standard 1024 bit) dsa.

Furthermore, characterising this bug as "key size matters" is again
disingenous, as _you_ are the one claiming this: This ticket is simply
about an arbitrary limit which hampers interoperation - nobody tries to
convince you to go for longer keys by default, recomemnd them, or anything
like that.

The fix would be trivial without sacrificing any security.

I can understand if you misread/misunderstood this ticket - we are all
very busy. If that is the case, maybe you could go back and actually take
care of the issue reported, instead of hammering on a topic that is
irrelevant here?

> have to take the whole system in account and not just one aspect.  16k
> keys are ridiculous and dangerous for the hole crypto environment.

Calling things "ridiculous" doesn't make them so: when actual crypto
experts disagree with you, you need to bring a bit more to the table than
simply calling things ridiculous.

How are they dangerous? At the moment, the only danger is in gpg, as other
implementations do not have this arbitrary limit, which creates a very
real danger of forcing people to not encrypt to solve interoperability
issues with gnupg.

> You only look at technical arguments and not on arguments regarding
> usability.

Actually, it is you who ignores usability - you are proposing to kepe the
status quo, which means existing keys are unusable until somebody patches
gnupg.

> Only a few 16k signature on a lot of keys makes the WoT
> re-checking slow.

Only if you enable it, that's what people are asking for here. Gnupg
already dynamically allocates the memory. Having an option would be
trivial.

It is you who ignores usability here.

> multi-recipient messages stops the workflow and makes people consider to
> switch off encryption.

I think the issue here was keysigning, not signing you e-mail. Different
keys, diuferent use cases, so your argument doesn't apply.

> smaller machines.  Thus it harms the overall usability of the system
> just for a few strawmen's misdirected huge key size is better opinion.

Again, you are the one who makes this "huge key size is better" claim - I
don't think anybody else did this in this ticket.

> > You have provided zero evidence in favour of not fixing this bug, but
> 
> Marc, pretty please read the FAQ.

Again, nothing in the FAQ can magically make your previous statements
right.

In any case, it seems you are arguing against a completely different issue
here - you really should go back and read this ticket.

> I won't continue to discuss this here anymore.

How well you maintain gnupg is your choice.

> precious for repeating the same arguments over and over again.

Since you didn't repeat any argument so far, there is no danger of you
repeatign yourself. Claiming "this is ridiculous" is not an argument.

> gnupg-users and you will find a lot of people who have enough time to
> discuss this with you.

Again, no amount of discussion can change facts.

> > you do not want fix this bug, keeping keysizes in gnupg arbitrarily low
> > for your own private reasons.
> 
> I do not know whether or what you want to imply withn that claim.  It
> sounds quite insulting, though.

I want to imply exactly what I wrote - the limit is currently arbitrary
and low compared to othe rimplementations, and stating "this is
ridiculous" is not a valid reason, so the actual reasons why you refuse to
fix this are, indeed, your own private ones.

If you don't like the facts, don't feel insulted.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\