your gnupg patches

[Tom St Denis]

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

On March 30, 2004 06:17 am, Werner Koch wrote:
> > 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.

Yeah, must be too bad for the wonderful Werner Koch.... oh heaven forbid that!  
You should go email Fluhrer, Wagner, Rose, etc... about this!!  They still 
read/post to the group!

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

If you look at the patches they are not that radical.  I replace your 
"inlined" load/stores with macros.  I replaced your constants with the 
#defines you already set and I added test vectors.  

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

Personally I don't believe in the GPL that's why I don't use it myself.  These 
patches were written ontop of a GPL product, that makes the patches GPL.

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

If anything only C99 [I'll have to check] provides for this.  I'm positive 
that C90 and C89 [the more popular standards] only provide types that are "at 
least" a given size.  If you don't trust me ask the pros in comp.lang.c

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

Um, I use "portable" code... check this out

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=_1HPa.866%24_K5.421%40fe01.atl2.webusenet.com&rnum=1&prev=/groups%3Fq%3Ddevine%2Baes%2Bgroup:sci.crypt.*%26hl%3Den%26lr%3D%26ie%3DUTF-8%26group%3Dsci.crypt.*%26selm%3D_1HPa.866%2524_K5.421%2540fe01.atl2.webusenet.com%26rnum%3D1

[really long, here's a shorter one]

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

My portable code is so much "slower" than yours that it ranks among the best 
in the world.   Yup, so much for that argument.

Let's not forget that my LOAD/STORE macros do come out to memcpy on the proper 
platforms [hint: glance at LibTomCrypt for a second].

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

See above.

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

I'm certain my patches could be applied against any branch as you guys were 
unlikely to clean up that code anyways.

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

So you write a tool called "GNUPG" then ignore contributions as a matter of 
pride?  Gotcha.  

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

How about not.  You guys are not worth the trouble.

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

iD8DBQFAaXMFsP+tEsHHY0ARAmYJAKCBsq+3IDJYZ6qpHOWYe42S9IcX+wCcDtaY
AUQXmKHbW6QMn+JfLz4sJ4w=
=I2+p
-----END PGP SIGNATURE-----