Closed cyc115 closed 1 year ago
I like the idea. Thoughts on how we might show this to folks? Or the schema format?
I like the idea, though can I ask it be the default but disable-able behind a flag. Since this forms part of CI for a lot of places this could end up blocking a lot of builds. Thoughts go out to a team I know contractually obligated to stay on ruby 1.8.x.
I like the idea, though can I ask it be the default but disable-able behind a flag. Since this forms part of CI for a lot of places this could end up blocking a lot of builds. Thoughts go out to a team I know contractually obligated to stay on ruby 1.8.x.
Good idea, I like the idea of switching on with a flag (vs. on by default and switch off with flag). I think opting in to EoL check is better than opting out because this could unnecessarily block builds.
Thoughts on how we might show this to folks? Or the schema format?
😄 Haven't had much thought on this yet. But will do this weekend.
UPDATE: I've opened https://github.com/rubysec/bundler-audit/issues/227 for discussion.
End-of-Lifed rubies could be stored in ruby-versions. End-of-Lifing isn't really a Security Advisory, so I don't think it really fits here. Although, Advisories for vulnerabilities in EOLed Rubies definitely can be added to ruby-advisory-db.
Closing this as the scope of ruby-advisory-db is security advisories for vulnerabilities.
Might be of interest: https://github.com/marketplace/actions/xeol-end-of-life-eol-scan
End of life Ruby and Gems could be something
ruby-advisory-db
tracks. Tools likebundler-audit
could then use this information to alert users fail builds. Any thoughts?