1. Instead of replaceable event's couldn't timestamps or invalidation work? A pointer to the event that's being replaced also be signed? It could make it easier for stolen keys to replace old versions with malware. I understand the asset won't be replaced, but the public pointer with version to the asset will be. 2. Optionally displaying souce only supports http git remotes. You should at least consider a variable format for source code. Signed tarballs or zips are also totally acceptable from FTP sites for example. It might also be worth while to allow sums of source and/or a commit that the package was built from. 3. Are there ways to handle variants of x86 and others for example? I ship packages that require x86-64 v2 and sometimes v3 extensions. You mention it's "loosely based", so I assume it's not a strict set?

Replies (1)

Thanks! 1. Not following completely to be honest, if your keys are stolen you're cooked anyway. Planing to mitigate that in other ways. Timestamps and invalidation smells complexity 2. Nothing stopping you from pointing to a tarball (I have come across thousands of apps and never seen that, though). There is also a commit tag. 3. Out of scope, I guess can use `variant` if needed, or just specify that manually to users of your application