I have verified the signature of Bisq-64bit-1.9.17.deb.asc as alejandro.garcia
After installing Bisq-64bit-1.9.17.deb on Ubuntu, I then got a hash by running:
shasum -a256 /opt/bisq/lib/app/desktop.jar
(I can not find a desktop-1.9.17-all.jar file as suggested on github.)
Last I remember, the jar verification was discontinued, as successfully verifying the installer itself makes redundant verifying the jar included in it
OK, this is going to show how little I know, but how do I verify the installer itself? From what I understand, verifying alejandro.garcia public key would only be useful if the key was then imported and used to verify the hashes.txt file - or something like that. I would then have a confirmed hash and could shasum -a256 on the installer (.deb) and then cross-check the hash. Anyway, I am sort of clueless and maybe there is a way to simply verify the installer itself. Thanks.
Where did you find this suggestion? Maybe itās outdated, or reffers to another use case.
I donāt verify any hashes.txt file, this is not even provided at Bisq. This is what I do, I think itās what you did and Iām pretty sure itās all that itās expected for any user to do:
Import alejandrogarcia public key was imported, which would be something like gpg --import alejandrogarciakey.asc.txt. That needs to be done only once, then that key will verify all future releases.
Then, go to where Bisq-64bit-1.9.17.deb.asc and Bisq-64bit-1.9.17.deb were downloaded, which is usually Downloads folder so cd Downloads and do gpg --verify Bisq-64bit-1.9.17.deb.asc. This message appears, meaning itās ok:
gpg: assuming signed data in āBisq-64bit-1.9.17.debā
gpg: Signature made Mon 24 Jun 2024 03:54:13 AM CEST
gpg: using RSA key B493319106CC3D1F252E19CBF806F422E222AA02
gpg: Good signature from āAlejandro GarcĆa alejandro.garcia@disroot.orgā [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: B493 3191 06CC 3D1F 252E 19CB F806 F422 E222 AA02
Verify jar file inside binary:
You can verify on OSX the jar file with:
shasum -a256 [PATH TO BISQ APP]/Bisq.app/Contents/app/desktop-1.9.16-all.jar
The output need to match the value from the Bisq-1.9.16.jar.txt file.
There are three hashes within the Bisq-1.9.16.jar.txt file (macOS, Windows, Linux).
If you want to reproduce and verify the hash of the jar file locally, you need to do so on Windows or Linux using Java 15.0.9 and the v1.9.16 release tag. Because of the signing and notarization process that requires the developer certificate used for the build on macOS it is not possible to create the same jar on macOS.
I have been trying to dig into this a bit. It seems that verifying the Bisqā¦deb.asc file using Alejandro GarcĆa public key simply means that the installation Bisqā¦deb file was signed by one of the creators, Alejandro. It does not preclude the possibility that Bisqā¦deb was later tampered with. That is what .jar.txt is suppose to do.
I have yet to find the elusive .jar.txt file and I am not sure the /opt/bisq/lib/app/desktop.jar file is the right one to be verify using .jar.txt.
As noted on Bisq, āAny software that manages funds, signs transactions, and deals with highly sensitive data is a prime target for malwareā so being able to verify the install seems very important.
Here are some instructions helped me better understand Bisqās verification directions but I still can not confirm the .deb installation file is legitimate. https://www.athena-alpha.com/install-bisq-on-ubuntu/
****** No Way To Verify Bisq *******
Apparently, there is no definitive understanding as to how to verify that the Bisq .deb (binary/package) installation file has not been tampered with per the discussion above. In contrast, the directions on verifying Moneroās wallet have a person first verify the pgp key, then the hashes, and then the install file and it all works as outlined. https://www.getmonero.org/resources/user-guides/verification-allos-advanced.html
Having done a bit of programming myself, I have a sense for how challenging it must be to create a platform like Bisq. Seriously, I am amazed. The ability to P2P transact in Bitcoin is huge and I so looked forward to using Bisq. However, the lack of a way to verify the .deb file as Bisq itself outlines suggests that the developers may not be as ābuttoned upā as one would like. Maybe there is some āmagicā being preformed wherein the software is verifying itself but this is not what is outlined on Bisqās verification page. As such, I can not see installing Bisq until I am convinced the files I am installing are legitimate.
I have a clear explanation about your question now.
jar file verification is only viable for deterministic builds, and that is not the case (anymore) because it requires additional steps to make sure anyone building the application will obtain the same exact binary, and that is not done when compiling.
The officially supported verification is that done on the install package itself, and that is the reason the wiki article detailing jar file verification has been redacted, to remove that part.
suddenshipvapor, thank you for looking into this! In general, do you happen to know how the verification is done? Does Bisq somehow verify itself after being installed?
Regardless, I feel confident in verifying and installing Bisq. Iāve started pursing the forums, and there is a lot to learn. Iām looking forward to my first transaction.
By the way, I did try building Bisq after installing āgitā and āopenjdk-11-jdkā using Synaptic Package Manager but it āfailedā with āError while evaluating property ārelativeClasspathā of task ā:apitest:startScriptsāā¦ā Anyway, thatās a topic for another day.
Bisq has no way to verify itself after install, and even if it did, once it was hypothetically tampered, it wouldnāt properly verify itself anymore would it
The very latest version was released in a hurry as bitcoinj bug was preventing any further trading, if you check that page that you linked it is still referring to 1.9.16. What I understand from my level is that having to fix to another bitcoinj distribution forced the distribution to be made in a way that prevents deterministic builds.
I am not able to help you with that error, I build it myself after installing java 11 with apt from commandline and it just works
