On 10/03/2014 02:47 AM, Werner Koch wrote: > On Thu, 2 Oct 2014 22:06, d...@fifthhorseman.net said: > >> Attached is a patch (a third variant) for gpg's 1.4 stable branch that >> does what i've outlined above. let me know what you think. > > Okay, okay, I give up ;-)
;)
> Please do not i18n the warning string. We already have too many rarley
> used strings translated.
OK, will do.
>> Note: with this patch, for aesthetic reasons, i've also changed the
>> configure option to --enable-large-rsa, so that the build-time and
>> run-time options are symmetric.
>
> Another idea: What about using --enable-secmem=65536 and change the
> warning to check that the supplied size is sufficient?
I like that, since it makes the ./configure option clearer about what
it's doing. Alternately, we could just call it --enable-large-secmem
(--enable-larger-secmem?), so that people can't do silly things like
--enable-secmem=17 or --enable-secmem=bananas
Assuming we go with the variable size configure option, i don't know how
to test that the supplied size is sufficient for generating 8192-bit
keys -- i suppose i can just use:
#if SECMEM_SIZE >= 65536
// accept --enable-large-rsa
#else
// warn that enable-large-rsa won't work
#endif
which is no worse than the current proposal.
Going down this route suggests that maybe the actual upper-limit to gpg
--gen-key --batch --enable-large-rsa should scale with the declared
SECMEM_SIZE, instead of being either 4096 or 8192, but i don't know how
to compute such a scale aside from experimentation on any given platform.
Let me know how you prefer it, and i'll roll up one final patch.
Thanks for persisting on this, Werner.
Regards,
--dkg
signature.asc
Description: OpenPGP digital signature
