[bisq-network/bisq] Update netlayer references to bisq repos (#4694)

[cd2357]

> Do we have a way now to archive past sigs/hashes or even binaries for being able to verify historical releases?

Yes, the `tor-binary` project can keep previous hashes used for previous tor versions, like here for v10: https://github.com/bisq-network/tor-binary/tree/upgrade-tor-10.0/tor-binary-resources/checksums . When the binaries are built for the next version, new hash files are added named accordingly, while still preserving the previous hash files.

> Also: Can you figure out if its feasible to do tor binary verification in the build scripts?

I tried, but found no direct way to do that, because there are no published hashes for the tor binaries.

The current approach does that indirectly:
- Bisq uses a certain version of `netlayer`
- ... which uses a certain version of `tor-binary`
- ... which contains, in the path listed above, the expected hashes of the tor browser binaries

The `tor-binary` build process will fail if the checked-in hashes don't match the actual hashes of the downloaded tor browser binaries.

Still, once built, the resulting libraries are downloaded from jitpack, when building Bisq, so this involves some trust in them.

One idea to eliminate the need for that trust: when upgrading `tor-binary` and `netlayer` next, the one who does it should build them locally + hash the resulting maven artefacts. Then, when the `netlayer` version is bumped in the Bisq `build.gradle` and `./gradlew -q calculateChecksums` is run to update `gradle-witness.gradle`, he can check if those checksums (hashes of the jitpack tor libraries) are the same as the checksums he generated locally earlier (from his local maven repo, after locally building `netlayer` and the `tor-binary` dependency).

Its a manual step in the "upgrade tor version" process, but it has to be done only once. If all looks good, the "upgrade tor version" commit in Bisq will include a verified set of hashes in `gradle-witness.gradle`, so all subsequent builds from anyone else will automatically check and expect the jitpack binaries to have those checksums.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/bisq/pull/4694#issuecomment-716184251
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20201025/da040d8b/attachment.html>