APK re-inserts basic auth info across domains when following redirects
The code related to this bug: https://github.com/alpinelinux/apk-tools/blob/master/libfetch/http.c\#L1081
Summary:
- add basic auth info to a repository in /etc/apk/repositories
- request an apk update
- server handling request returns a 302 redirect to provide the APKINDEX.tar.gz file
- apk follows redirect, re-injects basic auth, and makes request
This is done regardless of domain boundaries. In our case, this is
non-standard behavior that is causing issues. This ticket is not meant
as a judgement call that the current behavior is wrong, but that it
would, at the very least, be nice to be able to disable this behavior.
Furthermore, DNF, YUM, and APT do not have this behavior, so APK is
special in this case. This may be a feature request, if not considered a
bug.
Here’s a cleaned up excerpt of a conversation from the irc channel that
explains this bug in more detail:
my issue is this: I have a private repo stored on S3, which
is served behind a gateway with basic auth. The gateway creates signed
S3 urls, and redirects them to apk. apk handles the redirection just
fine, but the issue is it ‘re-issues’ or re-injects the original basic
auth info into the redirect, which causes s3 to break.
[to further] let me explain. So we have an s3 bucket that
we don’t want direct access to (the logging on s3 natively is not
granular enough to give us the information we need)
so, instead we have a mildly altered http gateway, that
restricts access via basic auth
which, when a file is requested, creates a signed url to
the s3 bucket, and returns a redirect to that file
actually, if gateway and s3 url are on different domain, and
the auth data is passed, its an bug in apk
it is a different domain
the redirect is a 302
johnnyfive:
https://github.com/alpinelinux/apk-tools/blob/master/libfetch/http.c\#L1081
apk is passing the auth data when following redirects, so the
question is, if thats valid or not
yep, no idea what the ‘correct’ behavior is, but I will
mention that yum+dnf+apt do not have this behavior
(from redmine: issue id 9490, created on 2018-09-28)