x/crypto: release-branch.go1.12 was removed

[dansnoddy]

What version of Go are you using (go version)?

1.12

Does this issue reproduce with the latest release?

Using dep to pull dependencies against 1.12 fails now because the release-branch-go1.12 is no longer available for crypto. Last week the 1.12 was available for crypto, today we only see 1.13.

[ianlancetaylor]

I'm not sure what you mean. When I look at the golang.org/x/crypto repo, I can still checkout release-branch.go1.12. Can you expand on exactly what is not working?

[dansnoddy]

We used to see the following when resolving crypto:

21 external packages imported from 18 projects
(0) ✓ select (root)
(1) ? attempt golang.org/x/crypto with 1 pkgs; 4 versions to try
(1) try golang.org/x/crypto@master
(2) ✗ golang.org/x/crypto@master not allowed by constraint release-branch.go1.12:
(2) release-branch.go1.12 from (root)
(1) try golang.org/x/[email protected]
(2) ✗ golang.org/x/[email protected] not allowed by constraint release-branch.go1.12:
(2) release-branch.go1.12 from (root)
(1) try golang.org/x/[email protected]
(1) ✓ select golang.org/x/[email protected] w/1 pkgs

Now we see:

(1) ? attempt golang.org/x/crypto with 1 pkgs; 1 versions to try
(1) try golang.org/x/crypto@master
(2) ✗ golang.org/x/crypto@master not allowed by constraint release-branch.go1.12:
(2) release-branch.go1.12 from (root)
(1) ← no more versions of golang.org/x/crypto to try; begin backtrack

The 4 versions that used to be available are now only 1. When I look in golang/crypto, I see:

Active branches
release-branch.go1.13

[dansnoddy]

@ianlancetaylor Any chance this is an issue in how we pull the dependencies using dep. While I see changes in the crypto repo, I don't know whether 1.12 was dropped. At least from dep, I can't access it.

[FiloSottile]

release-branch.go1.12 was intentionally removed because it did not point to anything meaningful. The x/ repo release branches are just there to track the tree that is vendored in the corresponding release of the main Go tree. Unfortunately the vendored x/crypto in Go 1.12 is a mix of different commits, so there is no meaningful commit for release-branch.go1.12 to point to.

The release branches in x/crypto are really internal implementation details, they are not documented and not covered by our security policies, and I didn't know anyone actually used them. What's the use case you are addressing by using them?

[dansnoddy]

@FiloSottile We used terminal.ReadPassword

[FiloSottile]

@danws2020 I didn't mean why you are using x/crypto (there are of course a number of reasons for that) but why you are using release-branch.go1.12.

[albertjin]

I think it's related and I am not going to file a separated issue. Here is what I see for branch release-branch.go1.13:

Is there a hidden branch named release-branch.go1.13-security, which is not synced at Github? This is similar to the situation of branch release-branch.go1.12.

[dansnoddy]

We are still on 1.12 because there wasn't enough time to recertify for 1.13.

[rittneje]

What’s the point of having these release branches? Just merge directly to master. Also, claiming that release branches are an internal detail is kind of silly. This is a public repo.

[FiloSottile]

I think it's related and I am not going to file a separated issue. Here is what I see for branch release-branch.go1.13:

Is there a hidden branch named release-branch.go1.13-security, which is not synced at Github? This is similar to the situation of branch release-branch.go1.12.

Yes, release-branch.go1.13-security will get merged to release-branch.go1.13 before the next release, this is documented at https://github.com/golang/go/wiki/MinorReleases#security-releases

[FiloSottile]

We are still on 1.12 because there wasn't enough time to recertify for 1.13.

This seems to be a misunderstanding: there is no 1.12 release of the x/crypto repository. You can (and probably should) use x/crypto master with Go 1.12, just like any other Go module.

If you want to pin a specific commit, you can do that without tracking a specific branch. I don't know how that works with dep but it's certainly possible.

To sum up, please don't rely on the undocumented release branches in the x/ repos, sorry if we made it sound like they were supported at any point.

[wgja]

Well, it breaks our builds too - we used release-branch.go1.11... until now. Not a nice thing to call a branch "release-branch-etcetc" then just remove it.

[ianlancetaylor]

@wgja Yes. We made a mistake. Our apologies. We'll try to avoid making similar mistakes going forward.

[wgja]

Any chance to bring back the branch or at least a tag for that commit? Newer releases are incompatible with the go version we use.

[FiloSottile]

@wgja My apologies for the confusion and the breakage. To clarify, release-branch.go1.11 does NOT mean "the code that's compatible with Go 1.11", but "the code that ships in the vendor folder of Go 1.11". You should treat x/crypto like you treat any other module, and pin the latest commit that works for you. As long as a Go release is maintained, it will work with x/crypto master. Go 1.11 is unmaintained so you might indeed have to pin an old commit.

[wgja]

@FiloSottile
" and pin the latest commit that works for you."
That was the tip of "release-branch.go1.11"... Is there any way to find out which commit was that?

(Also: what about git tags instead of branches?)

[FiloSottile]

@wgja I believe that was 56440b8.

We need branches to make cherry-picks on them if we need to change the code vendored in old Go releases, but again, these are not things anyone externally should rely on.