Skip to content
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

Merged
merged 1 commit into from
Jan 16, 2025

Conversation

xnox
Copy link
Member

@xnox xnox commented Jan 10, 2025

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.

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.
@octo-sts octo-sts bot added the bincapz/pass bincapz/pass Bincapz (aka. malcontent) scan didn't detect any CRITICALs on the scanned packages. label Jan 10, 2025
Copy link
Member

@dannf dannf left a 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.

@xnox
Copy link
Member Author

xnox commented Jan 15, 2025

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.

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.

@xnox
Copy link
Member Author

xnox commented Jan 15, 2025

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.

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.

@xnox
Copy link
Member Author

xnox commented Jan 16, 2025

forked tracing to chainguard-dev/melange#1752

@xnox xnox merged commit 80f71a7 into wolfi-dev:main Jan 16, 2025
14 checks passed
xnox added a commit that referenced this pull request Feb 13, 2025
…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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bincapz/pass bincapz/pass Bincapz (aka. malcontent) scan didn't detect any CRITICALs on the scanned packages.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants