[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#551010: openssh: New Feature: Add support for PKCS#11 authentication via new binary package



On Wed, Oct 14, 2009 at 06:08:50PM -0400, Joshua Kinard wrote:
> The attached patch is a re-base of the openssh_5.1p1-8.diff.gz file
> for the 'openssh' source package.  This patch includes patches to
> enable PKCS#11 support as a completely new binary package,
> openssh-client-pkcs11.  The debian/control and debian/rules files have
> been modified to the best of my ability, and they successfully build a
> PKCS#11-enabled deb that is independent from the more common
> openssh-client deb (and everything looks intact).  The openssh-server
> deb is left alone, as I haven't seen a need for the server to have
> this support in my uses (so far).

Thanks for your patch. However, I really, really, *really* do not want
to add new binary packages for new features. We just got away from that
with Kerberos. Adding new binary packages with different variations of
OpenSSH substantially increases the basic complexity of the packaging
(already complex) and invites combinatorial explosion. As a general rule
I do not intend to accept any patches that add new binary packages.

Can you try to load the relevant libraries dynamically instead? That
would make the packaging end of things much simpler. I realise it
involves more complex code, which is why nobody's done it yet ...

> The patches were sent upstream well over two years ago, and the bug
> associated with this feature has been constantly neglected by upstream
> for unspecified reasons.  The bug, however, continues to receive
> updates to the patchset should the upstream developers ever choose to
> act on the feature.  Said bug is here:
> https://bugzilla.mindrot.org/show_bug.cgi?id=1371

While I sympathise with the difficulty of getting changes upstream, I'm
not sure that the correct workaround for this is to try to get it into
distributions instead. I do have some security background, but I'm
nowhere near as competent as upstream to review the security properties
of this patch (I see Damien Miller has made some comments, albeit
infrequent).

I'm also concerned that this adds new command-line options (what happens
if upstream decide they're going to use it for something else? We would
be pretty comprehensively screwed as far as compatibility goes) and new
agent protocol numbers (ssh-agent is not the only implementation of the
OpenSSH agent protocol out there, so what would happen if upstream used
some of the numbers in that patch for something else?). Downstream
distributions are not, as a rule, good places to be making these kinds
of changes, even though the licence entitles us to do so.

I sympathise with the goal, but I'm just not sure that it's feasible to
do it this way.

Regards,

-- 
Colin Watson                                       [cjwatson@debian.org]



Reply to: