you are viewing a single comment's thread
view the rest of the comments
[–] 20 points 1 year ago (3 children)

Different distirbutrions subscribe to different "key servers" (is that the right term?) to validate that the packages they're getting have been signed by the right people, and not by Dick Dastardly and his crew. LibreWolf isn't your typical Linux package, but probably on the same trustworthy level as some of "extra" packages found in other repos. My guess would be Mint subscribes to the key server where the LibreWolf dev's key exists, and Ubuntu doesn't because Ubuntu has a very Ubuntu™ way of doing things (I'm being a snob here).

So I think if you really want to use LibreWolf, you will have to manually subscribe to the keyserver where the LibreWolf's dev key is, or manually import the key yourself to validate the package.

Anyway, welcome to the wacky races

  • source
  • hideshow 3 child comments
  • [–] 10 points 1 year ago* (last edited 1 year ago) (2 children)

    You understand what is happening conceptually but some of the details are not exactly correct.

    The package manager verifies every package's cryptographic signature, which is usually a hash of the file contents which is then signed with the developer's private key, so that anyone with the developer's public key can decrypt the hash (which verifies that it comes from a source which controls the private key of the keypair) and check it against the hash of the files they downloaded to ensure they haven't been altered between the project and your PC.

    What's happening is that OP is installing a package which is signed with a key that is not added as a trusted key in their keyring. So when it tries to check the cryptographic signature against its local hash it finds that none of the keys in the trusted keyring will decrypt the hash and so it doesn't trust the file and kicks out the error in the OP.

    The command

    sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys <PUBKEY>
    

    Tells apt to grab the public key with the ID from the keyserver keyserver.ubuntu.com and add it as a trusted key on your keyring.

    The reason that you use a key ID is that the actual public key is very large (2048 bits, most likely) and so it's easier on the system administrator to see key IDs and then retrieve the full public key from a keyserver if they need it than have the error log/terminal spammed with multiple screens full of random characters.


    That being said, using apt-key to add trusted keys is deprecated due to a potential security issue. The key is trusted for code signed from any repo, so a compromised key could allow an attacker to replace Librewolf with a malicious package on another repo called Librewolf and, as long as the signatures match (because they somehow stole Librewolf's private key or tricked you install installing an incorrect id) the package manager will install it.

    The new way (which is largely manual now, but people have already made scripts to do it more easily) is to manually download the key, store it somewhere and then add it to the configuration in /etc/apt/sources.list.d/ so that the source list itself defines which keys are trusted for that source. This would limit the key to being trusted for that specific repo only and not for every repo (or every possible thing that uses public keys)

    This has a more complete explanation, instructions on doing it manually and some links to helper scripts people have made to make the process just as simple as using apt-key: https://askubuntu.com/questions/1286545/what-commands-exactly-should-replace-the-deprecated-apt-key#1307181

  • source
  • parent
  • hideshow 2 child comments
  • load more comments (1 reply)