Bug#790125: RFS: dropbear/2015.67-1.1 NMU
Control: tags -1 + moreinfo
Hi Guilhem,
Thanks for your work on dropbear. Much appreciated.
On Sat, Jul 11, 2015 at 03:20:52PM +0200, Guilhem Moulin wrote:
> Note that while the current maintainer (Gerrit, CC'ed) told me to go
> ahead and proceed with a NMU, they are not able to sponsor me at the
> moment. Furthermore I'm currently a DM and would be open to
> co-maintenance once time is ripe.
My reading of Gerrit's mail is a bit more limited. He wrote to d-devel:
| Unfortunately I cannot support you, but don't hesitate to NMU the
| dropbear package to be able to proceed.
May be this is hair-splitting, but I'd read this as NMUing specifically
for the purpose of splitting out the initramfs stuff (and then moving it
to a different source package). I'd not assume that doing a new upstream
release is covered by the above. Maybe Gerrit can clarify that or we can
go via a delayed queue.
Despite me having lots of comments, your changes are actually of high
quality. Don't get scared! Some comments are picky/matter of taste. Feel
free to disagree.
Since you bump the upstream release your NMU version should be -0.1
instead of -1.1.
I note that the new tilde expansion functionality in the upstream
release is a bit strange. If my own home is "/home/helmut", it will
expand "~/foo" to "/home/helmut//foo" (note the double slash). Worse, it
will expand expand "~otheruser/foo" to "/home/helmut/otheruser/foo",
which does not match the general expectation of tilde expansion.
The new m_free(X) macro ends in a semicolon which can cause lots of bad
things (the old one wasn't better).
Gerrit asked for the binaries to be located in "dropbear", but you place
them in "dropbear-bin". Maybe Gerrit can also ack this? (It was stated
as a preference.)
Since dropbear-initramfs relies on initramfs-tools 0.94 features, the
dependency should be versioned.
If you disable password logins by default, please mention in a NEWS
entry!
Would it make sense to install the NEWS file to the transitional package
only? (i.e. mv debian/NEWS debian/dropbear.NEWS)
It might be safer in the future if dropbear-{initramfs,run} use a (=
${binary:Version}) dependency on dropbear-bin. Will you remember to bump
such a dependency when dropbear-run starts to use a new option? (But
--link-doc incurs this dependency anyway.)
Please consider whether Multi-Arch:foreign markings are appropriate for
some packages.
Why are dropbear-{initramfs,run} marked as Architecture:any? Do they
contain any architecture specific files? Is that an artifact of
--link-doc only? Maybe reconsider whether --link-doc is worth
duplicating these packages for each architecture.
I think it is an unfortunate choice to license the initramfs unlock
stuff under GPL when the rest of the package is MIT. That's your choice
of course. The mixing of GPL-2+ and GPL-3+ doesn't make things better.
Your GPL license paragraphs should include the actual license grant, not
just the reference to the GPL. (I think this point would be sufficient
for a ftp-master rejection. This incurs the moreinfo tag.)
dropbear-initramfs.postinst exits before running #DEBHELPER# unless $1
is "configure". #DEBHELPER# should be run unconditionally.
In dropbear-initramfs.postinst, when ssh-keygen is unavailable, the
creation of the $pubkey could be avoided.
Some of those comments also apply to dropbear-run.postinst.
It should not be necessary to pass --host to dh_auto_configure, as it
does that automatically for cross builds only.
You pass CFLAGS to dh_auto_configure. Why do you not pass CPPFLAGS or
LDFLAGS to configure? Both typically enable further hardening features.
In general, I'd find sponsoring this NMU much easier if the package
split and the fixing of those many bugs could happen in separate
uploads. Each part is complex and the fallout is hard to estimate. I
understand that such a separation would mean more work for you. Do you
think that doing this in two steps is worth the added effort?
Helmut
Reply to: