On 12/16/2013 09:27 PM, Ludovic Courtès wrote:
> l...@gnu.org (Ludovic Courtès) skribis:
>
>> Pádraig Brady skribis:
>>
>>> The speed of md5 and sha* hashes has lagged a bit in gnulib.
>>> So to address that and to take advantage of the architecture
>>> specific assembly used in libcrypto, the at
l...@gnu.org (Ludovic Courtès) skribis:
> Pádraig Brady skribis:
>
>> The speed of md5 and sha* hashes has lagged a bit in gnulib.
>> So to address that and to take advantage of the architecture
>> specific assembly used in libcrypto, the attached gnulib patch
>> allows projects to configure --wi
On 12/09/2013 12:15 AM, Paul Eggert wrote:
> Pádraig Brady wrote:
>> * m4/gl-openssl.m4 (gl_CRYPTO_CHECK): Don't empty LIB_CRYPTO
>
> That would inherit LIB_CRYPTO from the environment, no?
> It might be better to move the LIB_CRYPTO= into the
> initialization code.
I pushed the attached to fix t
On 12/09/2013 01:40 AM, Paul Eggert wrote:
> Pádraig Brady wrote:
>> Where would be best to initialize this?
>
> Maybe m4_divert_once([DEFAULTS], [LIB_CRYPTO=])?
I'll try it out.
>> The libgcrypt replacement calling out to libcrypto seems to work.
>> tests pass anyway.
>
> I assume you're prep
Pádraig Brady wrote:
> Where would be best to initialize this?
Maybe m4_divert_once([DEFAULTS], [LIB_CRYPTO=])?
> The libgcrypt replacement calling out to libcrypto seems to work.
> tests pass anyway.
I assume you're preparing a
gnulib patch that would prefer libgcrypt to libcrypto, or
somethin
On 12/09/2013 12:15 AM, Paul Eggert wrote:
> Pádraig Brady wrote:
>> * m4/gl-openssl.m4 (gl_CRYPTO_CHECK): Don't empty LIB_CRYPTO
>
> That would inherit LIB_CRYPTO from the environment, no?
> It might be better to move the LIB_CRYPTO= into the
> initialization code.
Right, I was worried about tha
Pádraig Brady wrote:
> * m4/gl-openssl.m4 (gl_CRYPTO_CHECK): Don't empty LIB_CRYPTO
That would inherit LIB_CRYPTO from the environment, no?
It might be better to move the LIB_CRYPTO= into the
initialization code.
Also, is libgcrypt compatible with libcrypt with
respect to MD5, SHA512, etc.?
On 12/03/2013 12:03 AM, Pádraig Brady wrote:
> On 12/02/2013 10:48 PM, Paul Eggert wrote:
>> On 12/02/2013 01:05 PM, Pádraig Brady wrote:
>>> each project would have
>>> to add LIB_CRYPTO_MD5 etc. to their list of libs similarly
>>> to the coreutils patch I had inline in my previous mail.
>>
>> Tha
On 12/03/2013 06:28 PM, Pádraig Brady wrote:
> On 12/03/2013 05:47 PM, Paul Eggert wrote:
>> Perhaps I'm reading too much into the standards, but that's how
>> --with-jpeg etc. behave in GNU Emacs 'configure'.
>
> Well I agree, that's how I expect --with options to work generally.
> Making the exi
On 12/03/2013 11:08 PM, Eric Blake wrote:
> On 12/03/2013 03:44 PM, Eric Blake wrote:
>
>>
>> Libvirt would prefer a solution that uses nettle, at least when used in
>> RHEL.
>
> Correction: libvirt would prefer a solution that uses gnutls, and could
> live with a solution that uses openssl. Cer
Perhaps I'm reading too much into the standards, but that's how
--with-jpeg etc. behave in GNU Emacs 'configure'.
FWIW, I think you are right, and --with should fail if the specified
package is not installed, per the standards text. Alternatively, it
could configure "as if" the with-packa
On 12/03/2013 03:44 PM, Eric Blake wrote:
>
> Libvirt would prefer a solution that uses nettle, at least when used in
> RHEL.
Correction: libvirt would prefer a solution that uses gnutls, and could
live with a solution that uses openssl. Certification-wise, indirect
use of nettle via gnutls is
On 12/03/2013 03:19 PM, Nikos Mavrogiannopoulos wrote:
> On Tue, 2013-12-03 at 17:39 +0100, Ludovic Courtès wrote:
>> Pádraig Brady skribis:
>>
>>> The speed of md5 and sha* hashes has lagged a bit in gnulib.
>>> So to address that and to take advantage of the architecture
>>> specific assembly us
On Tue, 2013-12-03 at 17:39 +0100, Ludovic Courtès wrote:
> Pádraig Brady skribis:
>
> > The speed of md5 and sha* hashes has lagged a bit in gnulib.
> > So to address that and to take advantage of the architecture
> > specific assembly used in libcrypto, the attached gnulib patch
> > allows proj
ni...@lysator.liu.se (Niels Möller) writes:
> I haven't paid much attention to x86_64 assembly for sha1 and md5 (there
> is x86_64 assembly for sha1, which is a direct translation of an earlier
> version of the x86 assembly, and there's no md5-assembly at all for
> x86_64).
I just checked in a so
On 12/03/2013 05:47 PM, Paul Eggert wrote:
> On 12/03/2013 05:45 AM, Pádraig Brady wrote:
>> I'll probably do this in coreutils configure.ac before gl_INIT,
>> so as to at least set the default as coreutils wants and caters for,
>> and allowing users to --without-openssl if they want.
>>
>> dnl Ena
On 12/03/2013 05:45 AM, Pádraig Brady wrote:
> I'll probably do this in coreutils configure.ac before gl_INIT,
> so as to at least set the default as coreutils wants and caters for,
> and allowing users to --without-openssl if they want.
>
> dnl Enable use of libcrypto by default
> AS_VAR_SET_IF([w
l...@gnu.org (Ludovic Courtès) writes:
> Pádraig Brady skribis:
>
>> The speed of md5 and sha* hashes has lagged a bit in gnulib.
>> So to address that and to take advantage of the architecture
>> specific assembly used in libcrypto, the attached gnulib patch
>> allows projects to configure --wit
On 12/03/2013 10:08 AM, Pádraig Brady wrote:
> Now it should be fairly easy to map the gnulib interface
> to the nettle one, so we might in future provide a --with-nettle
> option to gnulib similar to the current --with-openssl
Or maybe more like the threads interface, where we have
--with-crypto
On 12/03/2013 04:57 PM, Niels Möller wrote:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> Pádraig Brady skribis:
>>
>>> The speed of md5 and sha* hashes has lagged a bit in gnulib.
>>> So to address that and to take advantage of the architecture
>>> specific assembly used in libcrypto, the attach
Pádraig Brady skribis:
> The speed of md5 and sha* hashes has lagged a bit in gnulib.
> So to address that and to take advantage of the architecture
> specific assembly used in libcrypto, the attached gnulib patch
> allows projects to configure --with-openssl to use that if
> available or fall ba
On 12/03/2013 06:24 AM, Paul Eggert wrote:
> Pádraig Brady wrote:
>> Seems the handiest way to do this is to do the following
>> in configure.ac before gl_INIT:
>>
>> dnl Enable use of libcrypto by default
>> AC_ARG_WITH([openssl],
>> [AS_HELP_STRING([--with-openssl],
>> [use libcrypto hash r
Pádraig Brady wrote:
> Seems the handiest way to do this is to do the following
> in configure.ac before gl_INIT:
>
> dnl Enable use of libcrypto by default
> AC_ARG_WITH([openssl],
> [AS_HELP_STRING([--with-openssl],
> [use libcrypto hash routines if available: default=yes])],
> [],
> [
On 12/03/2013 01:48 AM, Paul Eggert wrote:
> Thanks, that works for me; please install it into gnulib
> when you have the time.
>
> I do have some minor stylistic suggestions, but they're not crucial.
Pushed with whitespace adjusted.
thanks for the review!
Pádraig.
On 12/02/2013 02:12 PM, Pádraig Brady wrote:
> To use this from coreutils I configure with --with-openssl
> Note since the new libs are required, then is one of the reasons
> I didn't enable this by default. A related question though
> is I'd like coreutils to change the default to enable this by
Paul Eggert wrote:
> + { (void) OPENSSL_FN(_Init) ((_gl_CTX *) ctx); }
Also, please put that open curly brace at the start of the line,
as that part of the GNU coding standards.
Thanks, that works for me; please install it into gnulib
when you have the time.
I do have some minor stylistic suggestions, but they're not crucial:
+GL_OPENSSL_INLINE void
+GL_CRYPTO_FN(_init_ctx) (struct _gl_ctx *ctx)
+ { (void) OPENSSL_FN(_Init) ((_gl_CTX *) ctx); }
Space before pa
On 12/02/2013 10:48 PM, Paul Eggert wrote:
> On 12/02/2013 01:05 PM, Pádraig Brady wrote:
>> each project would have
>> to add LIB_CRYPTO_MD5 etc. to their list of libs similarly
>> to the coreutils patch I had inline in my previous mail.
>
> Thanks for explaining.
>
> I tried that for Emacs and
On 12/02/2013 01:05 PM, Pádraig Brady wrote:
> each project would have
> to add LIB_CRYPTO_MD5 etc. to their list of libs similarly
> to the coreutils patch I had inline in my previous mail.
Thanks for explaining.
I tried that for Emacs and came up with the patch
appended to this message. Unfort
On 12/02/2013 07:50 PM, Paul Eggert wrote:
> On 12/02/2013 06:12 AM, Pádraig Brady wrote:
>> To use this from coreutils I configure with --with-openssl
>> and add in the appropriate libs as follows.
>> Note since the new libs are required, then is one of the reasons
>> I didn't enable this by defau
On 12/02/2013 06:12 AM, Pádraig Brady wrote:
> To use this from coreutils I configure with --with-openssl
> and add in the appropriate libs as follows.
> Note since the new libs are required, then is one of the reasons
> I didn't enable this by default. A related question though
> is I'd like core
The speed of md5 and sha* hashes has lagged a bit in gnulib.
So to address that and to take advantage of the architecture
specific assembly used in libcrypto, the attached gnulib patch
allows projects to configure --with-openssl to use that if
available or fall back to the existing internal routine
32 matches
Mail list logo
