Nostr Web Client

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.

ChipTuner 1y ago

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.

Reply to this note

Please Login to reply.

Discussion

DanConwayDev 1y ago

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.

franzap 1y ago

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

ChipTuner 1y ago

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.