APT repository: fix SSL certificate

[reklipz]

https://repository.spotify.com/ is served with an invalid SSL certificate, preventing its use with APT.  Serving APT repositories without TLS/SSL is a known security risk:

https://blog.packagecloud.io/eng/2018/02/21/attacks-against-secure-apt-repositories/

Thanks!

--

On an unrelated note: when will the Spotify client be built against a newer version of libssl?  Debian no longer ships with libssl1.0.0.

[jooon]

We are aware of the problems of only GPG signing the repository metadata over plain http. We haven't spent enough time on fixing the cert problem on our current APT CDN mirror. We did spend some time to try to fix it and setup a new one a while ago:

https://repository.scdn.co

Domains that end with scdn.co are Spotify domains on one of our cdns, but you have to take my word for it here in the forum.

We realized we had some cache issues with that that we haven't fixed yet, so we couldn't migrate away from our old CDN setup which doesn't handle https certs.

Both repository.spotify.com and repository.scdn.co CDN caches use our web server cluster:

https://repository-origin.spotify.com/

That one sits directly in one of our data centers (probably in London) and can handle pretty big load, but no way near what big CDN players can do.

Almost all of our new Linux users follow the download instructions on https://www.spotify.com/download/linux/ and install the snap package securily from Ubuntu Software. Most users who started using the Linux client before December 2017 however still use the debian package and since there is no obvious smooth migration plan, we will probably keep it around for a while.

Since version 1.0.69, which was released in December 2017, Spotify depends on either libssl1.1, libssl1.0.2, libssl1.0.1 or libssl1.0.0 since 1.0.69 and dynamically links to the highest version it finds.

Because of how snap bundles dependencies, Spotify snap users don't have the libssl dependency problems (or the upcoming libcurl problem: see https://community.spotify.com/t5/Desktop-Linux/libcurl4/td-p/4411011 ). The trade-off is of course that they will need to wait for Spotify to send out an updated snap bundle in case of a security issue.

[jooon]

Now that I read my own message, I wonder why we never just setup a temporary redirect from:

https://repository.spotify.com

to:

https://d2czmavkeme1ql.cloudfront.net/

I will investigate it again to see if we can fix it quickly before properly migrating to a better CDN setup.