your gnupg patches

[Werner Koch]

> Date: March 29, 2004 12:17 am
> From: Tom St Denis <tom at securescience.net>
> To: gnupg-devel at gnupg.org

> I did email the webmaster and the list.

We had severe problems with the list the last days.

> I posted the patches to sci.crypt as well....

I haven'd read that for ages - the S/N ratio used to be too bad.

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

> 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


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

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

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

> Is shorter, portable and more ameniable to platforms without shorter data
> types.

and slower

> a reward of spending 6 hours writing patches [and porting over my public
> domain LibTomCrypt test vectors/AES code] is a wall of silence can you really
> wonder why progress is slow?

I don't understand what you mean in this context with "progress"?
GnuPG 1.2 is the stable branch and ideally we won't change anything
there.

> The FSF exists for this very reason, to prevent dead-locks and barriers in
> software development.  The fact that this is *GNU* PG should reflect this.

That is definitely wrong.  The FSF exists to foster Freedom in
software use and development.  Specific development procedures have
nothing to do with the goals of the FSF.

>  as many others] just fine.  I wrote these patches as a courtesy to the GNUPG
>  team not as a justification for using the code.

You might want to coordinate with the developers before spending too
much time hacking on some code the next time you do this.


Thanks,

   Werner