your gnupg patches
berndj at prism.co.za
Tue Mar 30 18:10:24 CEST 2004
Hello all, I got this from Tom, I hope he doesn't mind me copying the
list (and Cc'ing him since he's not on the list).
----- Forwarded message from Tom St Denis <tom at securescience.net> -----
From: Tom St Denis <tom at securescience.net>
To: Bernd Jendrissek <berndj at prism.co.za>
Subject: Re: your gnupg patches
References: <87zn9yljd2.fsf at vigenere.g10code.de> <87vfkmlh28.fsf at vigenere.g10code.de> <20040330130355.GA11464 at prism.co.za>
In-Reply-To: <20040330130355.GA11464 at prism.co.za>
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
-----BEGIN PGP SIGNED MESSAGE-----
I'm not on the list but this ended up in my box anyways, so I'll reply
directly to ya.
On March 30, 2004 08:03 am, you wrote:
> On Tue, Mar 30, 2004 at 01:17:51PM +0200, Werner Koch wrote:
> > > Date: March 29, 2004 12:17 am
> > > From: Tom St Denis <tom at securescience.net>
> > > To: gnupg-devel at gnupg.org
> > >
> > > Why? I took the non-portable and messy code and cleaned it up.
> > > While I didn't fix readily exploitable bugs having cleaner code is a
> > > desireable goal right?
> > The code has been around for years and proven to be pretty portable to
> > all kinds of architectures, so we don't want to risk that. Even more
> > important is that every change increases the chance for new bugs and
> > thus for a stable version we don't do such cleanups.
> The same argument can be made for gzip, bzip2, and yet they make
> I haven't looked in a while; does GnuPG have a testsuite? So that I can
> type 'make check' and it'll pump gigabytes through gpg to be signed,
> encrypted, decrypted, whatever. If any bit differs from the "correct"
> result, you FAIL the test.
Yes it does. In fact all cipher/hashes have a "selftest" function which tests
it against known test vectors. Part of my patches was *adding* selftest
functions to the hashes [there were none] and making the selftest part of the
startup [e.g. when you first run gpg it will selftest *everything*].
As the author of LibTomCrypt I have learned over the years to be exacting
[e.g. I've had my share of implementation bugs in the past].
> > > Well I'd think that a public release would inherently fall under the
> > > GPL since the GPL mandates that.
> > Its not about the GPL, see http://www.gnu.org/copyleft/why-assign.html
> GPL code can freely incorporate public domain code, AFAIK (but IANAL).
> The only reason to prefer GPL-assigned-to-FSF over public domain is that
> in the event of a GPL violation, the violator cannot be hauled over the
> coals for the public domain parts.
The code I contributed as ported from LibTomCrypt which is a public domain
package [has been since Dec 2001].
> > > Which is not portable. A "u32" must be *at least* 32-bits and a
> > > "byte" must be *at least* 8-bits. There are no portable C types of
> > > a given exact size
> > Have a look at include/types.h and you will notice that u32 is defined
> > to be exactly 32 bits.
> How do you guarantee that without using __attribute__((mode (SI))),
> which is a GCC *extension*? Sure, you can always define types that are
> *at least* N bits long (at least for N <= 32).
> (Again, I haven't looked, so RTFS applies to me.)
I think C99 [re ISO C] supports exact types but I don't know. Certainly C90
didn't which is what I normally aim for [well a mix of C90/C99].
> > > * Also "byte" is not guranteed to be 8-bits so the original code is
> > > not always gonna work
> > We don't care about those ancient architectures. Nor do we care about
> > weird endian formats. Those machines would anyway be too slow for any
> > practical use of GnuPG.
> Oh well, okay. Says who ("too slow"), BTW? I'd love to see my
> cellphone able to produce OpenPGP output (not that a cellphone would be
> "too slow" or "weird"), or a pinpad at the bank, etc.
> Besides, did you just volunteer to field the requests for help when
> someone tries to build GnuPG on some weird PDP (*) hir basement?
> BTW these failures would manifest themselves at runtime, not
> (*) Sorry, can't find any specific, factual examples now.
That's just it. Robust code always seems like "overkill". Until it gets
tested [e.g. bug exploited]. Why not be on the safe side and write code that
is less likely to cause any troubles?
> > > Is shorter, portable and more ameniable to platforms without shorter
> > > data types.
> > and slower
> Let the compiler worry about that. And if you insist otherwise, it's
> time to pull out the assembler.
Um check this out
Not only is my [libtomcrypt] "portable" code slower ...er... faster than gnupg
but it is also less resilient to fault. ;-)
> Sorry, Werner, but I have just seen too much endianness and
> alignment-assuming code here where I work to have any tolerance left for
> code that "happens to work". Yes, it "happens to work" for good reason,
> some of which you state above, but sooner or later it's gonna come back
> and bite you.
Which is why I donated the patches to the package. Admitedly I should have
made them against a 1.3.x version but I'm not a gnupg-devel so I don't really
care. The patches I wrote are simple enough to port to the 1.3.x branch I'd
think specially since I doubt anyone has touched that /cipher/ dir in the
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the Gnupg-devel