Bug#790125: RFS: dropbear/2015.67-1.1 NMU
Hi all, sorry for the late reply.
On Thu, Aug 20, 2015 at 07:23:55AM +, Gianfranco Costamagna wrote:
> Hi Gerrit,
>
> >Alright, would it help moving forward if I were doing that? Reverting
>
> >to 2014.65 is easy, and the current 2015.68-1 could always be uploaded
> >once 2014.65-1 has entered testing. It'd be quite sad to upload known
> >bugs in a package containing multiple lintian warnings and errors [0],
> >but if someone is willing to review and upload the package, but only
> >with the split of dropbear-{bin,run,initramfs} and without the many
> >extra bug fixes, then I'm ready to clean, test and release [1].
>
>
> I didn't follow the thread, and seems that other DDs are already caring of
> this one, so I would just put my .02$ (and let me know if you need a review
> or help).
>
> Just a few questions:
> 1) Gerrit, you offered to add the package, but Guilhem might need to
> comaintain it,
> is that fine for you?
>
> Seems impossible to nmu it because of a binary package he starts to maintain.
>
> 2) what about updating to the latest version and upload on experimental?
>
> I don't see all this need to go for unstable, I might even sponsor an
> experimental upload
> because if Gerrit is not satisfied he can continue and upload his version to
> unstable,
> and experimental will disappear automagically.
>
> Isn't this one the experimental suite pourpose?
> We are still in the Stretch early stage, we might delay unstable until other
> folks tested it.
I'm currently not active, so I'm very happy with Guilhem bringing this
forward. I'm not particularly happy with the switch to debhelper, but
do not veto if it's necessary to progress.
Comaintenance is fine too. I not yet know Guilhem and his work for
Debian, but this won't change too soon, because my time to spend on
Debian is currently quite limited.
I hope Guilhem finds a sponsor soon.
Regards, Gerrit.
Bug#790125: RFS: dropbear/2015.67-1.1 NMU
Hi Gianfranco,
On Thu, 20 Aug 2015 at 07:23:55 +, Gianfranco Costamagna wrote:
I didn't follow the thread, and seems that other DDs are already caring of
this one, so I would just put my .02$ (and let me know if you need a review
or help).
Thanks! So far only Helmut has given feedback and offered to have
another look when time allows. I'll ping you if there is no follow-up
by the end of the month or so. (That said I wouldn't mind more eyeballs
looking at the package either ;-)
2) what about updating to the latest version and upload on experimental?
I don't see all this need to go for unstable, I might even sponsor an
experimental upload
because if Gerrit is not satisfied he can continue and upload his version to
unstable,
and experimental will disappear automagically.
Isn't this one the experimental suite pourpose?
We are still in the Stretch early stage, we might delay unstable until other
folks tested it.
If by “update to the latest version” you meant my dropbear-{bin,run,initramfs}
packages,
you'll find them there:
dget -x
http://mentors.debian.net/debian/pool/main/d/dropbear/dropbear_2015.68-0.1.dsc
Cheers,
--
Guilhem.
signature.asc
Description: Digital signature
Bug#790125: RFS: dropbear/2015.67-1.1 NMU
Hi Gerrit,
Alright, would it help moving forward if I were doing that? Reverting
to 2014.65 is easy, and the current 2015.68-1 could always be uploaded
once 2014.65-1 has entered testing. It'd be quite sad to upload known
bugs in a package containing multiple lintian warnings and errors [0],
but if someone is willing to review and upload the package, but only
with the split of dropbear-{bin,run,initramfs} and without the many
extra bug fixes, then I'm ready to clean, test and release [1].
I didn't follow the thread, and seems that other DDs are already caring of
this one, so I would just put my .02$ (and let me know if you need a review
or help).
Just a few questions:
1) Gerrit, you offered to add the package, but Guilhem might need to comaintain
it,
is that fine for you?
Seems impossible to nmu it because of a binary package he starts to maintain.
2) what about updating to the latest version and upload on experimental?
I don't see all this need to go for unstable, I might even sponsor an
experimental upload
because if Gerrit is not satisfied he can continue and upload his version to
unstable,
and experimental will disappear automagically.
Isn't this one the experimental suite pourpose?
We are still in the Stretch early stage, we might delay unstable until other
folks tested it.
just my .02$
Gianfranco
Bug#790125: RFS: dropbear/2015.67-1.1 NMU
Hi there,
On Thu, 30 Jul 2015 at 22:21:21 +0200, Helmut Grohne wrote:
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?
Alright, would it help moving forward if I were doing that? Reverting
to 2014.65 is easy, and the current 2015.68-1 could always be uploaded
once 2014.65-1 has entered testing. It'd be quite sad to upload known
bugs in a package containing multiple lintian warnings and errors [0],
but if someone is willing to review and upload the package, but only
with the split of dropbear-{bin,run,initramfs} and without the many
extra bug fixes, then I'm ready to clean, test and release [1].
Cheers,
--
Guilhem.
[0] https://lintian.debian.org/full/p...@smarden.org.html#dropbear_2014.65-1
[1]
https://gitweb.guilhem.org/dropbear?p=dropbear;a=commit;h=64ea640134b67e68daad2096d54afc91b0722895
signature.asc
Description: Digital signature
Bug#790125: RFS: dropbear/2015.67-1.1 NMU
Hi Helmut, On Fri, 31 Jul 2015 at 07:46:26 +0200, Helmut Grohne wrote: That was quick. Let me answer some of your comments already. I intend to take another stab at the upload when I find more time, but that shall not prevent other interested sponsors from uploading it earlier. Possibly Gerrit replied by then. I still have a hope to make it to Debconf (I'm currently on the waiting list :-/). Would be great to make it happen there! FYI upstream made a new release today. That includes a fix to the two issues you reported in #27; my own patches included in patches/series have been applied as well. http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2015q3/001777.html However, this time I didn't pull in the changes (although Debian is now 3 releases behind…) On Fri, Jul 31, 2015 at 05:44:09AM +0200, Guilhem Moulin wrote: Alright, this one is new to me. I'm not sure how blindly I can follow https://wiki.debian.org/Multiarch/Implementation#dh.281.29_and_autotools because dropbear-bin ships an executable ‘/usr/lib/dropbear/dropbearconvert’. So checked the package source for openssh and found that openssh-server uses Multi-Arch:foreign, but openssh-sftp-server, which ships ‘/usr/lib/openssh/sftp-server’, doesn't. So all in all I'm unsure what to in my case. It is actually much easier than that. Since dropbear does not ship any libraries or similar, the only Multi-Arch tag that makes sense is foreign. So this is mostly a matter of asking: Does a package expose its architecture via one of its public interfaces? If the answer is no, then foreign is appropriate. […] I didn't spot any reason for not marking all of the dropbear packages M-A:foreign, but this probably warrants a closer look. Thanks for the explanation. Yes, ‘Multi-Arch: foreign’ is the right tag in that case. I have updated my debian/control, but I'll wait for a second round of feedback before uploading the package to mentors. -- Guilhem. signature.asc Description: Digital signature
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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#790125: RFS: dropbear/2015.67-1.1 NMU
Hi Helmut,
On Thu, 30 Jul 2015 at 22:21:21 +0200, Helmut Grohne wrote:
Thanks for your work on dropbear. Much appreciated.
And thanks for the extensive feedback! I know it's quite a heavy
changelog, so I didn't really expect anyone other than Gerrit perhaps to
check it out that closely.
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.
Yeah true, I might have taken too much liberty here. I noticed upstream
was already two releases ahead so I wildly pulled in the new tarball :-/
(plus it fixed #775222 ;-) Then I couldn't split the package without
doing major refactoring (which thanks to debhelper automatically solved
#689618, #692932, #777324, #793006, #793917). And later I guess I got
carried away with enthusiasm on the way and decided to try to fix the
remaining bugs (some of them were quite old, and most fixes were rather
easy; at least the one relevant to the initramfs feature, which didn't
seem to be maintained anymore, and which bothered me personally since I
use this feature myself) :-P
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.
No worries. Constructive criticism never hurts anyway ;-)
Since you bump the upstream release your NMU version should be -0.1
instead of -1.1.
Thanks, fixed.
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.
Well spotted. I guess one ought to file a bug.
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.)
In fact in a later mail in the d-d thread Gerrit agreed to make
“dropbear” a transitional package and place binaries to “dropbear-bin”,
as suggested to me by Adam Borowski:
https://lists.debian.org/debian-devel/2015/06/msg00290.html
Since dropbear-initramfs relies on initramfs-tools 0.94 features, the
dependency should be versioned.
Thanks, fixed. (Didn't think it mattered since even oldoldstable has
said feature.)
If you disable password logins by default, please mention in a NEWS
entry!
It was never enabled in the initramfs (disabling it without notice would
have been foolish otherwise, indeed). The change I made (initramfs-only
only) is to no longer make the server *advertise* it, so that clients
won't prompt for a password and try to send it to the server (which is
bound to reject it anyway). Sorry for the confusion.
Would it make sense to install the NEWS file to the transitional package
only? (i.e. mv debian/NEWS debian/dropbear.NEWS)
Yes it would! Fixed, thanks for the suggestion.
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.)
You mean if upstream starts deprecate options used in
dropbear-{initramfs,run}? Which by the way seems to happen right now
with ‘-d’ with is now an alias for ‘-r’ but has been removed from the
manpage, see #761143. (And now I realize I could have written a note
regarding s/-d/-r/ in the NEWS regarding that change :-/)
Yeah that makes sense, I tightened the dependency by specifying the
${binary:Version}.
Please consider whether Multi-Arch:foreign markings are appropriate for
some packages.
Alright, this one is new to me. I'm not sure how blindly I can follow
https://wiki.debian.org/Multiarch/Implementation#dh.281.29_and_autotools
because dropbear-bin ships an executable ‘/usr/lib/dropbear/dropbearconvert’.
So checked the package source for openssh and found that openssh-server
uses Multi-Arch:foreign, but openssh-sftp-server, which ships
‘/usr/lib/openssh/sftp-server’, doesn't. So all in all I'm unsure what
to in my case.
Why are dropbear-{initramfs,run} marked as Architecture:any? Do they
contain any architecture specific
Bug#790125: RFS: dropbear/2015.67-1.1 NMU
Control: tags -1 - moreinfo Hi Guilhem, That was quick. Let me answer some of your comments already. I intend to take another stab at the upload when I find more time, but that shall not prevent other interested sponsors from uploading it earlier. Possibly Gerrit replied by then. On Fri, Jul 31, 2015 at 05:44:09AM +0200, Guilhem Moulin wrote: In fact in a later mail in the d-d thread Gerrit agreed to make “dropbear” a transitional package and place binaries to “dropbear-bin”, as suggested to me by Adam Borowski: https://lists.debian.org/debian-devel/2015/06/msg00290.html I must have missed that while scanning the thread. Thanks. Since dropbear-initramfs relies on initramfs-tools 0.94 features, the dependency should be versioned. Thanks, fixed. (Didn't think it mattered since even oldoldstable has said feature.) Your remark is very relevant here. That's a good reason to do an unversioned dependency. I simply forgot to look up when 0.94 was released. Alright, this one is new to me. I'm not sure how blindly I can follow https://wiki.debian.org/Multiarch/Implementation#dh.281.29_and_autotools because dropbear-bin ships an executable ‘/usr/lib/dropbear/dropbearconvert’. So checked the package source for openssh and found that openssh-server uses Multi-Arch:foreign, but openssh-sftp-server, which ships ‘/usr/lib/openssh/sftp-server’, doesn't. So all in all I'm unsure what to in my case. It is actually much easier than that. Since dropbear does not ship any libraries or similar, the only Multi-Arch tag that makes sense is foreign. So this is mostly a matter of asking: Does a package expose its architecture via one of its public interfaces? If the answer is no, then foreign is appropriate. Let me give examples what exposure means here. gcc creates ELF objects. So by compiling a .c file you get different output per architecture. Anything that contains a shared library generally exposes the architecture. A special example is pkg-config. It is marked M-A:foreign, but the output of pkg-config foo --libdir often depends on the architecture of pkg-config. Here, it is considered that pkg-config is not part of the public interface (from a Multi-Arch pov) and one should run $(DEB_HOST_GNU_TYPE)-pkg-config instead (which autotools do). Another special example is locales (which is Arch:all). It compiles locales during postinst and exposes the native architecture via those files generated during postinst. I didn't spot any reason for not marking all of the dropbear packages M-A:foreign, but this probably warrants a closer look. Yes, it's to make dh_installdocs happy, and avoid it spitting WARNING: --link-doc between architecture all and not all packages breaks binNMUs What are you suggesting as an alternative? There is a tradeoff to be made here. You can always consider not using --link-doc. Since the documentation directory is fairly small for dropbear, little is gained by using --link-doc (embedded installations that want to shrink the system can always add --path-exclude=/usr/share/doc/* to dpkg, which is guaranteed to work by the policy). Furthermore, not using --link-doc allows partitioning the documentation to make it easier to find. There is no right or wrong way here. That said I'm happy to learn more and I have added the header already. Removing moreinfo accordingly. In future, please remove the tag yourself when addressing the reason it was added. No I *extend* CFLAGS with -DSFTPSERVER_PATH='/usr/lib/sftp-server'. Aren't CPPFLAGS and LDFLAGS passed as is already? The build log seems to suggests it at least. Oh right. Seeing CFLAGS on the command line, it didn't occur to me that the other variables would go via the environment. Thanks for clarifying. That said, while I understand the heavy changelog is frown upon by potential sponsors, I have to say I would find it quite frustrating if my work on this package, including the fixes to the many bugs regarding dropbear-initramfs (which I heavily rely on in my own infrastructure), wasn't eventually uploaded :-P I do hope that all of these changes land in stretch. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#790125: RFS: dropbear/2015.67-1.1 NMU
Hi Vincent, Gerrit, On Tue, 14 Jul 2015 at 18:42:53 -0700, Vincent Cheng wrote: NMUs are intended to be minimally intrusive and be targeted to fix specific bugs (and usually RC/important ones); that means that in general, you should avoid things like new upstream releases and extensive packaging changes, and your proposed debdiff should be as small as possible. Yes I know: I intended to split the initramfs stuff, but I couldn't make multiple binary packages into the same source package without major refactoring. Your changes are more in scope of a package adoption than a NMU. I'd be open for adoption of dropbear-initramfs indeed, but it's best to keep the same source package for the three dropbear-*, hence my offer to co-maintenance instead ;-) While I don't want to discourage you from doing extensive work to improve dropbear, you'll likely find it difficult to find a DD other than the maintainer who's willing to sponsor this as a NMU. Fair enough, I'll wait then. Thanks for you answer anyway :-) -- Guilhem. signature.asc Description: Digital signature
Bug#790125: RFS: dropbear/2015.67-1.1 NMU
Control: tag -1 + moreinfo
Hi Guilhem,
On Sat, Jun 27, 2015 at 5:40 AM, Guilhem Moulin guil...@guilhem.org wrote:
Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for my package dropbear
* Package name: dropbear
Version : 2015.67-1.1
Upstream Author : Matt Johnston m...@ucc.asn.au
* URL : http://matt.ucc.asn.au/dropbear/
* License : MIT
Section : net
It builds those binary packages:
dropbear - transitional dummy package for dropbear-{run,initramfs}
dropbear-bin - lightweight SSH2 server and client - command line tools
dropbear-initramfs - lightweight SSH2 server and client - initramfs
integration
dropbear-run - lightweight SSH2 server and client - startup scripts
To access further information about this package, please visit the following
URL:
http://mentors.debian.net/package/dropbear
Alternatively, one can download the package with dget using this command:
dget -x
http://mentors.debian.net/debian/pool/main/d/dropbear/dropbear_2015.67-1.1.dsc
More information about dropbear can be obtained from
http://matt.ucc.asn.au/dropbear/ .
The maintainer told me to go ahead a proceed with the NMU [0].
Changes since the last upload:
* Non-maintainer upload.
[ Matt Johnston ]
* New upstream release. (Closes: #775222.)
[ Guilhem Moulin ]
* debian/source/format: 3.0 (quilt)
* debian/compat: 9
* debian/control: bump Standards-Version to 3.9.6 (no changes necessary).
* debian/copyright: add machine-readable file.
* Split up package in dropbear-bin (binaries), dropbear-run (init scripts)
and dropbear-initramfs (initramfs integration). 'dropbear' is now a
transitional dummy package depending on on dropbear-run and
dropbear-initramfs. (Closes: #692932.)
* Refactorize the package using dh_* tools, including dh_autoreconf.
(Closes: #689618, #777324.)
* dropbear-run:
+ Add a status option to the /etc/init.d script.
+ Pass key files with -r not -d in /etc/init.d script. (Closes: #761143.)
+ Post-installation script: Generate missing ECDSA in addition to RSA and
DSS host keys. (Closes: #776976.)
* dropbear-initramfs:
+ Don't mark /usr/share/initramfs-tools/conf-hooks.d/dropbear as a
configuration file, since it violates the Debian Policy Manual section
10.7.2. (Regression from 2014.64-1.)
+ Delete debian/initramfs/premount-devpts, since /dev/pts in mounted by
init since initramfs-tools 0.94. (Closes: #632656.)
+ Auto-generate host keys in the postinstall script, not when runing
update-initramfs. Pass the '-R' option (via $PKGOPTION_dropbear_OPTION)
for the old behavior. Also, print fingerprint and ASCII art for
generated keys (if ssh-keygen is available).
+ Revert ad2fb1c and remove warning about changing host key. Users
shouldn't be encouraged to use the same keys in the encrypted partition
and in the initramfs. The proper fix is to use an alternative port or
UserKnownHostFile.
+ Set ~root to `mktemp -d $DESTDIR/root-XX` to avoid collisions with
$rootmnt. (Closes: #558115.)
+ Exit gracefully if $IP is 'none' or 'off'. (Closes: #692932.)
+ Start dropbear with flag -s to explicitly disable password logins.
+ Terminate all children before killing dropbear, to avoid stalled SSH
connections. (Closes: #735203.)
+ Run configure_networking in the foreground. (Closes: #584780, #626181,
#739519.)
+ Bring down interfaces and flush network configuration before existing
the ramdisk, to avoid misconfigured network in the regular kernel.
(Closes: #715048, #720987, #720988.)
+ Add a script '/bin/unlock' to the initramfs to make remote unlocking
easier and possibly as a forced-command restrictions in authorized_keys.
NMUs are intended to be minimally intrusive and be targeted to fix
specific bugs (and usually RC/important ones); that means that in
general, you should avoid things like new upstream releases and
extensive packaging changes, and your proposed debdiff should be as
small as possible. Your changes are more in scope of a package
adoption than a NMU. While I don't want to discourage you from doing
extensive work to improve dropbear, you'll likely find it difficult to
find a DD other than the maintainer who's willing to sponsor this as a
NMU.
Regards,
Vincent
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#790125: RFS: dropbear/2015.67-1.1 NMU
Dear mentors, I am still in need for a sponsor for my package dropbear, so please allow me to bump the thread :-) https://bugs.debian.org/790125 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. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/dropbear Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/d/dropbear/dropbear_2015.67-1.1.dsc Feedback would also be appreciated, whether it leads to sponsorship or not. Cheers, -- Guilhem. signature.asc Description: Digital signature
Bug#790125: RFS: dropbear/2015.67-1.1 NMU
Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for my package dropbear
* Package name: dropbear
Version : 2015.67-1.1
Upstream Author : Matt Johnston m...@ucc.asn.au
* URL : http://matt.ucc.asn.au/dropbear/
* License : MIT
Section : net
It builds those binary packages:
dropbear - transitional dummy package for dropbear-{run,initramfs}
dropbear-bin - lightweight SSH2 server and client - command line tools
dropbear-initramfs - lightweight SSH2 server and client - initramfs
integration
dropbear-run - lightweight SSH2 server and client - startup scripts
To access further information about this package, please visit the following
URL:
http://mentors.debian.net/package/dropbear
Alternatively, one can download the package with dget using this command:
dget -x
http://mentors.debian.net/debian/pool/main/d/dropbear/dropbear_2015.67-1.1.dsc
More information about dropbear can be obtained from
http://matt.ucc.asn.au/dropbear/ .
The maintainer told me to go ahead a proceed with the NMU [0].
Changes since the last upload:
* Non-maintainer upload.
[ Matt Johnston ]
* New upstream release. (Closes: #775222.)
[ Guilhem Moulin ]
* debian/source/format: 3.0 (quilt)
* debian/compat: 9
* debian/control: bump Standards-Version to 3.9.6 (no changes necessary).
* debian/copyright: add machine-readable file.
* Split up package in dropbear-bin (binaries), dropbear-run (init scripts)
and dropbear-initramfs (initramfs integration). 'dropbear' is now a
transitional dummy package depending on on dropbear-run and
dropbear-initramfs. (Closes: #692932.)
* Refactorize the package using dh_* tools, including dh_autoreconf.
(Closes: #689618, #777324.)
* dropbear-run:
+ Add a status option to the /etc/init.d script.
+ Pass key files with -r not -d in /etc/init.d script. (Closes: #761143.)
+ Post-installation script: Generate missing ECDSA in addition to RSA and
DSS host keys. (Closes: #776976.)
* dropbear-initramfs:
+ Don't mark /usr/share/initramfs-tools/conf-hooks.d/dropbear as a
configuration file, since it violates the Debian Policy Manual section
10.7.2. (Regression from 2014.64-1.)
+ Delete debian/initramfs/premount-devpts, since /dev/pts in mounted by
init since initramfs-tools 0.94. (Closes: #632656.)
+ Auto-generate host keys in the postinstall script, not when runing
update-initramfs. Pass the '-R' option (via $PKGOPTION_dropbear_OPTION)
for the old behavior. Also, print fingerprint and ASCII art for
generated keys (if ssh-keygen is available).
+ Revert ad2fb1c and remove warning about changing host key. Users
shouldn't be encouraged to use the same keys in the encrypted partition
and in the initramfs. The proper fix is to use an alternative port or
UserKnownHostFile.
+ Set ~root to `mktemp -d $DESTDIR/root-XX` to avoid collisions with
$rootmnt. (Closes: #558115.)
+ Exit gracefully if $IP is 'none' or 'off'. (Closes: #692932.)
+ Start dropbear with flag -s to explicitly disable password logins.
+ Terminate all children before killing dropbear, to avoid stalled SSH
connections. (Closes: #735203.)
+ Run configure_networking in the foreground. (Closes: #584780, #626181,
#739519.)
+ Bring down interfaces and flush network configuration before existing
the ramdisk, to avoid misconfigured network in the regular kernel.
(Closes: #715048, #720987, #720988.)
+ Add a script '/bin/unlock' to the initramfs to make remote unlocking
easier and possibly as a forced-command restrictions in authorized_keys.
Cheers,
--
Guilhem.
[0] https://lists.debian.org/debian-devel/2015/06/msg00285.html
signature.asc
Description: Digital signature
