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 :)

@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
}

@kminardo Not really unfortunately... As said in the pinned comment, spotify continuously changes download binaries, GPG keys, etc... which is not appropriate, but we cannot do anything about it at our level.

The correct GPG key to import is noted/updated in the "Debian / Ubuntu" install instructions of this link. So if you get an error related to GPG key, you can check this link to see if it changed and adapt the command in the pinned comment with the new key (and also notify us so we can adapt the instructions in the pinned comment and in the PKGBUILD).

I guess one could set urlwatch (or something) to monitor this webpage to get notified of changes, but all can we do at our level on that matter is to relay Spotify's instructions. So I guess your best chance to keep up with the GPG key changes is to regularly check the "Debian / Ubuntu" install instructions of this link to see if the key has been replaced by a new one (and to notify us if it's the case so we can adapt the instructions there)! :D

Is there any recommended approach to keep up with the GPG key changes? Right now, I only know to check these comments to see if anyone reported a build failure, and hope gromit replied with a url

@gromit must be a slow brain day as I should have run paru -Scc instead. I also didn't realise AUR helpers were unsupported! How on earth do you manage tracking and building updates manually? nvchecker + scripts?

I appreciate the help regardless, clean cache & a chroot build seems to have done the job.

so I cleared all caches with pacman -Scc - same result.

This is only clearing pacman related caches and not whatever your AUR helper does (refer to its documentation on how to clear caches.

AUR Helpers are not supported anyways, please build and install with the methods described in the Wiki or in the pinned comment.

If this impacts others I'll post whatever fix I find

I like your spirit, but this is a problem very much specific to your setup!

@VetheonGames' paste no longer exists so I'm unsure if related.

They had some (network related) download issues if I remember correctly.

@gromit thanks for the reply. Installing via paru -Syu spotify. I thought the same thing, so I cleared all caches with pacman -Scc - same result.

Can confirm this error is confined to my machine (8th gen i5 laptop), as I've just successfully installed on another (Ryzen 3600X desktop). Removing the package also works totally fine, so no out-of-transaction file changes. Same install process on two machines running the same arch with a near identical setup. ¯\_(ツ)_/¯ If this impacts others I'll post whatever fix I find. @VetheonGames' paste no longer exists so I'm unsure if related.

Sorry for the noise.