I just downloaded 1.9.9 and I did not have a key to verify the signature. Did I lose the key or the key change, with no announcement? If the key changed without signing it with the old key, that’s a serious security error. But maybe I just screwed something up on my end?
Seems to me the releaser has changed, I think you can find the gpg public key on bisq.wiki
1 Like
It changed. Downloading and installing - Bisq Wiki
Twitter and release notes announce that change, but no, old key has not signed the new one, they’re different owners.
Looks like the wiki is missing some info, quote:
" which you can verify through commits on GitHub and []."
What’s in the box?!?!
Thanks, I’ve just fixed it. You could see ripcurlx key on keybase, but Bisq does not use Keybase anymore.
Yes, and different owners can sign each others’ keys. That is the proper procedure when changing a signing key. The former maintainer signs the new maintainer’s key.
It really does not help that it is in the release notes obviously, because anyone who could compromise the binary could compromise the release notes (they are in the same infrastructure).
This is really a basic verification process error here. Of course it does not mean there is a problem, but the point of using GPG is to ensure there is not one, and Bisq is not following the procedures that allow to verify this.
2 Likes
I just signed and published both new signer keys.
1 Like
is the new pgp signing key and public key up in the download section? because i tried uploading the public key yesterday and it was the same one that i’ve had for years
Hey there!
Following your (updated?) link to verify the installer, the wiki states:
Bisq installer files are currently built and signed by Alejandro Garcia (alejandrogarcia83). His public key ID is E222AA02 and fingerprint is B493 3191 06CC 3D1F 252E 19CB F806 F422 E222 AA02, which you can verify through commits on GitHub.
However, the latest commits by user “alejandrogarcia83” on GitHub were signed with GPG key ID: 4AEE18F83AFDEB23; not »E222AA02«.
What am I missing?
2 Likes
bisq.network key has not been uploaded yet.
@till I’m asking why last commit’s key is different.
1 Like
Copying the reply I got from Bisq 2 repo maintainer:
That’s normal. It’s GitHub’s PGP key. Look at the Bisq 2 repo commits (Commits · bisq-network/bisq2 · GitHub). When I merge PRs using the “GitHub UI” GitHub will sign the “merge commit”.
Thanks for taking care of it, @MnM !
Let me get this straight:
In the Bisq repository, I find commits from user “alejandrogarcia83” with two different signatures:
- his personal GPG signature: used when he does “classic” work (e.g. remote work using
git push) - any GitHub GPG signature: used when he works via the GitHub WebGUI.
This is not obvious to me as a user (and thus possibly to others) without explanation and leads to confusion in key verification. Is there a better way to do this?
1 Like
From the reply I got, it seems there is no better way to do it. If at least one of the keys signed commits, and the web gives you that key, seems enough.
But I understand it’s confusing. I’ll wait, though, to see if other people complains about this to see if something else is necessary.
1 Like
There is a long-established way of handling exactly this sort of thing, and Bisq isn’t doing it. Why even use signing keys if you’re not going to use them in the proper way?
I actually forget the original situation here, but if there are two keys then each of those keys should have signed each other and uploaded the new keys to the keyserver so everyone can verify that each signer knows the other.
If there is a new key, all former signing keys need to sign the new key, and upload all to the keyservers.
Also, the website should expain this situation. It is not acceptable to have a website say one thing, but the actual keys say something different.
This is basic keysigning procedure. Like I said I don’t remember what this situation is but what I’ve just laid out is keysigning 101 and should cover most situations.
To skip this basic security function for a piece of software that uses Tor and handles private data should be a huge red flag for anyone considering using Bisq. We’re not talking about anything special here, just basic keysigning/validation rules.
2 Likes
Hopefully by now you’ve seen that this is a problem? There is a proper way to start using a new key. Among other things, you sign the new key with the old key. You also give a clear and good reason, and state it publicly. Otherwise you end up in a situation where there are always questions about the software from that point on.
It’s crazy that Bisq developers don’t understand this, it’s alongside the most basic of rules when using GPG/PGP, but at least the Whonix team does:
www whonix org/wiki/Bisq#cite_ref-6:
1 Like