Technically, there is no guarantees that binaries are valid (yet). GH release runs are inaccessible after some time so you can only hope that nobody swapped binaries and hashes on the website/github. GH attestations allows the assertion of the build environment and gives you the option to verify the binary before using it in your project/port/cask/etc.
I wrote a small intro on GH attestations last year if anybody wants to see it in action with a zig project Artifact attestations ⢠charlesrocket
1 Like
The minisig signature attached to each tarball is the thing that guarantees that what youâre downloading was created by us. GitHub integration adds nothing to this system.
Thatâs now how it works. Interested users and other distributors (proxy owners, package managers, etc) are expected to save a local copy of our minisig public key. Once they do that, if an attacker gains access to our machines and tries to swap a tarball, they wonât be able to produce a valid signature for it.
The only weakness with this system is that you need to copy the public key at a time where it has not been compromised yet, but thatâs something that can be easily mitigated by a pinch of social legwork (ie ask people directly involved to confirm the value is good, or get confirmation though other reasonably reputable sources, like existing proxies or packages in other package indexes).
4 Likes
This sounds pretty weak if I have to âwalk around and askâ, relying on 3rd partyâs assertion. âDo not trust! Verify!â
How could one tell if the change in minisig is a valid key cycle or an attack?
GitHub Attestations are by definition trusting a third party.
How can you tell when GitHub rotates whatever keys might be involved in attestations vs an attack on GitHub infrastructure (or a take over of a key ZSF GitHub account)? Whatever works for GH can work for our system.
2 Likes
So I am getting this right and you cannot tell the difference between the attack and key cycle. Nothing is being rotated with GH attestations, thats kinda the idea Attestation ¡ charlesrocket/xtxf ¡ GitHub. Asking somebody on the chat and verifying GH assertions sounds like very different things. I am pretty sure its easier to steal a key from a linux machine than infiltrating every required entry point to mess with GH assertions.
Oh snap, its actually worse than I thoughâminisig still has no support for security keys. add support for security sticks, e.g. Yubikey ¡ Issue #95 ¡ jedisct1/minisign ¡ GitHub
Why does that matter for Zig?
Minisig is used as a public signature used for verification.
There is no need to hide that public hash.
Could you please stop jumping from topic to topic calling everything bad, without giving a good in-depth explanation in what way and why?
Otherwise it seems like you are overstating your expertise, if you have knowledge about something definitely being a bad practice than please explain it, if you canât explain it, then stop claiming things, you donât understand well enough so that you can present your point in detail.
Nobody needs to be an expert on everything before they can talk about it, but if you talk about it as if you are an expert, but then donât share your chain of reasoning, but only your claim about what you find the right thing to do, without sharing how you got to that conclusion, or even showing that you understand why other people may not agree with your conclusions (and how/why that disagreement is wrong), than I donât know how to take you seriously.
If we canât talk about details and learn things (through explanations), then this topic is just pointless bike-shedding.
8 Likes
Because you cannot securely store minisigâs private keys, since they are still working on the cold storage support (or not). And it is bad practice to store any valuable key hot on the machine. As far as I can tell from this topic, this minisigâs private key is the only key validating the integrity of the release. Sounds like it should be secured with the maximum effort, which is not possible with minisig. A quick fix would be migration to pgp on the same ed25519.
I donât feel like I am jumping from topic to topic. I just feel uncomfortable touching sensitive stuff on the public forum. I mentioned before I can break things down on keybase/other private channel, but here it would be irresponsible. So, please, excuse the lack of detailed walkthroughs.
Maybe if I posted here right away and not got into the weird ignoring hole on the discord, I would be more on mental resources and all hippy-dippy about it.
Note that âthe discordâ is just one of many Zig communities, not officially endorsed. Compiler development used to be coordinated there, but that has now moved to Zulip.
I was trying to reach the official staff member there, but got somewhat personal and shallow âno more githubâ without any chance of follow-up 
IMHO, this is a reasonable option. minisig always struck me as a still work in progress. At the moment GPG is more solid.
EDIT: key distribution story is bad for both minisig ang pgp/gpg. block-chain bros to the rescue 
I was trying to justify the tooling choice for a while, but just now realized its not its functionality but the language used?
PS
nah, blockchain bros only help themselves and charge 40 BTC per ios release. cypherpunks push it for free 
I was sarcastic when talking about âblock-chain brosâ.
got me good)) after all that roaring nft hype I now read ârug pullâ instead of âblockchain broâ 