[systemd-devel] [RFC] Switching to OpenSSL 3?

[Michael Biebl]

For some reason I sent this message to Lennart only back then, which
wasn't my intention.
Re-sending it to the mailing list.

Am Do., 16. Sept. 2021 um 19:25 Uhr schrieb Michael Biebl <mbiebl at gmail.com>:
>
> Hi Lennart, hi everyone!
>
> First, a couple of remarks regarding the Debian package:
> So far, I tried to avoid enabling any OpenSSL dependent features (e.g.
> repart) for the simple reason that I didn't want to pull in two SSL
> stacks into systemd  (we already enable GnuTLS related bits).
> Consolidating around a single SSL library will definitely make this simpler.
>
> W.r.t. to OpenSSL 3: There is currently a package in experimental [1].
> It's possible/very likely, that its maintainer will start a transition
> to OpenSSL 3 during the bookworm development cycle, which just started
> now.
> But there hasn't been any official announcement yet in that regard.
> And given the size of the transition, I don't expect this to be
> trivial [2]. I also don't expect that there will be any efforts to
> make OpenSSL 1 and 3 co-installable.
> This also means, that it is highly unlikely that there will be a
> backport of OpenSSL for bullseye, our current stable release.
>
> This brings me to the next point: backports
>
> I typically provide backports of newer systemd versions for the
> current stable release. (I did this for jessie, stretch and buster)
> and I planned to do that for bullseye as well.
> Mainly for two reasons: popular demand and it also proved to be useful
> when filing upstream bug reports. With systemd's rather strict
> requirement to only accept bug reports for the last 2 releases, it is
> much easier for me to convince users to install a systemd backport
> then upgrading their stable system to unstable.
>
> Not being able to provide this service to users for the next 2 years
> is not the end of the world, but it's a bit of a nuisance. For the
> second part, maybe upstream could be a bit more lenient to accept such
> bug reports with older systemd versions during the transition to
> OpenSSL 3?
>
> Last but not least: The licensing issue brought up by Luca regarding
> the GPLv2 incompatibility. This is very unfortunate and I haven't
> really checked if and how that affects rdeps of libsystemd0. Maybe
> Luca already did that work. In this case, I'd be very interested in
> his feedback here.
>
> Using GnuTLS would avoid all that afaics, no?
>
> Just curious: Can you elaborate why GnuTLS only is not an option.
>
> Regards,
> Michael
>
> [1] https://tracker.debian.org/news/1257327/accepted-openssl-300-1-source-into-experimental/
> [2] https://release.debian.org/transitions/html/auto-openssl.html
>
> Am Di., 14. Sept. 2021 um 13:36 Uhr schrieb Lennart Poettering
> <lennart at poettering.net>:
> >
> > Heya!
> >
> > Some of the systemd developers have been discussing switching
> > systemd's crypto libraries to be exclusively OpenSSL 3.0, and drop
> > support for older OpenSSL versions, as well as any GNUTLS/libgcrypt
> > support. As you might have noticed OpenSSL 3.0 has been released
> > recently, and for the first time resolves the GPL2 license
> > incompatibility mess comprehensively, which opens this door to us.
> >
> > I personally care a lot about reducing the combinatorial explosion of
> > deps a bit, and keeping our tree as maintainable as we can, with a
> > single implementation of everything, not multiple, and no abstraction
> > layers and such, and thus removing any compat kludges for other
> > libraries or other library versions.
> >
> > Now, before we make a decision on this, I'd like to collect feedback
> > on such a move. I know that there are some people who backpart new
> > systemd onto old distros. How big would the pain be require porting
> > OpenSSL 3, too, at the same time?
> >
> > (What's not up for discussion: for new additions to systemd we'll do
> > only OpenSSL, and won't accept anything else. My question is really
> > just about the stuff we aleady have, where we currently support
> > GNUTLS/libcgrypt.).
> >
> > Anyway, I'd be interested in your thoughts about this. i.e. hear
> > multiple takes, opinions, from differently people and positions?
> >
> > Thanks,
> >
> > Lennart