Hi Alpine Team,
thanks for the great work you done for the Open Source Community!
I was just making an PR to the docker-bench-security project and saw this:
sed -i 's/http\:\/\/dl-cdn.alpinelinux.org/https\:\/\/alpine.global.ssl.fastly.net/g' /etc/apk/repositories
Also in the latest Alpine Version 3.7 /etc/apk/repositories is configured to query over unsecure http:
http://dl-cdn.alpinelinux.org/alpine/v3.7/main
http://dl-cdn.alpinelinux.org/alpine/v3.7/community
Trying to get it over https in the Browser even throws a certificate warning: https://dl-cdn.alpinelinux.org/alpine/v3.7/main.
To solve this problem i would recommend to redirect all http calls to https on the server side or even enforce HSTS and then update /etc/apk/repositories to use https with the next release.

Cheers Maik
The value of https is small for apk repositories and may give a false sense of security. We have a number of mirrors which are hosted by people we don't trust, nor have we any control over the fastly cache servers, so anyone with access to those servers could modify the apk files. https would not protect you against that.
apk will verify the package against a signature embedded in the apk file, so it does not really matter that it is transferred over http.
But I don't mind using https if fastly (or someone else) is willing to burn cpu cycles on it, even if it does not add any security of significance.
apk will verify the package against a signature embedded in the apk file, so it does not really matter that it is transferred over http.
@ncopa can you provide more details on the signing process? How is this signature generated?
Most helpful comment
The value of https is small for apk repositories and may give a false sense of security. We have a number of mirrors which are hosted by people we don't trust, nor have we any control over the fastly cache servers, so anyone with access to those servers could modify the apk files. https would not protect you against that.
apk will verify the package against a signature embedded in the apk file, so it does not really matter that it is transferred over http.
But I don't mind using https if fastly (or someone else) is willing to burn cpu cycles on it, even if it does not add any security of significance.