Orchid's current trust requirements are a non-starter for the conscientious

[softwarecreations]

Firstly, I want to say, I love what you're doing and love the concept.

As Orchid exists right now, there is a large barrier, or a lot of friction to entry that I need to personally overcome to consider trying it out. And if I feel that way, then guaranteed there are a lot more potential users who feel the same. I'm not exactly 007 but I do practice some basic digital hygiene, which is totally lacking here.

I understand that dev resources are constrained and whatever, but solving these problems is not hard and it's critical for Orchid to be taken seriously at all by many potential users.

--

The problems

Currently if a Linux user wants to try out Orchid, they have to go here and run some binary blobs from Microsoft with blind faith https://github.com/OrchidTechnologies/orchid/releases

If I had such blind faith in Microsoft, maybe I'd be using Windows.

If users want to build from source, the readme doesn't have any build instructions. The only alternative, is Docker, which as you recognize, is super cringey.

On Android, Orchid isn't on F-Droid. So it's a non-starter on Android as well. Especially since there's no way verifiable blob to sideload; as above.

--

Two easy solutions

Firstly build instructions won't be that hard to make. Perhaps I can contirbute?

Secondly your blobs SHA512 sums should be signed with your PGP key, which is hosted somewhere that inspires some level of trust or assurance of authenticity. Perhaps you could store your PGP in Ethereum, sign it with the same dev key that you publish the smart contract with.

--

Conclusion

Without either of these, the project is a complete non-starter for the conscientious at this time.

What is the point of a security product, that if used, weakens security? To become more secure, I must install blobs from Microsoft? Really?

--

No hard feelings

Peace, love, freedom, autonomy and all that good stuff.

[saurik]

If users want to build from source, the readme doesn't have any build instructions.

Go into the folder you want to compile and type "make".

[saurik]

(Oh: and as also noted in the readme, you need to have Rust, clang with lld, Python3, and meson installed. But this is all documented in the build instructions in the readme, and would also be obvious when the build prints something like "cargo: command not found". Honestly, if you haven't managed to compile Orchid, it is more likely because you didn't try, not because it is either difficult or undocumented. If you get some actual error that seems specific to your system, I will absolutely treat that as a bug and fix it ASAP.)

[saurik]

...sign it with the same dev key that you publish the smart contract with.

So, our project's smart contracts (not including the OXT token, which in some sense isn't actually related to this software...) are intended to be "singletons" (deployed either directly or indirectly using "Nick's method"), as the entire premise is that you should trust the code to be correct and not the person deploying the contract. (With a singleton, the address of the contract is fixed by a hash of its code, and can be deployed by anyone; this is extremely important for parts of our system that are designed to be run on multiple chains: you can trust the contract on any chain no matter which end user deployed it.) There thereby is no existing key which you can or should trust involved in our stack (and I'd frankly be somewhat loath to introduce one: I'd rather that you trust the pedigree of the code rather than a handful of humans, as if nothing else putting that trust in us puts us in physical danger from people who want to co-opt that trust).

The directory contract is sadly not a singleton (as I didn't understand this property of Ethereum at the time), but you would still decide to trust it by recompiling it yourself and verifying the codehash... I deployed it (and the OXT token, which I also deployed)--on purpose (effectively replicating all the same thought processes of a singleton, excepting the deterministic address)--using an extremely insecure software key "owned by" SaurikIT (one that would not at all be reasonable to sign anything secure with: I call it a "petty cash" key and have made numerous copies of it without any key wrap across multitudes of devices and services), as the security properties of the system are unrelated to who deployed it. Like, if I gave you the private key (and I have been considering just posting it somewhere)--or lost it, or it was stolen by Google (as I have a copy in Google Docs of all places ;P), or AT&T (I've texted it via insecure SMS...), etc.--it would not affect the security of the contracts or the system (as, unlike many projects--even high-profile ones--we have no backdoors or kill switches in our contracts).

(That said, though, if you do in fact trust keys and signatures that come from me--and I'm not saying you should ;P in fact, I want to say that I'm somewhat arguing against that entire model of trust here--then you actually should trust the Android build, and specifically not on F-Droid!!! The security model of F-Droid is not to avoid trusting Google as much as it is to avoid trusting me: they rebuild software they deploy, which means that you have to trust them instead of--though, frankly, in addition to--me... but Google doesn't have our private keys, and so can't modify or forge what you download through them! The binaries you can get from the Play Store are thereby end-to-end from us--and, right now, quite specifically, me--signed using a key that we have to be pretty careful with... SHA256 fingerprint 0D:08:BF:D3:5D:5F:C4:44:88:D8:44:F6:CA:AF:10:A5:37:17:D5:3C:9C:E0:31:59:1D:36:73:6F:32:5E:90:0B, which you can verify using keytool -printcert -jarfile on the APK. And yes: it does make me sad that this is a centralized key owned by us/me :/. For a while I managed to stick someone else at Orchid with this scary responsibility; but, sadly, it is currently back on my plate.)

Really, though, like with the smart contracts, I'd say the code should be the root of trust here as well... maybe it would then be useful to know that I care a lot about and am quite experienced with reproducible builds (I have been doing deterministic build systems since before Debian, which is awkwardly famous for their efforts in that space, as part of the toolchain and userland for jailbroken iPhones back in late 2007 and early 2008) and not only should Orchid's server and "cli" builds be fully reproducible, the GitHub CI setup--which is itself in the repository (check out .github/workflows/main.yml) so you can just follow along with to reproduce the build (showing there is no sleight of hand involved in this build by either myself or GitHub)--even builds the Linux server daemon twice on entirely different systems (once on a messy macOS box from GitHub's Azure fleet and a second time on Linux inside of clean a Docker setup for some old version of Ubuntu) to verify the result is bit-for-bit identical, as I consider it a serious regression if that fails ;P. If you run --version it doesn't just print out a hash of the code used to do the build but also details on the compilers and linkers used. I'd imagine in a future world where Orchid was heavily used and its security properties were scary, people would trade around and compare the hashes of their locally built binaries (rather than trusting me or a key).