Re: [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 :
>
> 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
> :
> >
> > 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

Re: [systemd-devel] the need for a discoverable sub-volumes specification

[Topi Miettinen]

On 9.11.2021 23.03, Lennart Poettering wrote:

On Di, 09.11.21 19:48, Topi Miettinen (toiwo...@gmail.com) wrote:


i.e. we'd drop the counting suffix.


Could we have this automatic versioning scheme extended also to service
RootImages & RootDirectories as well? If the automatic versioning was also
extended to services, we could have A/B testing also for RootImages with
automatic fallback to last known good working version.


At least in the case of RootImage= this was my implied assumption:
we'd implement the same there, since that uses the exact same code as
systemd-nspawn's image dissection and we definitely want it there.

Doing this RootDirectory= would make a ton of sense too I guess, but
it's not as obvious there: we'd need to extend the setting a bit I
think to explicitly enable this logic. As opposed to the RootImage=
case (where the logic should be default on) I think any such logic for
RootDirectory= should be opt-in for security reasons because we cannot
safely detect environments where this logic is desirable and discern
them from those where it isn't. In RootImage= we can bind this to the
right GPT partition type being used to mark root file systems that are
arranged for this kind of setup. But in RootDirectory= we have no
concept like that and the stuff inside the image is (unlike a GPT
partition table) clearly untrusted territory, if you follow what I am
babbling.


My images don't have GPT partition tables, they are just raw squashfs 
file systems. So I'd prefer a way to identify the version either by 
contents of the image (/@auto/ directory), or something external, like 
name of the image (/path/to/image/foo.version-X.Y). Either option would 
be easy to implement when generating the image or directory.


But if you have several RootDirectories or RootImages available for a 
service, what would be the way to tell which ones should be tried if 
there's no GPT? They can't all have the same name. I think using a 
specifier (like %q) would solve this issue nicely and there wouldn't be 
a need for /@auto/ in that case.



Or in other words: to enable this for RootDirectory= we probably need
a new option RootDirectoryVersioned= or so that takes a boolean.


Wouldn't this be unnecessary, if the version magic would be available 
explicitly as specifier to the path of RootDirectory= or RootImage=? 
Then we know that the configuring user made this decision.


-Topi