Arch Linux User Repository

Please make sure to import the correct GPG key first:

$ curl -sS https://download.spotify.com/debian/pubkey_6224F9941A8AA6D1.gpg  | gpg --import -

And always build in a clean chroot. It is as easy as:

pacman -S devtools
git clone https://aur.archlinux.org/spotify.git
cd spotify
pkgctl build
pacman -U <path-to-spotify-package>

It is expected that the package will break now and then, as spotify continuously changes download binaries, gpg keys etc (which is not appropriate, but we cannot change this). Please be patient if an update does not occur the next day, you can still use an existing spotify install or update the version yourself.

@lightofpast Just pushed v1:1.2.20.1210-2 that now allows you to set custom launch flags in a spotify-flags.conf file under $XDG_CONFIG_HOME or ~/.config :)

Got same issues as @crispy-caesus (spotify window opens but it's blank gray) for several months now :(. Arch wiki suggestion to delete ~/.cache/spotify did nothing. I'm on hyprland wayland, haven't tested on xorg.

I had issues when authenticating and almost ran out of ideas. One of my last attempts was using another browser. I set the default browser app back to Firefox, instead of Brave, and it worked! In case anyone else has problems authenticating, this might be a solution.

Getting the same error as @rearwindowtaxidr. Restarting and cleaning files won't fix it.

@rearwindowtaxidr yeah, maybe just try again, that's not a problem with the package atleast.

Depending on your setup you might need to clean up the (partially) downloaded files, idk if the server supports byte ranges.

When downloading deb from repository.spotify.com, cURL outputs an error and stops. curl: (18) transfer closed with 71965275 bytes remaining to read Is this because Spotify's servers are poor?

@gromit, I've restarted yes, I've had this problem for 2 days now (I've installed it from flatpak but I'd prefer AUR if possible)

I tried deleting the cache now, though nothing changed.

I run Wayland usually, though it doesn't work either when I try it on Xorg

Where would I ask in the forums exactly, sorry I'm new to this

@crispy-caesus, did you restart in the meantime?

Also the output you mentioned is talked about here: https://wiki.archlinux.org/title/Spotify#/usr/lib/libcurl-gnutls.so.4_error

Although in my experience this should not be a hard error 🤔

Do you run under X or Wayland? Maybe others can help you in the forums or on IRC :)

On spotify 1:1.2.31.1205-2 I can't seem to start the app, this also applies to the spotify-launcher

[crispy@bob ~]$ spotify /opt/spotify/spotify: /usr/lib/libcurl-gnutls.so.4: no version information available (required by /opt/spotify/spotify) /opt/spotify/spotify: /usr/lib/libcurl-gnutls.so.4: no version information available (required by /opt/spotify/spotify) /opt/spotify/spotify: /usr/lib/libcurl-gnutls.so.4: no version information available (required by /opt/spotify/spotify) [crispy@bob ~]$

is what I keep getting, also upon reinstalling and a few other things like emptying my config

@agowa Thanks for your detailed input on the matter.
Your proposal is interesting but I'm not convinced it's the way to go though (as you kinda said yourself).

While the information you gave may be valuable security wise I don't think such workflow would be expected:

First of all, while it may not be convenient in Spotify's specific case (since they tend to change the signing GPG key often, even between two releases), I don't think having a "self-updating" PKGBUILD on that front would be expected. I assume such a change should be acknowledged, verified and edited properly by the package maintainers themself, as it's supposed to be for pkgver or checksums changes for instance (with the exception of -git packages by their nature, obviously). Additionally, having it automatically importing the key in user's local keyring would be even less expected ('# Maybe even:' part in your proposal). For what it's worth, such mechanism has been implemented in this package once but was quickly reverted due to it being objectively wrong.

Moreover, I think it's important to keep the PKGBUILD as clear and as intelligible as possible, not only for its maintenance but also for trust reasons. In my opinion, it is more trustworthy to have the PKGBUILD clearly stating what key it is expecting (whether it is correct/up-to-date or not) than having to actually launch a build against the said PKGBUILD to get the information (since with such an auto-updating mechanism, you cannot guarantee that the key noted in the validpgpkeys array is indeed the one returned by the validpgpkeys=() function, until you actually run it yourself). It may be convenient but it just makes getting the actual information harder in my opinion.

Lastly, I think it is to important to remind that AUR packages are not officially supported (as community maintained packages). This is to say that implementing such mechanism that "we'd never do under normal circumstances" is probably not expected at the package level for the above reasons; but such useful information as the ones you provided should, in my opinion, be directed to users instead so they get more input to verify the trustworthiness of the package before building/installing it on their system (as everyone is expected to do when it comes to the AUR).

Once again, this is just my opinion. Don't hesitate to challenge me :)

@Antiz What I'll be suggesting below isn't the usual AUR-thing to do, but considering the situation here as well as their implications it at lest in this case ultimately would not be worse than the current workaround (arguably even very slightly more secure)

Considering:

(1): The current practice of spotify of already constantly changing their keys,

(2): The fact that makepkg doesn't use the gpg trust level setting at all (makepkg uses pinned keys via validpgpkeys instead).

(3): The spotify key is neither signed nor validated against anything right now. Except implicitly through the TLS certificate of the source the user is told to download it from.

(4): All keys imported (or not) are still UNtrusted to gpg anyway. And even if (2) wasn't the case then the combination of (1) and (3) would still be an issue (we'd still have to tell users to blindly trust some key downloaded from the spotify server)...

(5): The sig and binary are both download unencrypted (I.E. could be tampered or spoofed in transit) are over http from repository . spotify . com

(6): The URL for downloading the correct key is over an TLS authenticated channel from A DIFFERENT DOMAIN "download . spotify . com"

(7): The URL to download the correct gpg public key contains the keyID.

(8): The .sig file contains the signers keyID.

This means for us:

Because of the combination of (5), (2), and (4) we CANNOT gpg auto-key-retrieve the signers key through the sig file, as the sig file may be signed by a potential attacker themselves and we'd then just download their key instead.

BUT what we can do is extract the keyID of the signer and piggyback on the TLS validation (6) + (7) of the server to automatically try downloading the key. This would either result in a server error (when the key is NOT from spotify) or succeed and hand us the needed key to validate the signature.

Thereby we'd also improve security as we would validate the accuracy of the key and not just "advice" to blindly import any random signing key to get this package to build regardless of (1)+(3)...

Therefore:

Why not do within the PKGBIULD file something similar to this (that as I already said at the beginning, we'd never do under normal circumstances):

validpgpkeys=() {
  # Note: Make sure to only once invoke gpg for both the KeyID and key itself to prevent time-of-check-time-of-use style attacks (even though that's mostly theoretical anyway)
  $gpgOutput = gpg -vv --verify Release.sig 2>&1
  signersKey = $gpgOutput | grep "using RSA key" | sed "s/^.* //"
  signersKeyID = $gpgOutput | grep ", keyid " | sed "s/^.* //"

  # Maybe even:
  (curl -sS https://download.spotify.com/debian/pubkey_$signersKeyID.gpg || throw KEY_NOT_FOUND) | gpg --import - >/dev/null 2>&1
  # BUT AT LEAST to validate:
  (curl -sS https://download.spotify.com/debian/pubkey_$signersKeyID.gpg || throw KEY_NOT_FOUND) >/dev/null 2>&1

  return signersKey
}