Bump Ruby patch versions to address CVE

[seanich]

Bumping to Ruby versions which address these CVEs: https://www.ruby-lang.org/en/news/2023/03/30/redos-in-time-cve-2023-28756/

[juliusrickert]

@seanich Why did you close this PR?

[seanich]

@juliusrickert I saw that there was a separate PR for 3.2 already so I decided to open a separate PR for 2.7 and close this one. Happy to re-open if it's preferred to upgrade all the minor versions in one shot.

[tianon]

For PRs like this, one PR updating all relevant versions is definitely preferred (but we do have automation via @docker-library-bot too).

[juliusrickert]

For PRs like this, one PR updating all relevant versions is definitely preferred

Thanks for clarifying. :)

(but we do have automation via @docker-library-bot too)

How is the automation triggered? Decided to create PRs since, two hours after the patched versions had been released, the container images hadn't been updated yet.

The patched versions have been released (the posts on ruby-security-ann have been published) at 13:30 UTC and the container images have been published around 21:00 UTC (afaict).

I am asking since this has been a problem with (coordinated) security releases in the past. For severe vulnerabilities, I think that's too long of a delay.

I don't want this to sound offensive or accusing in any way! But do I think that timely, maybe even coordinated, (security) releases would greatly benefit these images. Right now, it's hard to advocate the use of these images in production and I feel like this may be hurting the recognition and acceptance of containers for production use cases in small companies in general. It may convey a sense of inferiority and the impression that container images are an afterthought.

[tianon]

We are very open to coordinating security releases with the larger Ruby project if they'd like to include us (or collaborating in any other way on the maintenance of this repository). For context, that security release happened several hours before anyone maintaining this repository was even awake, let alone coherent enough to think about it and get something moving. If we'd had some advance timing notice, we could've planned for that (https://github.com/docker-library/official-images#security-releases). As is, we didn't even know there was going to be a security release until seeing the release announcements after the timeframe you suggest we should've updated the images.

[samuelkarp]

I am asking since this has been a problem with (coordinated) security releases in the past. [...] But do I think that timely, maybe even coordinated, (security) releases would greatly benefit these images.

I'm an outsider here, but it sounds like the Ruby project didn't coordinate with the Official Images project. I think that would be step 1, so @juliusrickert if you're involved with the Ruby community and can help them get in touch with Official Images maintainers prior to a security release that could help improve the situation.

[juliusrickert]

I'm an outsider here (…)

Me too, I'm not involved with the Ruby project or community in any way. Not sure whether it would be appropriate to reach out to the Ruby security team to propose a collaboration…

(…) it sounds like the Ruby project didn't coordinate with the Official Images project.

As a user, is there any way for me to tell whether an image on Docker Hub is subject to coordinated releases?

[hsbt]

@tianon 👋 I can invite you or docker image maintainer team to our security mailing-list. Ruby security team did post pre-release announcement and receive security reports on this mailing-list.

Please notify me if you interest it.

[tianon]

That would be fantastic, thank you! If you can add doi-security@infosiftr.com to the pre-announce mailing list, that would be really useful (if you can't add that group address for some reason, please feel free to email it and I can reply with some individual addresses to add instead).

[hsbt]

I send an invitation to doi-security@infosiftr.com 🚀