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?

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/crypto@release-branch.go1.11
(2) ✗ golang.org/x/crypto@release-branch.go1.11 not allowed by constraint release-branch.go1.12:
(2) release-branch.go1.12 from (root)
(1) try golang.org/x/crypto@release-branch.go1.12
(1) ✓ select golang.org/x/crypto@release-branch.go1.12 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

@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.

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?

@FiloSottile We used terminal.ReadPassword

@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.

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.

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

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.

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

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.

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.

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

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.

@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.

@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?)

@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.