[NO-TICKET] Add validation for gem file permissions #3531
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
**What does this PR do?** This PR adds validation so we catch the issue from #3529 before the incorrect packages are published on rubygems.org. Specifically, it checks that every file in packaged `.gem` file has the expected permissions. **Motivation:** Avoid #3529 happening again. **Additional Notes:** N/A **How to test the change?** You can run `bundle exec rake build` to trigger this validation. Try setting incorrect permissions on one of the files and running, and you should see the validation failing.
AlexJF
approved these changes
Mar 18, 2024
| require 'rubygems/package/tar_reader' | ||
|
|
||
| RSpec.describe 'gem release process (after packaging)' do | ||
| # TODO: This will need to be updated for the 2.0 branch |
There was a problem hiding this comment.
Given the release task copies all gems under /pkg maybe we could run this check against all *.gem files in pkg atm? May be slightly annoying in that it may match on things not produced by the build that just ran but any failing files would be invalid gems and should be deleted sooner rather than later anyway?
There was a problem hiding this comment.
Good point. I still kept a check that the file we expect is there (just in case we run the spec out-of-order or something like that), but I've expanded it to check every file: b059258
There was a problem hiding this comment.
Yeah keeping the file check is smart indeed!
p-datadog
approved these changes
Mar 18, 2024
AlexJF
approved these changes
Mar 18, 2024
| require 'rubygems/package/tar_reader' | ||
|
|
||
| RSpec.describe 'gem release process (after packaging)' do | ||
| # TODO: This will need to be updated for the 2.0 branch |
There was a problem hiding this comment.
Yeah keeping the file check is smart indeed!
This spec only makes sense to run **after** building a gem.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #3531 +/- ##
=======================================
Coverage 98.23% 98.24%
=======================================
Files 1275 1275
Lines 75303 75303
Branches 3558 3558
=======================================
+ Hits 73977 73978 +1
+ Misses 1326 1325 -1 ☔ View full report in Codecov by Sentry. |
marcotc
approved these changes
Mar 18, 2024
|
I'm going to go ahead and merge this, since the failing CI jobs are unrelated and we're looking into them separately :) |
ivoanjo
added a commit
to DataDog/libdatadog
that referenced
this pull request
Mar 18, 2024
**What does this PR do?** This PR adds an additional file permission validation step while building the libdatadog Ruby packages. This is effectively the same as DataDog/dd-trace-rb#3531 , and I'm adding it to avoid the same potential issue. **Motivation:** Avoid issue we ran into with `ddtrace` packaging. **Additional Notes:** N/A **How to test the change?** Running `bundle exec rake package` will trigger the packaging of the Ruby packages, and you'll see the test running. To see it failing, `chmod` the `.rb` files to something other than 644.
2 tasks
ivoanjo
added a commit
that referenced
this pull request
Mar 19, 2024
**What does this PR do?** This PR is a follow-up to #3531: In that PR we added validation for the permissions of the files in the packaged gem. After merging that PR, @AlexJF noticed that the GitLab CI `build-gem` job [was failing with](https://gitlab.ddbuild.io/DataDog/apm-reliability/dd-trace-rb/-/jobs/463401683): ``` Unexpected permissions for CHANGELOG.md inside pkg/ddtrace-1.21.0.dev.bfc613b.glci463401683.g20ea0f3a.gem (got 666, expected 644) ``` These permissions are indeed incorrect and don't match the ones we expect on actual gem releases. Thus, I've sprinkled a `chmod` call to fix the permissions before packaging the gem in gitlab. You can see in https://gitlab.ddbuild.io/DataDog/apm-reliability/dd-trace-rb/-/jobs/463581213 that it now works fine: ``` gem release process (after packaging) sets the right permissions on the gem files Finished in 0.07305 seconds (files took 1.2 seconds to load) ``` **Motivation:** Fix GitLab CI pipeline. **Additional Notes:** I guess this check is already flagging permission issues! Great success :) **How to test the change?** See above -- I manually triggered the CI pipeline with this change and confirmed it passes.
2 tasks
ivoanjo
added a commit
that referenced
this pull request
Mar 20, 2024
**What does this PR do?** This PR is a follow-up to #3531: In that PR we added validation for the permissions of the files in the packaged gem. After merging that PR, @AlexJF noticed that the GitLab CI `build-gem` job [was failing with](https://gitlab.ddbuild.io/DataDog/apm-reliability/dd-trace-rb/-/jobs/463401683): ``` Unexpected permissions for CHANGELOG.md inside pkg/ddtrace-1.21.0.dev.bfc613b.glci463401683.g20ea0f3a.gem (got 666, expected 644) ``` These permissions are indeed incorrect and don't match the ones we expect on actual gem releases. Thus, I've sprinkled a `chmod` call to fix the permissions before packaging the gem in gitlab. You can see in https://gitlab.ddbuild.io/DataDog/apm-reliability/dd-trace-rb/-/jobs/463581213 that it now works fine: ``` gem release process (after packaging) sets the right permissions on the gem files Finished in 0.07305 seconds (files took 1.2 seconds to load) ``` **Motivation:** Fix GitLab CI pipeline. **Additional Notes:** I guess this check is already flagging permission issues! Great success :) **How to test the change?** See above -- I manually triggered the CI pipeline with this change and confirmed it passes.
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR do?
This PR adds validation so we catch the issue from #3529 before the incorrect packages are published on rubygems.org.
Specifically, it checks that every file in packaged
.gemfile has the expected permissions.Motivation:
Avoid #3529 happening again.
Additional Notes:
N/A
How to test the change?
You can run
bundle exec rake buildto trigger this validation. Try setting incorrect permissions on one of the files and running, and you should see the validation failing.For Datadog employees:
credentials of any kind, I've requested a review from
@DataDog/security-design-and-guidance.