search

gsauthof / dracut-sshd

Provide SSH access to initramfs early user space on Fedora and other systems that use Dracut
242 stars 30 forks source link

Integrate into upstream dracut #8

Open cryptomilk opened 5 years ago

cryptomilk commented 5 years ago

@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.

gsauthof commented 5 years ago

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.

danimo commented 5 years ago

@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.

cryptomilk commented 5 years ago

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.

cryptomilk commented 5 years ago

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 ...

LaserEyess commented 4 years ago

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?

gsauthof commented 4 years ago

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.

LaserEyess commented 4 years ago

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?

gsauthof commented 4 years ago

Of course, I don't mind. This is part of the freedom open-source software provides.

Conan-Kudo commented 4 years ago

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.

gsauthof commented 4 years ago

@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:

Also, in general, I don't see any harm in mixing GPLv2+ sources with GPLv3+ sources.

Conan-Kudo commented 4 years ago

@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.