[staging] go: upgrade bootstrap to 1.18 #241776
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Tested with ipfs/kubo and keybase. Causes the following rebuilds 2404 packages updated |
SuperSandro2000
approved these changes
Jul 5, 2023
|
@ofborg build go_1_18.tests go_1_19.tests go_1_20.tests |
|
darwin is failing, as almost all the time when targeting staging, due to a missing lvm in cache which times out when building from source on ofborg. |
|
Are you sure about the "security" label? The bootstrap compiler should only be used during... bootstrapping, so the main security impact should be dropping CVEs from outputs of tools like vulnix? |
|
This has strong "checking a box" feels for me. I looked at a couple of the 9.8'ers and I am pretty sure they aren't applicable to any of the code in the Go tree.. Is there more information about where it's impacted? Perhaps
|
|
Yeah, agree there isn't any benefit from this but didn't really have any technical reasons to reject it. |
|
I also wanted to change bootstrap version but I stopped after reading golang/go#44505 it contains reasoning for not adopting 1.18 as bootstrap for 1.20 also current master still uses 1.17 as bootstrap that being said, I don't object this PR |
Honestly yeah a bit of anxiety from having those listed in my As for why 1.18 that is the minimum version still supported on Nix and recently EOLed so that major version wont be updating often. (Different from 1.19/1.20 still receiving patch releases)
I would say that is no longer applicable since 1.18 is EOL (and would hope most issues were fixed) + self bootstrapping of go upstream has stronger assurance requirements (trusting trust) than nix binary bootstrapping not part of stdenv (trusted binary to compile the upstream compiler that is not further used to keep bootstrapping) |
|
Here is the result of a recent (wink wink, nudge nudge #242640)
Others can correct me if I am wrong - but the bootstrap stuff is outside of the EOL constraints because you always need to be able to bootstrap (that's why 1.4 release will never go away). I am not terribly opposed to this going in - biggest concern I have is that it will cause build churn for no real benefit. Other than that, I build stable versions of Go using tip pretty frequently (for weird OSs) without issue. Shrug :D |
|
We're now using 1.21 to bootstrap Both Closing this as the churn isn't really worth it but thanks anyway for the PR. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of changes
Current 1.16/1.17 bootstrapping dates to at least before
Changes vulnix entries from:
Addresses
Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)