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 [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
