-
Notifications
You must be signed in to change notification settings - Fork 116
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
S3 URL generation for content artifacts is broken for apt clients when using Minio behind a load-balancer #2075
Comments
I confirm. Without the above mentioned patch, apt get the wrong link to Release file in s3. Сurl and browser themselves carry out autocorrect, but the apt don't |
Happy to see this being fixed. :) |
I am going to revert this change because it breaks other things #3124 |
Author: jlsm-se (jlsm-se)
Redmine Issue: 9669, https://pulp.plan.io/issues/9669
Here's the simplified setup I've used to reproduce this issue:
When I run
apt-get update
on a client configured to use the Pulp server, Pulp responds with the 302 redirect pointing to the HTTP load-balancer I've set up in front of Minio. So far so good.The problem is that the redirect URL contains a semicolon as a query separator, which none of the load-balancers I've tried seem to handle correctly (the
filename
parameter inresponse-content-disposition
seem to get discarded). The apt client always gets a 4XX error (e.g.401 unauthorized
).This seems to happen because content-proxies (that is, the load-balancers) will strip semicolons from query parameters, because that is what is recommended by the WHATWG since december 2017 and somewhat recently discovered cache poisoning attacks seems to have sped up efforts to follow this recommendation among languages and frameworks (see CVE-2021-23336).
These two comments in the golang issue tracker helped me come to this conclusion:
golang/go#25192 (comment)
golang/go#25192 (comment)
I've managed to hackishly solve the issue (apt clients can now use my repos!) with the below patch, but I'm not sure if it's actually the correct solution or even the safest since it still involves a semicolon as a query separator. The ideal would maybe be to avoid the semicolon entirely, but I'm not sure if the AWS S3 specs allow for that.
The text was updated successfully, but these errors were encountered: