-
Notifications
You must be signed in to change notification settings - Fork 300
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
openssf-compiler-options: include melange spec files #39242
Conversation
If exist, include melange generated spec file from workspace. No errors produced if the melange generated spec file is missing. Potentially worth exploring to also always load $HOME/.gcc.spec, which may make it easier to customize gcc spec files on per-package basis.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @xnox ! +1 to get this off the ground, but a couple of things I'd like to discuss, more related to the melange side of things:
I was wondering why we chose a workspace instead of a system path, but I see you raised the same question in your melange commit message. The workspace feels too volatile - something that should be owned by the package YAML. I think it could make developers more likely to consider in-place sed hacks to it instead of using one of the existing override mechanisms. (I'm a guilty party, but I'm thinking we could implement a pipeline for cases like mine). While I prefer /etc/melange
, would /melange
would be more idiomatic in a container world? That would reserve /etc/melange
for a melange-running-in-wolfi use case.
I feel like we should add some explicit messages in the logs when this is in use, especially during this startup period. While we can likely search for melange version numbers, a directly "grep-able" string might be easier to use for some quick bulk searches.
see chainguard-dev/melange#1750 because all paths inside the container are writable; currently we cannot build apko image with arbitrary extra text file which didn't come from an apk; and everything is mutable - so we need to do other build isolation work with most container files own by root (not the builder accounts uid) to actually make files in / to be not writable by the builder process. Hence all of this is moot for now until we fix lots of the pre-requisites to make any container/host files immutable. |
ok. We can land all of this things for the three packages; and then demo it and see how much more verbose we can make this. Because yes, I agree more verbosage would be nice. Cranking up gcc debug output is possible => but that's so much spam, it will be impossible to read the build logs. I guess melange emitting that it is writting this file would help. |
forked tracing to chainguard-dev/melange#1752 |
…cc specs for C, C++, Rust, Go. (#39152) Cannot land this PR in one go, thus split openssf-compiler-options (first commit) into separate PR to land first: - #39242 - **openssf-compiler-options: include melange spec files** If exist, include melange generated spec file from workspace. No errors produced if the melange generated spec file is missing. Potentially worth exploring to also always load $HOME/.gcc.spec, which may make it easier to customize gcc spec files on per-package basis. - **Use new spec file with optional include** As an e2e test for three packages (written in C/Go/Rust). This enables using the future spec file with melange generated spec file include. When these land in images, and SBOM/Vulnerability/Console all look good we can roll this out by default. NB! This PR needs melange that generates the dynamic gcc spec file which is being optionally included. Once this lands for three packages in question, images are tested, and any bugs/issues resolved, we can remove the opt-in, and make the ELF notes the default.
This is part 1 / pre-requisite to land:
If exist, include melange generated spec file from workspace.
No errors produced if the melange generated spec file is missing.
Potentially worth exploring to also always load $HOME/.gcc.spec, which
may make it easier to customize gcc spec files on per-package basis.