1. I mixed up some concerns in my head. My concerns are that developers can do sneaky things by replacing events on users. Having a chain of versions I can see/store is what I was considering, that way I, the user, can decide which versions I want to run. And/or sneaky patches that alter the release system. Im concerned knowing that most organizations are going to have their release cycle automated and signing key stored in their devops system, if a safe version was replaced with a malicious version, users platforms might be able to roll back to a previous version, or users as well. What stops the publisher from replacing all versions at some point in the future, disallowing me from running an old version they had? I understand these are problems will face today, but I think we can fix that with some immutability.

Replies (1)

Developers constantly replace releases on users, bitchat for example recently did that and there are countless others. The Zapstore indexer captures releases from Github once and when the developer edits the release/associated assets the download breaks and users start yelling, so I know well how many times that happens. I don't think any of those edits were nefarious, they all seemed reasonable. Software assets (kind 3063) are regular events that carry version information, those could be kept around, however if I had social signal that a key was compromised I would stop trusting it altogether. If I already have the software installed and I believe it's pre-compromise I would keep running it. Developers are encouraged to use bunkers, not hotkeys. In addition I just introduced this: which has support in zsp (publisher tool) but not the UI yet. Interesting model because to compromise it you kinda need to hack *both* keystore and nsec -- for updates at least.