-
Notifications
You must be signed in to change notification settings - Fork 41
feat: add check-advisories to check BRSA fields #604
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
base: develop
Are you sure you want to change the base?
Conversation
ba9f677 to
1eb07a3
Compare
jmt-lab
left a comment
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.
LGTM
ed9e89a to
9b86a6b
Compare
|
Fixed some of the comments above. |
34db683 to
a78f0ec
Compare
|
Resolved all comments. |
6179367 to
8a85572
Compare
cbgbt
left a comment
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.
I had to fix the advisories in the earlier versions because they didn't have patched-epoch field. We can plan on either defaulting to 0 here or add those fields in the advisories.
Zero as a default should be OK. RPM treats unspecified as 0.
I noticed that bottlerocket-core-kit/advisories/2.1.0/BRSA-1j0o73qa.toml has an odd patched version:
patched-version = "kernel-5.15.160-104.158.amzn2"
I suppose this just shows up as a warning? What should happen here?
|
8d45429 to
f064191
Compare
|
Fixed all comments. |
e24be77 to
d3f188d
Compare
0d1536d to
5ef22a5
Compare
cbgbt
left a comment
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.
Do we still need changes to Makefile.toml to ensure that these get run during a kit build? Maybe I missed it, but I'm not seeing how this gets invoked.
| fn validate_advisories(spec_path: &Path, advisories_dir: &Path) -> Result<()> { | ||
| let pkg_metadata = get_rpm_metadata(spec_path)?; | ||
|
|
||
| if !pkg_metadata.is_empty() { |
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.
Should it be an error if we can't extract RPM metadata?
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.
There are 2 sources of error.
- rpmspec command fails - this means its a malformed spec file and build would fail later.
- output doesn't have 3 parts: name, epoch, version - I couldn't get it to fail on a valid spec file. If epoch is not present then the value is
(none). Name and version are mandatory fields and would just cause command failure above.
| Ok(()) | ||
| } | ||
|
|
||
| fn check_advisory( |
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.
Can we get an integration test with edge cases for this? We have other integration tests in twoliter that build kits. This logic seems correct, but it's pretty hard to know without tests.
This runs as part of the |
twoliter/embedded/build.Dockerfile
Outdated
| RUN --mount=source=advisories,target=/home/builder/advisories \ | ||
| --mount=target=/host \ | ||
| /host/build/tools/advisory-checker rpmbuild/SPECS/${PACKAGE}.spec /home/builder/advisories/ |
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.
Better to run this before the package build.
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.
I placed it before the rpmbuild but after we put the sources and macros in the right place. Should I move this before that and add the line for copying macros into this?
8dbc4e4 to
dc3a561
Compare
Signed-off-by: Piyush Jena <jepiyush@amazon.com>
dc3a561 to
8802745
Compare
| RUN --mount=source=advisories,target=/home/builder/advisories \ | ||
| --mount=target=/host \ | ||
| /host/build/tools/advisory-checker --spec-file rpmbuild/SPECS/${PACKAGE}.spec --advisories-dir /home/builder/advisories/ | ||
|
|
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.
I don't think this will this work for custom kits that may not include an advisories directory. Probably safer to mark as not required in the mount args and check for existence of the advisories dir:
| RUN --mount=source=advisories,target=/home/builder/advisories \ | |
| --mount=target=/host \ | |
| /host/build/tools/advisory-checker --spec-file rpmbuild/SPECS/${PACKAGE}.spec --advisories-dir /home/builder/advisories/ | |
| RUN --mount=source=advisories,target=/home/builder/advisories,required=false \ | |
| --mount=target=/host \ | |
| if [ -d /home/builder/advisories ]; then \ | |
| /host/build/tools/advisory-checker --spec-file rpmbuild/SPECS/${PACKAGE}.spec --advisories-dir /home/builder/advisories/ \ | |
| fi |
Alternatively, could just set required=false in the mount args and in your advisory-checker binary, throw a warning if the dir doesn't exist and move on.
I'd also advocate for unit/integration testing for this case.
Description of changes:
Add
check-advisoriestaskHow it works?
We implement a
advisory-checkerrust crate that takes 2 arguments - The rpmspec file and advisories directory. The binary is called during build by the upper level build.Dockerfile. Since, its already in the sdk context and the rpm macros are loaded, we can userpmspecandrpm --evalmacros to extract package name and versions. We deserialize the advisory files to extract the expected version and then compare using rpm.vercmp to evaluate if we are in a newer version.Testing done:
Cropping output for brevity.
Testing it on
bottlerocket-core-kit. I introduced 2 errors to test different cases. I created a sub-package BRSA with wrong epoch which got flagged. A different package with wrong version also got flagged.Testing it on
bottlerocket-kernel-kit.Terms of contribution:
By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.