A nil slice of headers will use the previous set of default response
headers to maintain existing behavior. The same list of headers is
repeated as the default flag value in `cmd/imageproxy` as documentation
for users to know what values they are overriding (and might want to
still include).
Fixes#387
to address the segfault we're seeing in production. The necessary
conditions for the issue are:
1. The 303 must return a location URI that changes every time, so that
the real location of the image is never cached. As an example, if the
remove service redirects to S3, the presence of the
`X-Amz-Security-Token` accomplishes this.
2. The image responses must match by Etag, so that
imageProxy.should304() returns true causing
TranformingTransport.RoundTrip() to return a bare 304 response.
If those conditions are met, then the bare 304 Response returned will
be used and read by one of the callers. Specifically, the lack of a
Body causes a segfault.
So let's make it more like a real Response and use http.NoBody so when
it's used it doesn't cause things to explode.
The httpcache package is intended only to be used in private caches, so
it will cache responses marked `private` like normal. However,
imageproxy is a shared cache, so these response should not be cached
under normal circumstances. This change introduces a potentially
breaking change to start respecting the `private` cache directive in
responses.
This also adds a new `-forceCache` flag to ignore the `private` and
`no-store` directives, and cache all responses regardless.
- bump docker/login-action from 3.1.0 to 3.4.0
- bump docker/metadata-action from 5.5.1 to 5.7.0
- bump docker/setup-buildx-action from 3.3.0 to 3.10.0
- bump docker/build-push-action from 5.3.0 to 6.16.0
- bump sigstore/cosign-installer from 3.5.0 to 3.8.2
I believe chainguard no longer supports arm/v7. This was added at a
user's request I think that was running imageproxy on a raspberry pi or
something. I might switch to a different base image that does have
support, though it's annoying to have to do so. In the meantime, users
can always built the image themselves for other platforms.
This requires updating to a more recent version of golangci-lint, which
has some new failures. This removes those failing linters, and I'll
need to come back and look at those problems in a followup change.
I'm not entirely sure why I had this in the first place... probably just
a misunderstanding at the time of what a mux did and when it is helpful.
In this case, it serves no purpose.
I'm honestly not sure which formatter this is using. Probably something
from the markdown LSP server I'm using. Maybe something built in to
neovim or that ships with LazyVim?
When following redirects, ensure that the final URL is not in the
configured DenyHosts list, but do not further enforce presence in the
AllowHosts list.
This was initially added in #237, and the original use case was about
protecting against redirects being used to bypass denied hosts. They
were using URL signatures and deny lists (for localhost, etc), but not
allow lists. So really, checking against the deny list is all that was
needed in that case.
This came up recently for me as I was trying to proxy images on a remote
host that redirects to Amazon S3. Even though the original URL was
signed, the redirect was being denied because s3-us-west-2.amazonaws.com
isn't on of my allowed host. But I don't want to allow all of S3, just
the signed URLs.
