Default to & as separator instead of either & or ;

[jeremyevans]

Allowing ; as separator by default can lead to web cache poisoning.

Fixes #1732

[rafaelfranca]

Should we rename qs and d to something more descriptive? I would never think that d would mean separator.

[jeremyevans]

I like the idea, but as a separate commit.

[ioquatix]

The next release should be a 3.0 release, so this is fine to merge.

[jeremyevans]

Ubuntu CI is failing due to the inability to install packages, before it runs tests. All tests pass on Mac, and this change is probably platform independent, so I'll merge it.

[hctan]

Hi, any chances this fix can be rolled out for 2.x? I'm currently using 2.2.3. When is 3.0 expected to be released?

[ioquatix]

Probably by the end of the year.

[blakegearin]

Any updates?

[jeremyevans]

There is no estimated release date yet. We are nearing the end of making major feature changes, I think, but there are few more pull requests and issues we need to work through. Due to many changes in 3.0, we'll probably need to start with a prerelease version and allow for a substantial period for people to test before the final release. So it don't think we can provide a good estimate yet for the final release of 3.0.

[blakegearin]

It appears a05f8d5 was cherry-picked out of the release of 2.2.3.1 and 2.2.4? Please correct me if I'm wrong.

Was wondering why it would be excluded since this commit patches the CWE-444 vulnerability (Snyk report). So applications wanting to avoid the vulnerability will have to depend on the main branch instead of a version which isn't ideal.

[jeremyevans]

It appears a05f8d5 was cherry-picked out of the release of 2.2.3.1 and 2.2.4? Please correct me if I'm wrong.

The commit was only made to the main branch, it was never applied to the 2-2-stable branch. So the phrase cherry-picked out certainly doesn't apply. The commit wasn't backported to 2.2. I think it is too backwards incompatible to be backported, and it looks like @ioquatix feels the same way. Maybe @tenderlove can give his opinion.

Was wondering why it would be excluded since this commit patches the CWE-444 vulnerability (Snyk report). So applications wanting to avoid the vulnerability will have to depend on the main branch instead of a version which isn't ideal.

Again, this wasn't excluded, it just wasn't backported due to backwards compatibility concerns.

[blakegearin]

Understood. The reason I said "cherry-picked" was because I'm used to versions being different slices of main instead of the multiple stable branches you all have going. So since it was merged to main I expected any new release to include it. My bad!

Again, this wasn't excluded, it just wasn't backported due to backwards compatibility concerns.

I guess I consider any version with a known vulnerability to be functionally dead in the water and backwards compatibility not particularly relevant. But that's just my opinion and we can disagree. Backporting is easier said than done.

At the places I've worked when a vulnerability was found in a dependency a new version with a patch was typically released within 24-48 hours or at most a week. If not, the dependency was removed altogether because it's not an acceptable risk and pointing at main is a hard sell due to lack of confidence in future vulnerability fixes. If Rack doesn't aim for/cater to a lot of commercial usage though, I understand. Just wanted to share my experiences for context.

[robopolomsky]

Hi, could somebody please cherry-pick this issue into 2.2? It's a vulnerability issue known for 2 years https://security.snyk.io/vuln/SNYK-RUBY-RACK-1061917 and unfortunately ruby-rails still didn't include rack 3 and I don't know when it will happen.

(Update): I read #2043 and it seems that's not possible unfortunately :(.