your gnupg patches

[Bernd Jendrissek]

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

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.

> > 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.

> > 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.)

> > [specifically because some platforms don't natively support anything
> > other than a machine register, e.g. the ARM IIRC].
> 
> GnuPG runs just fine on ARM boxes.

Aren't there some El Weirdo machines that are neither little nor
big-endian, and consequently have a NUXI problem?

> >  * 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.

> > 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.

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.

- -- 
http://voyager.abite.co.za/~berndj/ (up again for now - yay!)
"IBM has more patent litigation lawyers than SCO has employees." - unknown
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFAaXAq/FmLrNfLpjMRAmF3AJ4zKhQDAkfUH/Htx+MwJ4BKvUG6mwCgpd0e
6fUDE3C4SPGMOQ9CPAO4Ds4=
=uo1f
-----END PGP SIGNATURE-----