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

[RFC]: Support EOL #419

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

fatkodima
Copy link
Contributor

#416
I have included only 2 examples of how it can be implemented.
gems/eol.yml file format:

<gem name>:
  url:
  date:
  description:

I see title attribute here as always useless, because it will every time be the same, something like "<gem name> is deprecated".

rubies/eol.yml file format:

<engine>:
  url:
  date:
  version:

Here I see description field as useless, as it will always be the same, like "<engine> is deprecated, you should upgrade".

But for consistency, we can provide title and description in both variants.

I can think of an alternative implementation:

ruby-advisory-db/:
  eols/:
    gems/:
      ruby-sass.yml
      foo-bar.yml
      ...
   rubies/:
     ruby.yml
     jruby.yml
     ...

Where ruby-sass.yml has format:

url:
date:
description:

And ruby.yml has format:

url:
date:
version:

Will add missing tests after agreeing on implementation.

@reedloden
Copy link
Member

Have you considered ruby-advisory-db/gems/ruby-saas/eol.yml as a possible file location? That way, we keep all the old advisories in the same directory, but we also have a special eol.yml file in a gem directory that can describe that the gem is EOL.

@fatkodima
Copy link
Contributor Author

Sure, I have considered that option in the first place, but I'm a little worried about special case handling which will be introduced. At least in tests

describe "gems" do
Dir.glob(File.join(File.dirname(__FILE__), '../gems/*/*')) do |path|
include_examples 'Gem Advisory', path
end
end
describe "libraries" do
Dir.glob(File.join(File.dirname(__FILE__), '../libraries/*/*')) do |path|
include_examples 'Libraries Advisory', path
end
end
describe "rubies" do
Dir.glob(File.join(File.dirname(__FILE__), '../rubies/*/*')) do |path|
include_examples 'Rubies Advisory', path
end
and in bundler-audit in Database class in several places, like here https://github.com/rubysec/bundler-audit/blob/ad5afdadf6b792eca6e4ae872e1bb858fa9cdc2c/lib/bundler/audit/database.rb#L226-L228

And what do you think about .yml file structure?

@postmodern
Copy link
Member

If a gem/ruby is EOLed, but it does not have any security issues, why should you stop using it? I don't see why ruby-advisory-db should track EOLs. Seems a little out of scope.

@postmodern
Copy link
Member

Actually, would there be interest in creating a separate repo just for EOLs?

@reedloden
Copy link
Member

reedloden commented Oct 25, 2019 via email

@postmodern
Copy link
Member

@reedloden key word there is when a security advisory is published after the EOL. The time between EOL and first advisory is a grey area.

I am still in favor of creating another repo database dedicated to EOLs or orphaned gems.

@eoinkelly
Copy link
Contributor

Gems sometimes go out of and then back into maintenance. I think having one "EOL date" might not capture that easily. Would adding something like maintained: true|false to the schema be useful here?

@postmodern
Copy link
Member

I noticed this PR was approved, but still think it's out of scope of tracking security advisories. The amount of data to track whether a gem is currently maintained is much less than what is necessary to represent an advisory. Additionally, maybe this could be an attribute which could be added to rubygems.org's database scheme?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants