![](https://lemmy.world/pictrs/image/b80cd659-96c7-49cf-876a-98ddcae42335.png)
![](https://lemmy.world/pictrs/image/8286e071-7449-4413-a084-1eb5242e2cf4.png)
I use it and love it. Having the metadata (tags, dates, …) of your pages available to query and organize is awesome. I also love the tagged tasks feature.
I use it and love it. Having the metadata (tags, dates, …) of your pages available to query and organize is awesome. I also love the tagged tasks feature.
Yeah, this topic would actually lend itself to an intro video which demonstrates the problem on a tiny project.
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.
I use nextcloud.export
which comes with the snap (https://github.com/nextcloud-snap/nextcloud-snap/wiki/How-to-backup-your-instance), but the backup app looks nicer.
If you know of any FOSS, offline editors for Android which can do what silverbullet can, drop a link.