How secure is anything really?
Focus: Musings on dependencies
How do you know the software you use is safe? ElectrumSV is dependent on many open source packages. Most of them hosted on the Python package index. We don’t look at the source code as we upgrade each to a new version, ideally vetting every change made.
Packages as dependencies
Even if we vetted every change that was made to our dependencies, we do not use that source code. We do what everyone else does, in order to live in a real and practical world. We fetch published packages. It is the package any installation of ElectrumSV obtains, that we validate, not the source code the package came from.
There is no guarantee that the official package for any dependency we use was built from any source code we might have theoretically vetted. Where the source code comes from, and who built the package, and how and where that package was built are not identifiable.
Best practices for dependencies
When we build an ElectrumSV binary for release, all the dependencies should be verified. For the Python packages, each download that will be included is hashed — which means that if we get a different file than the one we require, the build process will fail. For other dependencies, we manually retrieve the source code from a commit in the relevant Git repository, which again ensures the source code we obtain must be the source code we require.
Again, we have no real knowledge of what source code was used in the Python packages we require for a build. At least, not unless they are the ones we built ourselves. It should be obvious by this point, that it is impractical to have this knowledge.
Even if we weren’t an open source project with limited resources, it wouldn’t change anything. We do what most every software developer does. We choose a limited set of well known and visible dependencies and use best judgement to assume they are safe enough. And we decide very carefully what additional dependencies we choose to incorporate. This is all we can realistically do.
Electrum Core, and likely also Electron Cash, have put a lot of work into reproducible builds. What this means is that everything about making a build is locked down and adjusted, so that not only is every dependency fixed to a specific version, but the resulting binaries when built should be byte-for-byte identical to those anyone builds using the same process.
While the ideal, it’s somewhat of a facade. Their dependencies are checked in much the same way as ours. The only thing this gives is the ability to prove that, given you have vetted the source code, the binary you get is the one that a build will make from the given source code you vetted. Even this is to a degree fragile, if something that was not already identified as variable changes, it is possible that the builds will stop being reproducible.
This is valuable, but I consider it to be mostly a thing nerds value. The real value for me, would perhaps be in a system of packages that enforced and checked this property. And secondary services which checked and proved it — witnessing it, if you prefer. And keys and signing, so any problem becomes inherently tied to the loss of value for an identity.
If no-one is vetting all that source code and vouching for it by signing something, then perhaps the value of an ideal system like this is undermined. In which case perhaps it becomes the signatures and value of identity, that has the main value. And we already sign our downloads, albeit with the nightmarishly painful experience that is GPG.
Reproducibility and insurance
At this point I am going to go on a minor tangent and wonder how insurable software security would be, within defined conditions.
If there was this ideal source of dependencies that guaranteed both reproducibility and observed signatures from those for whom it means something to vet relevant source code, then this should if constructed correctly allow verifiable confidence. If your project in turn adopted these practices, and the complete stack met the criteria, then this would give a level of security that most if not all through lack of budget cannot afford to achieve today.
There’s an idea somewhere here related to an alternate Python package index built on Bitcoin SV payments, that uses Bitcoin SV keys for signing and identity, and only deals in reproducing builds and including those that pass the requirements. If an application or package is included, it has to have met those requirements of reproducibility, and can prove it through presence. The service, not the developer should produce the package. Add in a system where those identities can sign, and weight being given to domain experts who do so. Monetise it all.
Sell personalised proof of the complete end to end verifiable build. Or sell reproducible build specifications, and provide snapshots of dependencies, and sign the lot. After all, availability of dependencies can always change. Offer consultancy for helping projects or businesses get their product (closed or open source) included — which leads beyond Python as a project like this should. Become the primary source of verifiability compliance. If a business needs an open source project verified, then you’re the person they come to to get it done.
Worthwhile? Valuable? You decide.
Everything is based on trust. We can build better systems that remove the need to trust, if it is worthwhile to do so. But who has time for that.
For now, ElectrumSV will just try and choose our dependencies wisely. Someday maybe, everything will be reproducible and verifiable, and people will be vetting all the source code. But if you expect that now, you better start reading and building every application you use.