Open ylecuyer opened 2 years ago
@ylecuyer maybe a better fix would be to print the gem's platform (if set) along with the gem name and version in the report? I think it would be bad if bundler-audit
ignored an insecure gem in the Gemfile.lock
because it's platform differs from the user's current ruby platform. This means bundle-audit
would ensure the gems were secure for the user running it, but maybe not their coworker who's on a different ruby platform. By including the platform of the gem in the final report, we're not losing any information.
Also, under normal circumstances, you shouldn't have gems from multiple platforms in the Gemfile.lock
.
source 'https://rubygems.org/'
gem 'nokogiri-ext'
gem 'nokogiri'
group :development do
gem 'rake'
end
GEM
remote: https://rubygems.org/
specs:
nokogiri (1.13.9-x86_64-linux)
racc (~> 1.4)
nokogiri-ext (0.1.0)
nokogiri (~> 1.0)
racc (1.6.0)
rake (13.0.6)
PLATFORMS
x86_64-linux
DEPENDENCIES
nokogiri
nokogiri-ext
rake
BUNDLED WITH
2.3.17
I suspect the multiple platforms are due to gems having explicit platform:
/platforms:
set in the Gemfile
or multiple developers running bundle install
/bundle update
on different platforms then committing the Gemfile.lock
?
Hello, lately we noticed some gems having duplicates in the report because of the various platform.
Here is an example with nokogiri:
And this is causing the duplicates.
As a fix, I suggest to filter and keep only the ruby platform for the check.