-
Notifications
You must be signed in to change notification settings - Fork 39
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
fix: improve parsing of Package.gz metadata, matching Debian parser logic #43
fix: improve parsing of Package.gz metadata, matching Debian parser logic #43
Conversation
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
I've just signed the CLA on behalf of myself for my GitHub user. Let me know if there's anything I can do to get this moved along! |
Could you provide more information on why this is necessary? |
@thesayyn certainly! I have updated the PR to contain more details around the nature of this fix. I did include a bit more information in my issue that I am happy to copy/paste over here for completeness. |
Okay, ignoring the lines start with X sounds like workaround. looks like this is successfully parsed by other parsers, we should fix the parser to allow there to be nothing after the |
Agreed on it being more of a workaround. Let me see if I can wrestle this logic into something similar to those links you've referenced. |
Something like this should work:
|
Thanks @thesayyn ! That was an immense help. I was able to get a successful run against my lockfile with those changes. If you wouldn't mind glancing at this again, it would be appreciated! The only addition I added to your logic was the stripping of leading whitespace. I thought it was causing issues when running locally, but that was not the case. It seems like a good practice to strip that out, but happy to remove that logic if necessary. |
ed7f4e6
to
b3b6ef4
Compare
Looks great, stripping sounds good but i am afraid it might break some other code path as parsing doesn't have a unit test for edge cases. Can we remove that part? |
Removed! |
Some buildifier errors on CI, you can run: |
It does seem that I am able to reproduce the whitespace issue consistently (making me think I fell victim to caching on my prior comment.) I am now cleaning my workspace as a means of verification: without whitespace trim:
with whitespace trim:
|
Alright, we should be good for (another) review. Thanks for the whitespace spot, I would have been here for a few more hours 😝 Buildifier is showing no changes after making these updates, CI should hopefully reflect the same. |
Thank you! |
Problem
On Ubuntu 24.04, and likely other distributions - a Package is able to be published to Ubuntu repositories with non-standard formatting.
Example (package
btm
):The current parser logic of
rules_distroless
assumes that all keys will be followed immediately with a value which is not a newline. In this case, the improper formatting here implies an empty value set forX-Cargo-Built-Using
and then tries to do key/val parsing logic on the list of dependencies used to compile the package in question.This results in the following error when running:
Solution
This PR complements the issue I've opened up here: #42
This PR sanitizes package metadata when parsing the
Packages.gz
archive on a given Debian/Ubuntu repositiory to allow for newlines and other characters which may follow a:
in keyval definition.Verification Evidence