On 27/02/2024 21:36, Bruno Haible wrote:
Pádraig Brady wrote:
Does this work for all the various names of libcrypto in various distros?
Debian 12 libcrypto.so.3
Ubuntu 22.04libcrypto.so.1.1 libcrypto.so.3
Slackware 15libcrypto.so.1.1
openSUSE 15.5 libcrypto.so.1.1
CentOS Stream
Pádraig Brady wrote:
> > Does this work for all the various names of libcrypto in various distros?
> >
> > Debian 12 libcrypto.so.3
> > Ubuntu 22.04libcrypto.so.1.1 libcrypto.so.3
> > Slackware 15libcrypto.so.1.1
> > openSUSE 15.5 libcrypto.so.1.1
> > CentOS Stream 9 libcrypto.so.3
Paul Eggert wrote:
> Thanks for the patch. I was hoping that we didn't need to worry about
> older platforms needing -ldl. Oh well.
Distros with glibc < 2.34 include:
Debian 11
CentOS 8 stream
Fedora 34
openSUSE 15.5
Slackware 15
These are not obsolete, so far.
> The patch causes 'conf
Thanks for the patch. I was hoping that we didn't need to worry about
older platforms needing -ldl. Oh well.
The patch causes 'configure' to search for dlopen even when there's no
crypto library. 'configure' could instead use AC_SEARCH_LIBS only if the
AC_LINK_IFELSE fails (or simply put AC_LI
On 27/02/2024 11:15, Bruno Haible wrote:
Paul Eggert wrote:
I installed the
attached patch into coreutils. With it, 'sort -R' continues to use MD5
but on GNUish platforms 'sort' links libcrypto dynamically only if -R is
used (Bruno's suggestion). This doesn't significantly affect 'sort -R'
perfo
Paul Eggert wrote:
> I installed the
> attached patch into coreutils. With it, 'sort -R' continues to use MD5
> but on GNUish platforms 'sort' links libcrypto dynamically only if -R is
> used (Bruno's suggestion). This doesn't significantly affect 'sort -R'
> performance, and reduces the startu
On 26/02/2024 18:06, Andreas Schwab wrote:
On Feb 26 2024, Pádraig Brady wrote:
https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=3bbdb3938
It's still bad as it adds a hidden dependency that is invisible to rpm.
Right. In practice though since coreutils also links libcrypto
for
On 2024-02-26 06:12, Pádraig Brady wrote:
On 26/02/2024 06:44, Yann Collet wrote:
* xxhash128 is not a cryptographic hash function, so it doesn't
attempt tobe random.
Just a correction : xxh128 does try to be random. And quite hardly: a
significant amount of development is spent on ensuring
On Feb 26 2024, Pádraig Brady wrote:
> https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=3bbdb3938
It's still bad as it adds a hidden dependency that is invisible to rpm.
Also, the regexp in the sed command contains unquoted uses of '.' that
are supposed to be matched literally.
--
On 26/02/2024 17:39, Bruno Haible wrote:
Pádraig Brady wrote:
+ void *handle = dlopen ("libcrypto.so", RTLD_LAZY | RTLD_GLOBAL);
That only works if libopenssl-devel is installed.
Good spot.
I'd already pushed a fix for this at:
https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=3
Pádraig Brady wrote:
> >> + void *handle = dlopen ("libcrypto.so", RTLD_LAZY | RTLD_GLOBAL);
> >
> > That only works if libopenssl-devel is installed.
>
> Good spot.
> I'd already pushed a fix for this at:
> https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=3bbdb3938
Does this work
On 26/02/2024 17:11, Andreas Schwab wrote:
On Feb 25 2024, Paul Eggert wrote:
+/* Dynamically link the crypto library, if it needs linking. */
+static void
+link_libcrypto (void)
+{
+#if DLOPEN_LIBCRYPTO && HAVE_OPENSSL_MD5
+ void *handle = dlopen ("libcrypto.so", RTLD_LAZY | RTLD_GLOBAL);
On Feb 25 2024, Paul Eggert wrote:
> +/* Dynamically link the crypto library, if it needs linking. */
> +static void
> +link_libcrypto (void)
> +{
> +#if DLOPEN_LIBCRYPTO && HAVE_OPENSSL_MD5
> + void *handle = dlopen ("libcrypto.so", RTLD_LAZY | RTLD_GLOBAL);
That only works if libopenssl-devel
even
though randomness is a pre-requisite (but not sufficient in itself) to
collision resistance.
From: Paul Eggert
Date: Sunday, February 25, 2024 at 10:25 PM
To: Pádraig Brady , Bruno Haible ,
bug-gnulib@gnu.org , Coreutils
Cc: Yann Collet
Subject: Re: sort dynamic linking overhead
On 2023-10-
On 26/02/2024 06:44, Yann Collet wrote:
* xxhash128 is not a cryptographic hash function, so it doesn't attempt tobe
random.
Just a correction : xxh128 does try to be random. And quite hardly: a
significant amount of development is spent on ensuring this property.
It’s even tested with Prac
On 2023-10-09 06:48, Pádraig Brady wrote:
An incremental patch attached to use xxhash128 (0.8.2)
shows a good improvement (note avx2 being used on this cpu):
xxhash128 is not a cryptographic hash function, so it doesn't attempt to
be random. Of course most people won't care - it's random "eno
On 08/10/2023 21:53, Pádraig Brady wrote:
On 08/10/2023 14:36, Pádraig Brady wrote:
On 07/10/2023 22:29, Paul Eggert wrote:
On 2023-10-07 04:42, Pádraig Brady wrote:
The auto linking is globally controlled with the --with-openssl
cofigure option, but you could build sort (and md5sum)
without
On 08/10/2023 14:36, Pádraig Brady wrote:
On 07/10/2023 22:29, Paul Eggert wrote:
On 2023-10-07 04:42, Pádraig Brady wrote:
The auto linking is globally controlled with the --with-openssl
cofigure option, but you could build sort (and md5sum)
without that dependency with:
./configure ac_
18 matches
Mail list logo
