Go: cmd/go: downloads follow plain-HTTP redirects even when the -insecure flag is not set [1.12 backport]

Created on 7 May 2019  ·  10Comments  ·  Source: golang/go

Per https://github.com/golang/go/issues/29618#issuecomment-490137320:

I've been thinking about this some more. I don't think we'll have adequate soak time on the change until after Go 1.13 is released: I suspect that the problems will be in the long tail of packages, and users on the long tail by and large are not testing against HEAD on a nightly basis.

While this is a security issue, I don't think it's major enough to risk breaking long-tail packages at a point release.

I'm going to tentatively schedule the 1.12 backport for a couple of weeks after the 1.13 release, when we'll have a clearer view of just how broken the long tail is.

CherryPickCandidate FrozenDueToAge

Most helpful comment

@stefanb, this is not standing in the way of a release. (If it were, it would be labeled release-blocker.)

All 10 comments

I'm going to tentatively schedule the 1.12 backport for a couple of weeks after the 1.13 release, when we'll have a clearer view of just how broken the long tail is.

@bcmills Can you clarify what you meant by "a couple of weeks after the 1.13 release"? After the final 1.13 release (as in "v1.13.0" in semver form), or something else? If so, we should move this to a later 1.12.x milestone.

After the final 1.13 release. I want folks to be able to go back to a supported 1.12 release as a mitigation if they discover a secure-to-insecure redirect when moving to 1.13.

Moving to Go1.12.8, as 1.13 is not yet out.

It seems that this is standing in a way of 1.12.8 release with some urgent bugfixes (eg #33405)
I think this one should be moved to 1.12.9 milestone, to be released after 1.13.

@stefanb, this is not standing in the way of a release. (If it were, it would be labeled release-blocker.)

Yep, this is why this should be postponed to the next milestone/release so that 1.12.8 could be released asap and this with the next release (1.12.9) few weeks after 1.13 (it currently has several active release blockers).

The point is, changing the milestone of this issue is not going to affect when the 1.12.8 release occurs.

If we backport this fix, we should also backport CL 193259 which fixes a regression introduced in it.

That said, I think this is too complex to backport, given the complication noted in https://github.com/golang/go/issues/29591#issuecomment-479881945.

(Decided not to backport; closing.)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jayhuang75 picture jayhuang75  ·  3Comments

natefinch picture natefinch  ·  3Comments

mingrammer picture mingrammer  ·  3Comments

dominikh picture dominikh  ·  3Comments

myitcv picture myitcv  ·  3Comments