Hi!
On Thu, 2023-11-09 at 17:38:05 -0500, Benjamin Barenblat wrote:
> coreutils can link against OpenSSL, yielding a substantial speed boost
> in sha256sum etc. For many years, this was inadvisable due to license
> conflicts. However, as of bookworm, coreutils requires GPL-3+ and
> OpenSSL is
On 2023-11-11 09:32, Julian Andres Klode wrote:
> While libraries are dependencies of Essential packages, they
> themselves are distinctively not Essential, they are pseudo-essential.
Fair enough, but still the general point of being very careful about
what we make (pseudo-)essential is valid and
Luca Boccassi wrote on 10/11/2023 at 16:08:30+0100:
> On Fri, 10 Nov 2023 at 14:22, Pierre-Elliott Bécue wrote:
>>
>> Luca Boccassi wrote on 10/11/2023 at 15:00:24+0100:
>>
>> > On Fri, 10 Nov 2023 at 13:45, Bjørn Mork wrote:
>> >>
>> >> Luca Boccassi writes:
>> >>
>> >> > If we want to
* Theodore Ts'o:
> If you can get upstream a patch so that coreutils could try to dlopen
> OpenSSL and use it if it is available, but skip it if it is not, that
> might be one way to avoid OpenSSL going into essential. The challenge
> is that OpenSSL is not known for its ability to maintain a
On Sat, Nov 11, 2023 at 09:32:46AM +0200, Julian Andres Klode wrote:
>
> WRT dlopen(), this is never an appealing solution because you do not
> get any type-checking, you have to make sourceful changes for an soname
> bump. It is an interface you can use for loading plugins (that is, you
> should
On 2023-11-11 Michael Stone wrote:
> On Sat, Nov 11, 2023 at 11:50:31AM +0100, Andreas Metzler wrote:
> > you seem to have missed/deleted the paragraph where Ansgar suggested how
> > to do this *without* tradeoff. ("explicitly disable/enable build options
> > per arch")
> No, I didn't. That was
On Sat, Nov 11, 2023 at 11:50:31AM +0100, Andreas Metzler wrote:
you seem to have missed/deleted the paragraph where Ansgar suggested how
to do this *without* tradeoff. ("explicitly disable/enable build options
per arch")
No, I didn't. That was in my original email and is one of the
On 2023-11-10 Michael Stone wrote:
> On Fri, Nov 10, 2023 at 03:10:42PM +0100, Ansgar wrote:
>> Please avoid producing different results depending on the build
>> environment. That just results in non-reproducible issues in unclean
>> environments (suddenly different dependencies, different
On Sat, Nov 11, 2023 at 06:52:50AM +0100, Emanuele Rocca wrote:
> Hi,
>
> On 2023-11-09 07:31, Theodore Ts'o wrote:
> > If you can get upstream a patch so that coreutils could try to dlopen
> > OpenSSL and use it if it is available, but skip it if it is not, that
> > might be one way to avoid
Hi,
On 2023-11-09 07:31, Theodore Ts'o wrote:
> If you can get upstream a patch so that coreutils could try to dlopen
> OpenSSL and use it if it is available, but skip it if it is not, that
> might be one way to avoid OpenSSL going into essential. The challenge
> is that OpenSSL is not known for
On Thu, Nov 09, 2023 at 11:13:51PM +, Luca Boccassi wrote:
> > Alternatively, what would you think about making sha256sum etc.
> > divertible and providing implementations both with and without the
> > OpenSSL dependency?
>
> Please, no, no more diversion/alternatives/shenanigans, it's just
https://lists.debian.org/debian-arm/2021/06/msg1.html is the start of a
thread about support for encryption in HW, which AFAIK uses the Crypto API.
That's available on a number of arm64 devices.
It may be useful to specify/detail a test so that people can (uniformly) test
the performance on
Hi,
On 11/11/23 03:34, Julian Andres Klode wrote:
1) we use libgcrypt in libapt-pkg, which needs global initialization.
Libraries should not be doing the initialization, we're basically
misusing it.
I remember that KiCad had problems with OpenSSL for this exact reason --
we were
On Sat, Nov 11, 2023 at 12:55:16AM +0900, Simon Richter wrote:
> Hi,
>
> On 11/10/23 21:07, Stephan Verbücheln wrote:
>
> > In my opinion, this is yet another reason to use a proper cryptography
> > library (openssl, gnutls or gcrypt) instead of a custom implementation
> > for this kind of
Hi,
On 11/10/23 21:07, Stephan Verbücheln wrote:
In my opinion, this is yet another reason to use a proper cryptography
library (openssl, gnutls or gcrypt) instead of a custom implementation
for this kind of algorithm.
Yes and no. The reason several of our core tools bring their own
On Fri, 10 Nov 2023 at 14:22, Pierre-Elliott Bécue wrote:
>
> Luca Boccassi wrote on 10/11/2023 at 15:00:24+0100:
>
> > On Fri, 10 Nov 2023 at 13:45, Bjørn Mork wrote:
> >>
> >> Luca Boccassi writes:
> >>
> >> > If we want to start nitpicking, then let's be exact: 0.61% of popcon.
> >> >
On Fri, Nov 10, 2023 at 03:10:42PM +0100, Ansgar wrote:
Please avoid producing different results depending on the build
environment. That just results in non-reproducible issues in unclean
environments (suddenly different dependencies, different features,
...).
I think that is an acceptable
Luca Boccassi wrote on 10/11/2023 at 15:00:24+0100:
> On Fri, 10 Nov 2023 at 13:45, Bjørn Mork wrote:
>>
>> Luca Boccassi writes:
>>
>> > If we want to start nitpicking, then let's be exact: 0.61% of popcon.
>> > Whether that qualifies as "plenty" we'll leave as an exercise for the
>> >
On Fri, 10 Nov 2023 at 13:48, Michael Stone wrote:
>
> On Fri, Nov 10, 2023 at 10:38:13AM +, Luca Boccassi wrote:
> >Per-architecture dependencies are possible though, so maybe starting
> >to add the libssl dependency only on amd64 is a good starting point,
> >and then users of other
On Fri, 2023-11-10 at 08:48 -0500, Michael Stone wrote:
> On Fri, Nov 10, 2023 at 10:38:13AM +, Luca Boccassi wrote:
> > Per-architecture dependencies are possible though, so maybe starting
> > to add the libssl dependency only on amd64 is a good starting point,
> > and then users of other
Hi,
On Fri, 2023-11-10 at 14:45 +0100, Bjørn Mork wrote:
> I guess those 0.61% are run bt the most valuable Debian users out
> there. I'm sorry to not be one of them, but that's the way things
> have become.
Do you have any data to back up this claim? Or is it just a totally
made up guess and
On Fri, 10 Nov 2023 at 13:45, Bjørn Mork wrote:
>
> Luca Boccassi writes:
>
> > If we want to start nitpicking, then let's be exact: 0.61% of popcon.
> > Whether that qualifies as "plenty" we'll leave as an exercise for the
> > readers.
>
> I wonder if this sort of arrogant "don't care about
On Fri, Nov 10, 2023 at 10:38:13AM +, Luca Boccassi wrote:
Per-architecture dependencies are possible though, so maybe starting
to add the libssl dependency only on amd64 is a good starting point,
and then users of other architectures can request to be added too if
it is beneficial for them.
Luca Boccassi writes:
> If we want to start nitpicking, then let's be exact: 0.61% of popcon.
> Whether that qualifies as "plenty" we'll leave as an exercise for the
> readers.
I wonder if this sort of arrogant "don't care about minorities" attitude
will ever stop? Was sort of hoping that
On Fri, 10 Nov 2023 at 11:54, Matthew Vernon wrote:
>
> Luca Boccassi writes:
>
> > On Thu, 9 Nov 2023 at 22:54, Benjamin Barenblat wrote:
>
> >> What would you think about having coreutils Depend on libssl3? This
> >> would make the libssl3 package essential, which is potentially
> >>
In my opinion, this is yet another reason to use a proper cryptography
library (openssl, gnutls or gcrypt) instead of a custom implementation
for this kind of algorithm.
Over time, when these libraries add support for cryptography
acceleration instructions for more architectures, all programs
Luca Boccassi writes:
> On Thu, 9 Nov 2023 at 22:54, Benjamin Barenblat wrote:
>> What would you think about having coreutils Depend on libssl3? This
>> would make the libssl3 package essential, which is potentially
>> undesirable, but it also has the potential for serious user time savings
>>
On Fri, Nov 10, 2023 at 10:38:13AM +, Luca Boccassi wrote:
> On Fri, 10 Nov 2023 at 02:26, Simon Richter wrote:
> >
> > Hi,
> >
> > > What would you think about having coreutils Depend on libssl3? This
> > > would make the libssl3 package essential, which is potentially
> > > undesirable, but
On Fri, 10 Nov 2023 at 02:26, Simon Richter wrote:
>
> Hi,
>
> > What would you think about having coreutils Depend on libssl3? This
> > would make the libssl3 package essential, which is potentially
> > undesirable, but it also has the potential for serious user time savings
> > (on recent Intel
On Thu, Nov 09, 2023 at 05:38:05PM -0500, Benjamin Barenblat wrote:
> Dear Debian folks,
>
> coreutils can link against OpenSSL, yielding a substantial speed boost
> in sha256sum etc. For many years, this was inadvisable due to license
> conflicts. However, as of bookworm, coreutils requires
On Fri, Nov 10, 2023 at 11:25:34AM +0900, Simon Richter wrote:
> Hi,
>
> > What would you think about having coreutils Depend on libssl3? This
> > would make the libssl3 package essential, which is potentially
> > undesirable, but it also has the potential for serious user time savings
> > (on
On Thu, Nov 09, 2023 at 11:13:51PM +, Luca Boccassi wrote:
> On Thu, 9 Nov 2023 at 22:54, Benjamin Barenblat wrote:
> >
> > Dear Debian folks,
> >
> > coreutils can link against OpenSSL, yielding a substantial speed boost
> > in sha256sum etc. For many years, this was inadvisable due to
Hi,
What would you think about having coreutils Depend on libssl3? This
would make the libssl3 package essential, which is potentially
undesirable, but it also has the potential for serious user time savings
(on recent Intel CPUs, OpenSSL’s SHA-256 is over five times faster than
coreutils’
On Thu, 9 Nov 2023 at 22:54, Benjamin Barenblat wrote:
>
> Dear Debian folks,
>
> coreutils can link against OpenSSL, yielding a substantial speed boost
> in sha256sum etc. For many years, this was inadvisable due to license
> conflicts. However, as of bookworm, coreutils requires GPL-3+ and
>
Dear Debian folks,
coreutils can link against OpenSSL, yielding a substantial speed boost
in sha256sum etc. For many years, this was inadvisable due to license
conflicts. However, as of bookworm, coreutils requires GPL-3+ and
OpenSSL is Apache-2.0, so I believe all license compatibility questions
35 matches
Mail list logo
