Gemfury downloads still blocked after #288 (redirect goes to s3.amazonaws.com/gemfury) #308

Hi! We've been having trouble with Dependabot updates for a Python (uv) project that pulls a private package from Gemfury. Every update job has failed since egress enforcement was turned on, with private_source_authentication_failure.

We saw #288 and hoped it would fix things, but we're still getting blocked. It looks like Gemfury redirects our downloads to the path-style S3 URL rather than the accelerate host that #288 allows:

proxy | GET https://pypi.fury.io:443/***/<account>/-/ver_xxxxx/<pkg>-<ver>-py3-none-any.whl
proxy | 302 https://pypi.fury.io:443/***/<account>/-/ver_xxxxx/<pkg>-<ver>-py3-none-any.whl
proxy | GET https://s3.amazonaws.com:443/gemfury/gems/<id>/<file>?x-acct=<acct>&X-Amz-...
proxy | * egress not allowlisted s3.amazonaws.com
proxy | 403 https://s3.amazonaws.com:443/gemfury/gems/<id>/<file>?x-acct=<acct>&X-Amz-...

Registry auth itself seems fine: the index returns 200 and the file request returns the 302. It's just the redirected download that gets stopped. We get the same s3.amazonaws.com/gemfury/... redirect when we hit the URL directly with curl or pip, so it doesn't seem to be anything Dependabot-specific.

We thought about declaring s3.amazonaws.com as a registry in our dependabot.yml, but that would open up every bucket. So we're not sure what the right fix is on our end.

Since it's the same gemfury bucket #288 already allows, just addressed path-style, would it make sense to allow s3.amazonaws.com only for /gemfury/ paths on jobs that use a *.fury.io registry? We know the allowlist only matches hosts today, so that might not fit how you want to handle it. We're happy to help test, or to put together a PR if you have a preferred approach.

Thanks!

Related: #288, #284