dracut-sshd
dracut-sshd copied to clipboard
gsauthof
Integrate into upstream dracut
@danimo what would be needed to get this upstream?
Currently OpenSSH is the only ssh server with FIPS support. For a smaller solution we would need to build something using libssh.
FWIW, OpenSSH sshd doesn't add much to the initramfs.
For example, on Fedora, the impact of adding the network and ifcfg modules is much higher - and these modules aren't needed for dracut-sshd if you are using systemd-networkd.
@cryptomilk dracut has its own test suite, the travis ci-based test would need adoption. The module can just be added to the modules.d directory. Also, run "make syncheck" in the root. Once that's all done, submit a PR to dracutdevs/dracut.
I think @gsauthof would be the right person to submit it. I'm sorry but I don't have the time to find my way through github CI.
I need to ask, what would the benefit of merging this into upstream dracut be?
It makes sense that this is a standard feature of dracut. Especially the rescue shell for remote systems. Also it would be maintained there if there are changes to dracut which would need to adopt the configs/setup ...
Dracut's TODO lists this explicitly as a feature they're willing to support.
@gsauthof Are you just waiting on someone to submit it? What other work needs to be done?
Well, the TODO lists it as a 'future enhancement request'. Which basically documents that there are people who requested this enhancement. You can also read the support note as something like: 'this request is supported by Debian'.
That this TODO item is 9 years old speaks for itself.
I've even commented in 2018 on the bugzilla issue that is linked from that TODO:
https://bugzilla.redhat.com/show_bug.cgi?id=524727#c28
Also in 2018, I posted to the dracut mailinglist to get an idea what additional requirements upstream might have for getting dracut-sshd merged.
On both my bugzilla comment and the mailing posting I got zero response from upstream developers.
Thus, at that point it was pretty uncertain what amount of extra work would be required to get it upstream - and how good would be the chances getting it accepted.
As a consequence I didn't pursue that idea further, at that time.
Last year a dracut contributor commented on this issue - from that I read that a pull request would need to include some tests that fit into the existing dracut testsuite. Which is fair enough.
So if you want to submit upstream this is the main work package that needs to be done.
It's still uncertain how interested upstream would be to deal with a dracut-sshd pull-request.
I mean in the worst-case you would invest a significant amount of time creating new tests for the dracut test suite and then the pull-request would be ignored for years.
I see, thank you for the insight. I'll do some research and see how big of an effort that would be. Supposing I do manage to make an acceptable PR for dracut devs, I take it you do not mind if I submit it myself?
Of course, I don't mind. This is part of the freedom open-source software provides.
The license would need to be changed to GPLv2+ to conform with the rest of dracut, so either a rewrite or contacting all the contributors to relicense it would be the first step.
@Conan-Kudo are you speaking for the dracut development team when you are saying that dracut contributions are required to be GPLv2+ licensed?
I'm asking because dracut already mixes several licenses - including GPLv3+. For example, in dracut 050 I can find code licensed under:
- GPLv2+
- GPLv3+
- LGPLv2.1+
Also, in general, I don't see any harm in mixing GPLv2+ sources with GPLv3+ sources.
@gsauthof Hmm, for some reason I thought the project maintained GPLv2+... I knew of some of the code being LGPLv2+, but I didn't realize some GPLv3+ code existed already. Nevermind then.