[RFC]: Support EOL

[fatkodima]

#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]

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]

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 https://github.com/rubysec/ruby-advisory-db/blob/75e23aea6e5adf46d91fdb230810b0fcc2d47cf7/spec/advisories_spec.rb#L6-L21 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]

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]

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

[reedloden]

Personally, I consider the use of EOL software to be a security issue, whether it has an actual security vulnerability or not. It means nobody is actively maintaining the code, so if an issue is found, it may not ever be fixed. Much easier to plan a migration away while there isn’t currently a vulnerability than trying to rush something in the heat of the moment. In fact, I’ve seen such a requirement to not use EOL software come up in corporate legal agreements more than a few times.

On Thu, Oct 24, 2019 at 5:35 PM Postmodern [email protected] wrote:

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

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rubysec/ruby-advisory-db/pull/419?email_source=notifications&email_token=AACV767PBFFOLM2EATWAZVTQQI5MDA5CNFSM4JDQTCP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECG2JIY#issuecomment-546153635, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACV7645LE2KL22DNQQEUPLQQI5MDANCNFSM4JDQTCPQ .

[postmodern]

@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]

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]

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?