On Sun, 09 Jul 2017 at 15:08:36 +0100, Colin Watson wrote:
> On Sun, Jul 02, 2017 at 11:27:44PM +0200, Guilhem Moulin wrote:
>> /usr/bin/scp — used both client and server side — is currently provided
>> by the openssh-client package. I'm currently maintaining dropbear,
>> which happens to also provide scp; it's currently not included in our
>> packages, but users have repeatedly requested it [0] and I'm wondering
>> what would be the best way to provide it.
>>
>> Quoting myself from bug #495795 msg #25,
>>
>> --8<--------------------------------------------------------------->8--
>>
>> I believe the options at hands are:
>>
>> * ask the OpenSSH maintainers to consider using an alternative for
>> their scp binary (and possibly ssh too), or
>> * provide a new package dropbear-client to ship /usr/bin/{dbclient,scp}
>> and make it conflict with openssh-client.
>>
>> Any thoughts or suggestions?
>>
>> --8<--------------------------------------------------------------->8--
>>
>> I'm currently leaning towards the second solution, but would be great to
>> have your opinion on that :-)
>
> I think it would be pretty disruptive to use alternatives (I'm sure the
> feature set won't match up absolutely precisely), so I'm not
> enthusiastic about that idea. And I'm a bit concerned about Conflicts
> possibly painting us into a corner in future.
>
> Can you tell me about the scp implementation in dropbear? For instance,
> does it differ meaningfully from OpenSSH's scp apart from being set up
> to use the dropbear client for the actual SSH protocol?
That's an excellent question, let's ask upstream :-) Matt, I think I
left enough context up here, but you can also find the thread archived
at https://lists.debian.org/debian-ssh/2017/07/msg00005.html . (I'm
trying to find a solution for Debian bug #495795.)
Meanwhile I had a look at dropbear's scp variant and AFAICT it's
actually an almost exact copy of OpenSSH 4.3p2's. (It's mentioned in
the headers, and the diff is pretty minimal.)
Besides using the dropbear client, it also differs in that it doesn't
pass options that are not understood by dbclient: ‘-x -oForwardAgent=no
-oPermitLocalCommand=no -oClearAllForwardings=yes’.
In the end it seems like it makes little sense for Debian to ship an scp
fork in the dropbear-bin package. From the #495795 submitter I
understood the concern was that with all its dependencies, installing
OpenSSH's scp can be a problem on embedded systems (in a clean sid
chroot `apt install --no-install-recommends openssh-client` pulls in 8
dependencies for a total of 10.3MiB, while `apt install dropbear-bin`
pulls in 0 dependencies.
But AFAICT OpenSSH's scp binary could very well be shipped in its own
package with a dependency on ssh-client | ssh-server (possibly
recommending both), libc6, and nothing else. The dropbear SSH client
seems to work fine with the current (1:7.5p1-5) OpenSSH scp. (It spews
some warnings due to the above options it doesn't understand, but we
could easily implement them and/or make them a no-op to keep it quiet.)
IMHO that might be the best way to fix that bug.
Matt, is there a fundamental divergence I missed between OpenSSH's scp
and dropbear's? I'd be curious to hear your opinion on the matter,
anyway :-)
Cheers,
--
Guilhem.
Attachment:
signature.asc
Description: PGP signature