your gnupg patches

[Bernd Jendrissek]

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 
	zebra.wetton.example.org
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.63
X-Spam-Level: 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
> changes.
>
> 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
> compile-time.
>
> (*) 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 

http://groups.google.com/groups?selm=be4jnp%241280%241%40biggoron.nerim.net&output=gplain

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 
longest while!

Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAaXWMsP+tEsHHY0ARAhf3AKCBh98Hr5QFd0e9uH0osLFKhDPpUwCdGZS6
0HvBsQaMOQ1jRVan8R/6Ais=
=ZKUm
-----END PGP SIGNATURE-----