On Wed, 23 Oct 2019 at 16:04:31 -0400, Anton Avramov wrote: > On Mon., Oct. 21, 2019, 21:08 Guilhem Moulin, <guilhem@debian.org> wrote: >> Given the scope of this package, I strongly believe it'd make more sense >> to merge it with src:dropbear rather than shipping a separate source >> package. > > I agree. However I don't know how I can contribute to that. It's never too late :-) `apt showsrc dropbear-initramfs` gives a link to the repository (hosted at salsa in the ‘Debian’ group). Bugs, including feature requests, are to be filed against the Debian BTS like for any other package: https://bugs.debian.org/dropbear-initramfs . >>> Following dropbear-initramfs package >> You seem to suggest that your code takes inspiration from >> dropbear-initramfs, but your copyright information doesn't reflect >> that. > > Sorry about that! I've tried to change that, but I'm not absolutely > certain I've done it right. AFAICT only src/* and etc/* are taken from src:dropbear's debian/initramfs/* (and modified by you), the rest is your own work. Also AFAICT upstream isn't a copyright holder for these scripts. Regarding debian/control, your package shouldn't break or replace dropbear <2015.68-1. This was the case the case for drobear-initramfs after the package split, but it doesn't apply here. And AFAIK there is no need to add a lower-bound on dropbear-bin's version. >>> that will install dropbear and would have the appropriate initramfs >>> scripts to start it in case the system enters rescue mode. >> >> Why couldn't that be done in dropbear-initramfs instead? Right now the >> script is run at premount stage, but I guess we could have an option to >> run it at another stage instead. > > The only argument I can think of is to give the option to have separate > access for panic and crypt unlock. > […] > And in principle I can give someone the right to unlock the fs, but > not login in case of panic where in that case and admin with higher > access should step in. One can already separate access levels with a single authorized_keys(5) file containing multiple keys and different restriction options. dropbear-initramfs spawns the sshd at init-premount stage, ie after udev has been started and modules loaded. AFAIK it's unreliable to start it earlier, because there might not be any network stack yet. So if initramfs-tools panics earlier you'll not be able to log in remotely will you? (Anyway, again ‘panic’ is not a documented initramfs-tools(7) subdirectory.) And if it panics later, for instance due to a missing block device, then one should be able to log-in using dropbear-initramfs alone. > By compatible I mean they can run together without interfering given they > use different port. Since there are only 2 scripts in initramfs I'm not > sure how would they suppose to share the code if we assume they are > different packages Using Depends: plus maybe some refactoring on the drobpear-initramfs side would be a way, but IMHO no separate binary package (let alone a source package) is needed :-P dropbear-initramfs's purpose is to expose the dropbear sshd at initramfs stage, starting as early as possible and for as long as possible. It can be useful to unlock encrypted volumes, but it's not its only use-case. -- Guilhem.
Attachment:
signature.asc
Description: PGP signature