Depending on your threat model, not very important. What are the chances that 1) someone will have hacked Mullvad’s server and installed a compromised version of the browser, and 2) you happen to download the compromised version before the hack is discovered and mitigated? Also, the signature and the package appear to be on the same server, so what’s necessarily going to stop the hacker from updating the signature to match their hacked package? [Edit: It’s a GPG signature, not a simple hash signature, so I guess that’s so not trivial after all.]
That’s kind of what I figured, although after following Mullvad Browser’s instructions for verification, I did get two different RSA keys, if that means anything . . .
You’ll want to make sure that the key you’re validating is provided through another trusted channel, so that an attacker can’t provide a bad download and have you check it against their bad key too.
Depending on your threat model, not very important. What are the chances that 1) someone will have hacked Mullvad’s server and installed a compromised version of the browser, and 2) you happen to download the compromised version before the hack is discovered and mitigated?
Also, the signature and the package appear to be on the same server, so what’s necessarily going to stop the hacker from updating the signature to match their hacked package?[Edit: It’s a GPG signature, not a simple hash signature, so I guess that’s so not trivial after all.]That’s kind of what I figured, although after following Mullvad Browser’s instructions for verification, I did get two different RSA keys, if that means anything . . .
Right. The risk is low, but nonzero.
You’ll want to make sure that the key you’re validating is provided through another trusted channel, so that an attacker can’t provide a bad download and have you check it against their bad key too.