Skip to content

GitLab

Closed
Opened by Morgan Hein@morganhein

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)