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

Remove deprecated base64 in favour of pack/unpack (2-2-stable) #2174

Closed
wants to merge 2 commits into from

Conversation

adam12
Copy link
Contributor

@adam12 adam12 commented Apr 24, 2024

The base64 library is external as of Ruby 3.4 and is no longer available by default in Ruby. The pack/unpack methods support encoding as base64 and can be used in its place.

String#unpack.first was preferred here to support Ruby 2.3, which didn't yet have String#unpack1 introduced in Ruby 2.4.

The base64 library is external as of Ruby 3.4 and is no longer available
by default in Ruby. The pack/unpack methods support encoding as base64
and can be used in it's place.

String#unpack.first was preferred here to support Ruby 2.3, which didn't
yet have String#unpack1 introduced in Ruby 2.4.
@adam12 adam12 changed the title Remove deprecated base64 in favour of pack/unpack Remove deprecated base64 in favour of pack/unpack (2-2-stable) Apr 24, 2024
@jeremyevans
Copy link
Contributor

I don't think we should backport this to 2.2 before backporting it to 3.0. It's also not a security issue, so it shouldn't be considered for backport to 2.2, IMO.

CHANGELOG.md Outdated Show resolved Hide resolved
@adam12
Copy link
Contributor Author

adam12 commented Apr 24, 2024

To preface: I'm OK if this merges or if it doesn't.

I actually hesitated to submit a PR to an older release branch, but I looked for the official stance on backports and didn't see anything (maybe I missed it?). If it's not acceptable for backport, we can go ahead and close the PR.

I have 2 applications with a very sticky Rack 2 dependency that I am in the process of upgrading, but it's been a bit of a challenge and I still want to continue with Ruby upgrades. I'll end up maintaining my own fork of 2-2-stable if I have to.

@adam12
Copy link
Contributor Author

adam12 commented Apr 26, 2024

I just noticed that the base64 dependency was added to rack-session gemspec, which could be done in this case too (if we wanted parity).

@ioquatix
Copy link
Member

I suppose we either need to do one of those options, or this release will simply stop working with the next major release of Ruby, no?

@jeremyevans
Copy link
Contributor

It won't stop working, it will just require that users of Ruby 3.4+ and Rack 2.2 list base64 explicitly in their Gemfile.

@ioquatix
Copy link
Member

Right, so there is a workaround, which is users would need to explicitly add the missing gem to their application level gemfile. i.e. the Rack gem has an implicit dependency and the user can compensate for that.

@jeremyevans
Copy link
Contributor

I'm still against backporting this to 2.2, as it is not a security issue, and users can work around it by adding base64 to Gemfile.

@adam12
Copy link
Contributor Author

adam12 commented May 30, 2024

I was just thinking about this again yesterday. I'm assuming this isn't the first time that this will come up, so perhaps less intrusively we just update the README?

@jeremyevans
Copy link
Contributor

I not opposed to adding this to the README. The README could stand to be updated, as it still states "Rack v3.0.0 was recently released", and that was over 18 months ago.

@adam12
Copy link
Contributor Author

adam12 commented May 30, 2024

I'll submit a PR for README changes and then we can close this.

@tenderlove
Copy link
Member

I'll submit a PR for README changes and then we can close this.

+1

Thank you for your work!

@tenderlove tenderlove closed this May 30, 2024
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.

None yet

5 participants