From wk at gnupg.org Thu Dec 1 13:28:44 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 01 Dec 2011 13:28:44 +0100 Subject: [PATCH] Add ability to save/load an md5 checkpoint file In-Reply-To: <4ED6A748.1030702@virtualcomputer.com> (Ben Guthro's message of "Wed, 30 Nov 2011 16:59:36 -0500") References: <4ED6A748.1030702@virtualcomputer.com> Message-ID: <87ipm079xf.fsf@vigenere.g10code.de> On Wed, 30 Nov 2011 22:59, ben.guthro at virtualcomputer.com said: > For large encryption streams - it can be convenient to write a checkpoint file, > to be able to be able to resume later. I can image that is is usable. However, your code does not fit into the Libgcrypt architecture: It is only for an old and for most purposes broken algorithm, it uses direct write to a file and it is not architecture neutral. Further we would need copyright assignments to the FSF. A better way of doing this is to have a general way of serializing and exporting/importing the state of a hash algorithm. Given that the state is an internal property of Libgcrypt, we can't export it because that would mean to keep that serialized state compatible to all future versions; this is a too high burden for maintenance. What we can do is to return the state a long with a version number and allow restoring it only if the version number matches - that should be okay for this purpose. It is a bit of work, though. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ben.guthro at virtualcomputer.com Thu Dec 1 13:49:31 2011 From: ben.guthro at virtualcomputer.com (Ben Guthro) Date: Thu, 1 Dec 2011 07:49:31 -0500 Subject: [PATCH] Add ability to save/load an md5 checkpoint file In-Reply-To: <87ipm079xf.fsf@vigenere.g10code.de> References: <4ED6A748.1030702@virtualcomputer.com> <87ipm079xf.fsf@vigenere.g10code.de> Message-ID: I figured it was a bit of a long shot that you'd take the patch as-is...but thought it was useful functionality that might, at least spark a discussion as to the proper way to implement such a feature that would be acceptable upstream. As for copyright assignments...doesn't the code fall under the existing copyright in the file? On Dec 1, 2011, at 7:28 AM, Werner Koch wrote: > On Wed, 30 Nov 2011 22:59, ben.guthro at virtualcomputer.com said: >> For large encryption streams - it can be convenient to write a checkpoint file, >> to be able to be able to resume later. > > I can image that is is usable. However, your code does not fit into the > Libgcrypt architecture: It is only for an old and for most purposes > broken algorithm, it uses direct write to a file and it is not > architecture neutral. Further we would need copyright assignments to > the FSF. > > A better way of doing this is to have a general way of serializing and > exporting/importing the state of a hash algorithm. Given that the state > is an internal property of Libgcrypt, we can't export it because that > would mean to keep that serialized state compatible to all future > versions; this is a too high burden for maintenance. What we can do is > to return the state a long with a version number and allow restoring it > only if the version number matches - that should be okay for this > purpose. > > It is a bit of work, though. > > > Salam-Shalom, > > Werner > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > From wk at gnupg.org Thu Dec 1 15:59:39 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 01 Dec 2011 15:59:39 +0100 Subject: [PATCH] Add ability to save/load an md5 checkpoint file In-Reply-To: (Ben Guthro's message of "Thu, 1 Dec 2011 07:49:31 -0500") References: <4ED6A748.1030702@virtualcomputer.com> <87ipm079xf.fsf@vigenere.g10code.de> Message-ID: <87ehwo72xw.fsf@vigenere.g10code.de> On Thu, 1 Dec 2011 13:49, ben.guthro at virtualcomputer.com said: > I figured it was a bit of a long shot that you'd take the patch > as-is...but thought it was useful functionality that might, at least > spark a discussion as to the proper way to implement such a feature > that would be acceptable upstream. That worked. > As for copyright assignments...doesn't the code fall under the > existing copyright in the file? No. For non-trivial changes the FSF requires a written (i.e. paper) copyright assignment. If I would add code from you, you would have the copyright on that parts of the code. Now if for example the FSF wants to change the license (say from GPL to LGPL) they would have to get your permission to do that. Now consider there are dozens of authors and some may not agree or are simply not anymore reachable. Thus copyright assignments are the way to go. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ben.guthro at virtualcomputer.com Thu Dec 1 16:32:28 2011 From: ben.guthro at virtualcomputer.com (Ben Guthro) Date: Thu, 1 Dec 2011 10:32:28 -0500 Subject: [PATCH] Add ability to save/load an md5 checkpoint file In-Reply-To: <87ehwo72xw.fsf@vigenere.g10code.de> References: <4ED6A748.1030702@virtualcomputer.com> <87ipm079xf.fsf@vigenere.g10code.de> <87ehwo72xw.fsf@vigenere.g10code.de> Message-ID: Sorry to hear that. I guess I will not be contributing to this OSS project. I have contributed to quite a few projects in the pas - both for work, and as a private developer. All of these works have always fallen under the copyright in the file header. I have never filled out paperwork, and have no intention to do so in the near future. Best of luck to you, and Stallman in stifling innovation by way of dead trees. Feel free to re-imlement this idea, should you see fit, independent of this patch. /btg On Dec 1, 2011, at 9:59 AM, Werner Koch wrote: > On Thu, 1 Dec 2011 13:49, ben.guthro at virtualcomputer.com said: > >> I figured it was a bit of a long shot that you'd take the patch >> as-is...but thought it was useful functionality that might, at least >> spark a discussion as to the proper way to implement such a feature >> that would be acceptable upstream. > > That worked. > >> As for copyright assignments...doesn't the code fall under the >> existing copyright in the file? > > No. For non-trivial changes the FSF requires a written (i.e. paper) > copyright assignment. If I would add code from you, you would have the > copyright on that parts of the code. Now if for example the FSF wants > to change the license (say from GPL to LGPL) they would have to get your > permission to do that. Now consider there are dozens of authors and > some may not agree or are simply not anymore reachable. Thus copyright > assignments are the way to go. > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > From wk at gnupg.org Fri Dec 2 10:46:03 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 02 Dec 2011 10:46:03 +0100 Subject: [PATCH] Add ability to save/load an md5 checkpoint file In-Reply-To: (Ben Guthro's message of "Thu, 1 Dec 2011 10:32:28 -0500") References: <4ED6A748.1030702@virtualcomputer.com> <87ipm079xf.fsf@vigenere.g10code.de> <87ehwo72xw.fsf@vigenere.g10code.de> Message-ID: <87sjl34884.fsf@vigenere.g10code.de> On Thu, 1 Dec 2011 16:32, ben.guthro at virtualcomputer.com said: > Best of luck to you, and Stallman in stifling innovation by way of dead trees. That is required by the US copyright law. It is not RMS' idea. BTW, a lot of high profile projects require copyright assignments, for example X11 or Samba. There are also companies who require that (e.g. Sun's OpenOffice, Canonical's Ubuntu, Oracls's MySQL, etc.); I would actually hesitate to sign such company CAs - they don't guarantee that the assigned code will stay free. In contrast the FSF guarantees this and give you all the reciprocal rights as possible by US law. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From andre at amorim.me Fri Dec 2 10:58:01 2011 From: andre at amorim.me (Andre Amorim) Date: Fri, 2 Dec 2011 09:58:01 +0000 Subject: [PATCH] Add ability to save/load an md5 checkpoint file In-Reply-To: <87sjl34884.fsf@vigenere.g10code.de> References: <4ED6A748.1030702@virtualcomputer.com> <87ipm079xf.fsf@vigenere.g10code.de> <87ehwo72xw.fsf@vigenere.g10code.de> <87sjl34884.fsf@vigenere.g10code.de> Message-ID: open .. payday ? On 2 December 2011 09:46, Werner Koch wrote: > On Thu, ?1 Dec 2011 16:32, ben.guthro at virtualcomputer.com said: > >> Best of luck to you, and Stallman in stifling innovation by way of dead trees. > > That is required by the US copyright law. ?It is not RMS' idea. > > BTW, a lot of high profile projects require copyright assignments, for > example X11 or Samba. ?There are also companies who require that > (e.g. Sun's OpenOffice, Canonical's Ubuntu, Oracls's MySQL, etc.); I > would actually hesitate to sign such company CAs - they don't guarantee > that the assigned code will stay free. ?In contrast the FSF guarantees > this and give you all the reciprocal rights as possible by US law. > > > Shalom-Salam, > > ? Werner > > -- > Die Gedanken sind frei. ?Ausnahmen regelt ein Bundesgesetz. > > > _______________________________________________ > Gcrypt-devel mailing list > Gcrypt-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gcrypt-devel -- Gnupg key: 02375205 Fingerprint: F7CD D181 943B 0453 8668 ?AF16 84E9 7565 0237 5205 From wk at gnupg.org Fri Dec 2 21:04:03 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 02 Dec 2011 21:04:03 +0100 Subject: [PATCH] Add ability to save/load an md5 checkpoint file In-Reply-To: (Andre Amorim's message of "Fri, 2 Dec 2011 09:58:01 +0000") References: <4ED6A748.1030702@virtualcomputer.com> <87ipm079xf.fsf@vigenere.g10code.de> <87ehwo72xw.fsf@vigenere.g10code.de> <87sjl34884.fsf@vigenere.g10code.de> Message-ID: <87ehwm3fm4.fsf@vigenere.g10code.de> On Fri, 2 Dec 2011 10:58, andre at amorim.me said: > open .. payday ? Care to explain? Salam-Shalom, Werner A3: Please. Q3: Should I avoid top posting on this mailing list? A2: Because, by reversing the order of a conversation, it leaves the reader without much context, and makes them read a message in an unnatural order. Q2: Why is top posting irritating? A1: It is the practice of putting your reply to a message before the quoted message, instead of after the (trimmed) message. Q1: What is top posting? -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bradh at frogmouth.net Sat Dec 3 01:44:32 2011 From: bradh at frogmouth.net (Brad Hards) Date: Sat, 3 Dec 2011 11:44:32 +1100 Subject: [PATCH] Add ability to save/load an md5 checkpoint file In-Reply-To: <87sjl34884.fsf@vigenere.g10code.de> References: <4ED6A748.1030702@virtualcomputer.com> <87sjl34884.fsf@vigenere.g10code.de> Message-ID: <201112031144.32908.bradh@frogmouth.net> On Fri, 2 Dec 2011 08:46:03 PM Werner Koch wrote: > BTW, a lot of high profile projects require copyright assignments, for > example X11 or Samba. I don't know about X11, but Samba doesn't require copyright assignment. http://www.samba.org/samba/devel/copyright-policy.html Its a personal choice as to whether you want to go through the pain of the FSF's process. For some people, its OK; for others, its a barrier to entry. Personally, I've done it for some FSF projects, but I probably wouldn't do it again. Brad From andre at amorim.me Sat Dec 3 06:38:48 2011 From: andre at amorim.me (Andre Amorim) Date: Sat, 3 Dec 2011 05:38:48 +0000 Subject: [PATCH] Add ability to save/load an md5 checkpoint file In-Reply-To: <87ehwm3fm4.fsf@vigenere.g10code.de> References: <4ED6A748.1030702@virtualcomputer.com> <87ipm079xf.fsf@vigenere.g10code.de> <87ehwo72xw.fsf@vigenere.g10code.de> <87sjl34884.fsf@vigenere.g10code.de> <87ehwm3fm4.fsf@vigenere.g10code.de> Message-ID: I am very sorry for the cognitive dissonant, to be honest I was so tired that I slept immediately after writing the email and now even for myself is hard to get the line of thought again, the unconscious mind has its own language... but was something about volunteer, donations, no obligation, business model, dual licence, etc.. Again, apologize. Andre Amorim On 2 December 2011 20:04, Werner Koch wrote: > On Fri, ?2 Dec 2011 10:58, andre at amorim.me said: >> open .. payday ? > > Care to explain? > > > Salam-Shalom, > > ? Werner > > > A3: Please. > Q3: Should I avoid top posting on this mailing list? > > A2: Because, by reversing the order of a conversation, it leaves the > ? ?reader without much context, and makes them read a message in an > ? ?unnatural order. > Q2: Why is top posting irritating? > > A1: It is the practice of putting your reply to a message before the > ? ?quoted message, instead of after the (trimmed) message. > Q1: What is top posting? > > > -- > Die Gedanken sind frei. ?Ausnahmen regelt ein Bundesgesetz. > -- Gnupg key: 02375205 Fingerprint: F7CD D181 943B 0453 8668 ?AF16 84E9 7565 0237 5205 From wk at gnupg.org Sat Dec 3 16:38:05 2011 From: wk at gnupg.org (Werner Koch) Date: Sat, 03 Dec 2011 16:38:05 +0100 Subject: [PATCH] Add ability to save/load an md5 checkpoint file In-Reply-To: <201112031144.32908.bradh@frogmouth.net> (Brad Hards's message of "Sat, 3 Dec 2011 11:44:32 +1100") References: <4ED6A748.1030702@virtualcomputer.com> <87sjl34884.fsf@vigenere.g10code.de> <201112031144.32908.bradh@frogmouth.net> Message-ID: <87wrad1x9e.fsf@vigenere.g10code.de> On Sat, 3 Dec 2011 01:44, bradh at frogmouth.net said: > I don't know about X11, but Samba doesn't require copyright assignment. > http://www.samba.org/samba/devel/copyright-policy.html Oops. I got that wrong while remembering the latest change in the Samba policy [1] which is on how to handle work by employees. I was not anymore able to find anything regarding X11 copyright assignmens; it is possible that back in these times X11 (not Xfree86) was controlled by corporations which always require such a thing. Other examples are Qt (which recently dropped it) and MySQL or MariaSQL. Copyright assignment are a hot topic these days and there are lots of pros and cons. The FSF policy is old and has only been slighly revised over the years. However, this is what we have to use for (core) GNU projects. One of the goals of the GNU Advisory Committee [2] is to look at problematic areas in GNU software development requirements and try to fix them. There is no roadmap, though.. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ken.werner at linaro.org Wed Dec 21 18:18:45 2011 From: ken.werner at linaro.org (Ken Werner) Date: Wed, 21 Dec 2011 18:18:45 +0100 Subject: [PATCH] Mark 'xl' as early clobbered In-Reply-To: <1324487925-9285-1-git-send-email-ken.werner@linaro.org> References: <1324487925-9285-1-git-send-email-ken.werner@linaro.org> Message-ID: <1324487925-9285-2-git-send-email-ken.werner@linaro.org> In ARM mode the input register of the umull must be different from the output register. Signed-off-by: Ken Werner --- mpi/longlong.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/mpi/longlong.h b/mpi/longlong.h index 5dba793..69b02d4 100644 --- a/mpi/longlong.h +++ b/mpi/longlong.h @@ -228,7 +228,7 @@ extern UDItype __udiv_qrnnd (); __asm__ ("%@ Inlined umul_ppmm\n" \ "umull %r1, %r0, %r2, %r3" \ : "=&r" ((USItype)(xh)), \ - "=r" ((USItype)(xl)) \ + "=&r" ((USItype)(xl)) \ : "r" ((USItype)(a)), \ "r" ((USItype)(b)) \ : "r0", "r1") -- 1.7.5.4 From ken.werner at linaro.org Wed Dec 21 18:18:44 2011 From: ken.werner at linaro.org (Ken Werner) Date: Wed, 21 Dec 2011 18:18:44 +0100 Subject: [PATCH] Small fix for umul_ppmm on ARM Message-ID: <1324487925-9285-1-git-send-email-ken.werner@linaro.org> Hi There, Currently the definition of umul_ppmm (longlong.h) looks like this: #define umul_ppmm(xh, xl, a, b) \ __asm__ ("%@ Inlined umul_ppmm\n" \ "umull %r1, %r0, %r2, %r3" \ : "=&r" ((USItype)(xh)), \ "=r" ((USItype)(xl)) \ : "r" ((USItype)(a)), \ "r" ((USItype)(b)) \ : "r0", "r1") This code generates the following assembler error message when compiling for -march=armv5te: Error: selected processor does not support Thumb mode `umull r5,ip,r5,r3' In ARM mode the input register of the umull must be different from the output register. This limitation does not exists for the Thumb mode but in my case the compiler was restricted to ARMv5 that doesn't support Thumb. One way to fix this would be to mark "xl" as early clobbered. The code was introduced by this patch: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commitdiff;h=487fe72494051de4a7e513c15b6a895dcd0164ce#patch9 Ken Werner (1): Mark 'xl' as early clobbered mpi/longlong.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Best Regards, Ken -- 1.7.5.4 From wk at gnupg.org Wed Dec 21 20:51:42 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 Dec 2011 20:51:42 +0100 Subject: [PATCH] Small fix for umul_ppmm on ARM In-Reply-To: <1324487925-9285-1-git-send-email-ken.werner@linaro.org> (Ken Werner's message of "Wed, 21 Dec 2011 18:18:44 +0100") References: <1324487925-9285-1-git-send-email-ken.werner@linaro.org> Message-ID: <87ehvxwvn5.fsf@vigenere.g10code.de> On Wed, 21 Dec 2011 18:18, ken.werner at linaro.org said: > This code generates the following assembler error message when compiling > for -march=armv5te: > Error: selected processor does not support Thumb mode `umull r5,ip,r5,r3' What cpp macro is defined for this architecure? I would feel better not to change 10 years old code, if there is a way to avoid it. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ken.werner at linaro.org Wed Dec 21 21:51:09 2011 From: ken.werner at linaro.org (Ken Werner) Date: Wed, 21 Dec 2011 21:51:09 +0100 Subject: [PATCH] Small fix for umul_ppmm on ARM In-Reply-To: <87ehvxwvn5.fsf@vigenere.g10code.de> References: <1324487925-9285-1-git-send-email-ken.werner@linaro.org> <87ehvxwvn5.fsf@vigenere.g10code.de> Message-ID: <4EF246BD.4080509@linaro.org> On 12/21/2011 08:51 PM, Werner Koch wrote: > On Wed, 21 Dec 2011 18:18, ken.werner at linaro.org said: > >> This code generates the following assembler error message when compiling >> for -march=armv5te: >> Error: selected processor does not support Thumb mode `umull r5,ip,r5,r3' > > What cpp macro is defined for this architecure? I would feel better not > to change 10 years old code, if there is a way to avoid it. $ arm-linux-gnueabi-cpp -march=armv5te -dM /dev/null|grep ARCH #define __ARM_ARCH_5TE__ 1 However, initially I thought it's because of the inline assembly and I wrote that tiny patch. But I just noticed when using the toolchain I've got that even the following code: unsigned int foo (unsigned int xh, unsigned int xl, unsigned int a, unsigned int b) { __asm__ ("%@ Inlined umul_ppmm\n" "umull %r1, %r0, %r2, %r3" : "=&r" (xh), "=&r" (xl) : "r" (a), "r" (b) : "r0", "r1"); return xl; } results in: Assembler messages: Error: selected processor does not support Thumb mode `umull r4,r5,r2,r3' It doesn't occur when using the CSL 2011.03 for example. So, I suspect a toolchain bug. I'll investigate further. Regards, Ken From code at funwithsoftware.org Wed Dec 28 11:50:22 2011 From: code at funwithsoftware.org (Patrick Pelletier) Date: Wed, 28 Dec 2011 02:50:22 -0800 Subject: fixes for small typos in random-fips.c Message-ID: <4EFAF46E.9010302@funwithsoftware.org> Hi, I just saw a few typos in random-fips.c and wanted to submit corrections. Is this the right place and format for doing so? I've pasted a diff below, which hopefully won't get badly mangled by my email client. Thanks, --Patrick diff --git a/random/random-fips.c b/random/random-fips.c index e0ae968..f45f370 100644 --- a/random/random-fips.c +++ b/random/random-fips.c @@ -104,7 +104,7 @@ static size_t entropy_collect_buffer_size; /* This random context type is used to track properties of one random generator. Thee context are usually allocated in secure memory so - that the seed value is well protected. There are a couble of guard + that the seed value is well protected. There are a couple of guard fields to help detecting applications accidently overwriting parts of the memory. */ struct rng_context @@ -141,10 +141,10 @@ struct rng_context unsigned char guard_3[1]; - /* The external test may want to suppress the duplicate bock check. + /* The external test may want to suppress the duplicate block check. This is done if the this flag is set. */ unsigned char test_no_dup_check; - /* To implement a KAT we need to provide a know DT value. To + /* To implement a KAT we need to provide a known DT value. To accomplish this the x931_get_dt function checks whether this field is not NULL and then uses the 16 bytes at this address for the DT value. However the last 4 bytes are replaced by the @@ -308,7 +308,7 @@ x931_get_dt (unsigned char *buffer, size_t length, if (!last_sec) { /* This is the very first time we are called: Set the counters - to an not so easy predictable value to avoid always + to a not so easily predictable value to avoid always starting at 0. Not really needed but it doesn't harm. */ counter1 = (u32)getpid (); #ifndef HAVE_W32_SYSTEM @@ -468,7 +468,7 @@ x931_aes_driver (unsigned char *output, size_t /* Due to the design of the RNG, we always receive 16 bytes (128 bit) of random even if we require less. The extra bytes - returned are not used. Intheory we could save them for the + returned are not used. In theory we could save them for the next invocation, but that would make the control flow harder to read. */ nbytes = length < 16? length : 16;