Bug#860429: unblock: golang-go.crypto/1:0.0~git20170407.0.55a552f-1

[Niels Thykier <niels@thykier.net>]

Control: tags -1 moreinfo

Michael Lustfield:
> Package: release.debian.org
> User: release.debian.org@packages.debian.org
> Usertags: unblock
> Severity: normal
> 
> Please unblock package golang-go.crypto
> 
> About 18 days ago, a security issue was patched [1] in this package. For reasons
> not directly related to the CVE [2], an upload to unstable was done about 9 days
> after the relevant security update. I have not yet confirmed the fix is in
> unstable (haven't had the time available, yet), but believe it's there.
> 
> While the patch itself is relatively simple [3], there is a large delta from
> testing and the debdiff is quite substantial (~16,000 lines). Unfortunately, I
> agree with the severity and RC status... and this package has a very large
> number of reverse build dependencies against it. Adding to the headache, this
> change introduces an unavoidable breaking change.
> 
> I know the current unstable package needs d/NEWS,chglog updated before an
> acceptable debdiff could be presented. I now see other security updates [4]
> have been resolved since the version in testing.
> 
> This is my first time requesting a freeze exception or trying to handle one at
> all and the list of reverse dependencies has me a feeling a little uneasy. If
> anyone is interested in mentoring (or taking over), please do!
> 
> [1] https://github.com/golang/go/issues/19767
> [2] https://security-tracker.debian.org/tracker/CVE-2017-3204
> [3] https://github.com/golang/crypto/commit/e4e2799dd7aab89f583e1d898300d96367750991
> [4] https://github.com/golang/go/issues?q=label%3ASecurity+is%3Aclosed
> [-] https://bugs.debian.org/859655
> 
> unblock golang-go.crypto/1:0.0~git20170407.0.55a552f-1
> 
> [...]

Hi Michael,

Thanks for bringing this issue to our attention. This is a very
unfortunate situation.

 * First of all.  AFAIUT, the change will at least possibly break the
   following packages:

     * golang-github-jamesclonk-vultr
     * aptly
     * gitlab-ci-multi-runner
     * kubernetes
     * golang-github-pkg-sftp
     * golang-github-spf13-afero
     * golang-github-kisom-goutils
     * packer

   They need to be fixed or removed from testing before we can even
   consider doing an exception for this breaking change.

 * Secondly, is it correctly understood of me that the issue is
   basically that golang-go.crypto defaults to not validating an SSH
   key, but a client /can/ do so with the current API?  The fix is
   then to require the client to explicitly choose a way to deal with
   SSH keys?

Thanks,
~Niels