Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 836261 - dev-lang/go-1.18: Sandbox violation due to default -buildvcs=true in go build
Summary: dev-lang/go-1.18: Sandbox violation due to default -buildvcs=true in go build
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: William Hubbs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 558556
  Show dependency tree
 
Reported: 2022-03-27 06:30 UTC by Bernd Feige
Modified: 2022-06-20 06:52 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Add -buildvcs=false when building go-1.18.3 (go-1.18.3-buildvcs.patch,384 bytes, patch)
2022-06-20 06:50 UTC, Remy Blank
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Bernd Feige 2022-03-27 06:30:03 UTC
go-based project installations started to fail now (here, app-containers/skopeo and app-containers/podman) due to sandbox violation errors.
Background is that with default -buildvcs=true in go build, different VCS are tried to get build information. The VCS commonly work their way up the directory hierarchy to find their control directory. In my case a fossil control directory is found in /var and successive accesses rightfully fail:

cd /var
fossil info
 * ACCESS DENIED:  open_wr:       /var/.fslckout
# cd /var; fossil info
repository does not exist or is in an unreadable directory: /gentoo/fossil_repo/var.fossil
error obtaining VCS status: exit status 1
	Use -buildvcs=false to disable VCS stamping.

Anyway, possible VCS information in upper directories has nothing to do with the project built and -buildvcs=false should be the default. How can this be done? Thanks!

Reproducible: Always
Comment 1 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-03-27 06:34:58 UTC
Interesting!
Comment 2 William Hubbs gentoo-dev 2022-03-27 22:29:50 UTC
I will open a bug upstream to confirm that this is the best path to
take.
Comment 3 William Hubbs gentoo-dev 2022-03-28 14:59:38 UTC
I just tested, and unfortunately adding -buildvcs=false to GOFLAGS would
cause a hard break for go versions prior to 1.18.I just tested, and
unfortunately adding -buildvcs=false to GOFLAGS would cause a hard break
for go versions prior to 1.18, so I need to come up with a way to do
this conditionally.
Comment 4 Bernd Feige 2022-03-28 16:18:08 UTC
Thanks! I am not an expert of go integration on gentoo obviously and had hoped there would be an eclass for building using go build that could have been modified... But as it turns out in app-containers/skopeo "go build" is called directly in the ebuild, while app-containers/podman uses a Makefile which is already edited by sed script. I managed now to add "-buildvcs=false" to both ebuilds and can confirm that they now install flawlessly. Seems that doing the same for every ebuild will be tedious (GOFLAGS="-buildvcs=false" emerge ... didn't work here). Possibly renaming the fossil binary before emerging will be an ugly trick in the future...
Comment 5 William Hubbs gentoo-dev 2022-03-28 16:40:15 UTC
The problem with that approach is, go-module.eclass sets GOFLAGS
globally, so you don't really want to override those.

Unfortunately I don't see a clean fix for this until go 1.17 is removed
from the tree. Once that happens, I can add the -buildvcs=false flag to
GOFLAGS.
Comment 6 Bernd Feige 2022-03-28 16:55:20 UTC
Sorry - understood go-module.eclass now.

Modifying it to add -buildvcs=false to GOFLAGS, all packages build nicely.

I see that the eclass cannot ask go for the version because go might not even be installed when the eclass runs. Tricky...

Thanks for your support!
Comment 7 William Hubbs gentoo-dev 2022-03-28 18:59:07 UTC
Yes, that is the change I would make globally, but with that change in
place, it is not possible to use go 1.17.

You are correct that go may not be installed so I can't query to find a
go version.
I think this also kills the idea of a wrapper we were discussing
upstream.

I suppose that when 1.18 goes stable I can remove 1.17 and make the
change.
Comment 8 Brand Huntsman 2022-06-20 02:33:08 UTC
Building 1.18.3 now fails and manually patching GOFLAGS in the eclass doesn't help, like it did for go packages. Downgrading to 1.17.11 produces the same error because it bootstraps using 1.18. Go must be uninstalled before downgrading to 1.17 or upgrading to 1.18.3 (and probably all future 1.18 versions).

+ ./cmd/dist/dist bootstrap -a
Building Go toolchain1 using /usr/lib/go.
error obtaining VCS status: exit status 128
        Use -buildvcs=false to disable VCS stamping.
error obtaining VCS status: exit status 128
        Use -buildvcs=false to disable VCS stamping.
error obtaining VCS status: exit status 128
        Use -buildvcs=false to disable VCS stamping.
error obtaining VCS status: exit status 128
        Use -buildvcs=false to disable VCS stamping.
go tool dist: FAILED: /usr/lib/go/bin/go install -gcflags=-l -tags=math_big_pure_go compiler_bootstrap bootstrap/cmd/...: exit status 1
Comment 9 Remy Blank 2022-06-20 06:50:54 UTC
Created attachment 786386 [details, diff]
Add -buildvcs=false when building go-1.18.3
Comment 10 Remy Blank 2022-06-20 06:52:47 UTC
The patch above adds -buildvcs=false when bootstrapping go, and this fixes the issue for me.