pull down to refresh

  1. found the public key from https://github.com/spesmilo/electrum/blob/master/pubkeys/ThomasV.asc
Imported the key, also there are other devs are listed on the site.
Good, I think using Github as the source of trust is okay. But remember: the more sources that say that this is indeed the correct key, the better!
one thing really strange is that when I tried this again, it says
gpg: can't open 'electrum-4.5.3.dmg.asc': No such file or directory gpg: verify signatures failed: No such file or directory
Mhh, and you are sure you didn't (remove) the file? Did you run gpg --verify in the correct folder?
  1. I can't find the SHA256 to continue šŸ˜³
If the software you downloaded was signed, then you don't need separate hashes. The signature contains the hash to verify integrity. I can tell from your comment that this is the case for Electrum since the signature is named electrum-4.5.3.dmg.asc and the software is in electrum-4.5.3.dmg.
Sparrow Wallet was just a special case where not the software was signed but the hashes. Then you need to run another command (sha256sum --check <hashfile> --ignore-missing) to verify the software.
I mentioned that I don't know why Craig did it like this, I only had an educated guess:
Conclusion
So what we just did was to basically verify the authenticity and integrity of the file that contained the hashes for all binaries with gpg --verify. When the hashes could be trusted, we could use them to make sure that the software was not tampered with. But why not simply provide a digital signature for the binary itself?
I actually don't know. But my educated guess is that it's related to convenience. Instead of providing a signature for every binary, the hashes are signed. Using sha256sum --check with --ignore-missing then simply ignores all files that don't exist. So I am basically guessing that there is no way to do something similar with digital signatures. Maybe someone knows more?
wait, so when the software was signed all you need to do is finding the correct public key ( the more sources suggesting the same key the better ), and then verify the asc? that's all?
reply
Yes. The "asc" is the (detached) signature.
The hardest part is verifying the public key but most people just skip that lol
reply
how hard can it be, all you need to do is to search. šŸ˜‚
reply
To be fair, I think if the instructions mention to import the key from a site like Keybase like Sparrow does, I think it's fine. Most important thing is to not import the public key from the same site you received everything else and I think if people just follow instructions, they automatically do that.
It just makes me feel uneasy if people are not aware that this is important. The why's and so on.
reply
It just makes me feel uneasy if people are not aware that this is important.
like @DarthCoin say - education is key šŸ”‘
reply
Haha yes. Like a secret key hidden in plain sight.
reply
is my understanding correct?
the logic behind this is the dev uses his private key to sign the signature ( asc ) which then hash the software.
reply
359 sats \ 24 replies \ @ek OP 24 Feb
Yes
You just summarized my post with a few words haha
Wait, no. The dev signs the software (or whatever). The signature IS the hash "encrypted" with the private key.
now I finally understand what you mean here, why not just put each dev's key in GitHub šŸ˜Ø
reply
Best way is to spread your key fingerprint around imo.
If you only use one site as the source of trust, it's a single point of failure. Even if it's Github.
I have to do that myself, still figuring things out around PGP keys
deleted by author
reply