I don't think there's a way to verify a package other than trusting the builder/signer. That's what reproducible builds are for.
Artifact hashes: yes, NIP-94
PGP: we're adding it to kind 0s! Currently building a tool developers will use with the ability to attach their PGP keys or certs. See
Artifacts should be signed by the developer IMO and attached to a source hash if the project is open source. Upstream depend on being able to verify binaries, when source isn't available, or the build process is too complex or undocumented, such is the case for polyglot systems or container based deployments.
I agree but it is also sometimes useful to have a application signing key.
The common way of signing a release is to sign a checksum file which lists all of the related binaries hashes. That is essentially what the the nip51 event does although it doesn't include the actual hash, but rather the id of each event that contains the hash. This makes it harder to find release events that include a specific binary because there may be many nip94 events referencing the same file. We need to query for nip94 events for the hash first and then find releases that reference those. I suppose isn't too bad.
It makes more sense to me that trust attestations are made against a release event and not just each individual binary. What if the author accidentally included a binary from the previous release? the hashed file would still have trust attestations attached.
How would you highlight that a previously issued release package shouldn't be trusted as it contains incorrect version? With a replaceable event the author could quietly update it and the user wouldn't know that they didn't use the correct binary.
Definitely agree that attestations can't be placed on mutable events.
> What if the author accidentally included a binary from the previous release? the hashed file would still have trust attestations attached.
Doesn't this go against your point? If the author accidentally points to a wrong binary in a mutable release set event, they can update it.
A user cares about finding an attestation for the actual thing they're installing.
If it were mutable, the author would need to revoked and reissue which would notify the users who installed the incorrect version.
I'm coming around to mutable. You wouldn't want to have to revoke a release to fix a typo in the change log. Clients could also keep track of the version they installed from and notify the user if a new version comes in with worrying changes in it.
Right, I'm thinking clients could detect an update in the mutable release set, and then trigger double-checking the references file metadatas? As you say maybe it's just a typo and user needn't be prompted about it
Agree on release signing keys, I was lumping that into the dev's key, because presumably the developer (or their infra) holds that key. AKA developer's keys.
I suppose my concern is that there is enough information attached with my binary when I download it that I can trace it's hash to the source code (if open source) or that they developer told me this is the latest version, and here is it's signature. And you must trust that developer. With closed source this trust would be required. Just like in PGP, I don't know that we need/want a trust-less system here, if that is your suggestion?
Sorry if I am missing the point.
I was trying to make the case for trust attestations made against releases rather than binaries like what happens with gpg signatures today. I'm coming around to them just being made against pubkeys, app profiles and binaries.
Given that nostr:nprofile1qqs8y6s7ycwvv36xwn5zsh3e2xemkyumaxnh85dv7jwus6xmscdpcygpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz8thwden5te0dehhxarj9ekh2arfdeuhwctvd3jhgtnrdakj7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qxvpy4 has already been building with mutable releases, I don't think there is a strong enough argument here to warrant a change.
Thanks for considering that too, nostr:npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr .
nostr:npub1qdjn8j4gwgmkj3k5un775nq6q3q7mguv5tvajstmkdsqdja2havq03fqm7 we can totally add a git commit to the 1063
And btw you can recreate a checksum file by querying kinds 1063 with a #e of the 30063 - basically one query
Yeah fair enough. This is what I did on my website: I always have source tarballs associated with commits along with binary tarballs. The tarball hashes are individually signed.
I'm thinking for a mode where we have sdks and libraries that are being pulling into other projects during build time, where everything runs automatically and we want a secure way to verify artifacts during the upstream CI pipeline.
