![](https://lemmy.world/pictrs/image/b80cd659-96c7-49cf-876a-98ddcae42335.png)
![](https://lemmy.ml/pictrs/image/a64z2tlDDD.png)
True, while I think the page that I linked explains the concept well, it might not be easy to digest for someone who is new to software development.
But then again, if you handle cryptographic materiel, you better learn fast 😃
True, while I think the page that I linked explains the concept well, it might not be easy to digest for someone who is new to software development.
But then again, if you handle cryptographic materiel, you better learn fast 😃
But I am thinking that their workflows are reproducible builds, correct?
A reproducible build is more than an automated build. It is a build process which enables any third party to build a binary that is bit-by-bit identical (see https://reproducible-builds.org/docs/definition/).
So if I would build a specific release/commit of your application on my PC (given an identical development environment, i.e. same version dependencies, compiler, etc.) it MUST result in a bit-by-bit identical binary to the one you built on your development machine and the one the github workflows built.
All these binaries would result in the same hash (and thus be verifiable by the same signature files).
“Here is my very simple commit that you can read, and here is the executable in case you want to download the fixed wallet but are not technically savvy enough to build it”
Other than a signed binary from a trusted developer/organization, there is (IMHO) no way for a non-tech savvy user to gauge the trustworthiness of a binary they download from the internet, and even then a signing key might have been lost or broken (see the recent Microsoft debacle w.r.t. AD signing key misuse).
I don’t know whether github actions output can be tampered with by you, but the only actually reliable way (that I know of) to prove that your binaries correspond to a certain state of the sourcecode is to support reproducible builds (See e.g. https://reproducible-builds.org/).
All other methods require trust (in either the developer or w.r.t. github actions towards github).
The drawback is of course, that to verify whether your binaries are good, someone needs to rebuild the software, but it is a good tool to build and maintain trust in your signed binaries, especially if they deal with sensitive information like private keys.
Not that I know of. I think this needs to be implemented in a system framework.
Basically, yes. IIRC the FIDO/U2F handling is implemented in google libs.
They are however re-implemented in microG: https://github.com/microg/GmsCore/wiki/Implementation-Status, so if you are open to using that it should work with apps using the corresponding google client libraries.
I have used Firefox on Lineage/microG and tested FIDO2 there, it does NOT work with Fennec as that does not include the required client side libraries.
Yeah, this topic would actually lend itself to an intro video which demonstrates the problem on a tiny project.