On Tue, 2019-03-12 at 17:00 +0000, Robert McQueen wrote:
So - it would be much better if we were able to add such a "pushed" commit into the Flathub repos, and add our collection ID bindings, without having to modify the commit and invalidate the upstream signature. Is there a way we could, for example, add a collection and ref binding in the detatched metadata where we add a signature, so that the original commit and its signature can be left intact?
Did you ever get any bright ideas about this? I realise I have completely missed the boat on it (sorry, never prioritised putting aside time to reply), but here are some thoughts. Proviso: I haven’t thought seriously about OSTree P2P stuff for a year now, so I am partially out of date, and partially rusty. I see a fairly major problem with the example you give, in that: - If someone trusts (say) Mozilla’s key, but not flathub’s key, and - flathub has added collection–ref bindings and its signature as detached metadata on the OSTree commit originally signed by Mozilla; then - the user can’t verify the flathub collection–ref bindings without trusting the flathub GPG key, which means - the user can only access the flatpak via Mozilla’s repository (if such a thing were to exist), and not flathub. A naive solution to that would be for flathub to add its bindings and signature as detached metadata, and then for Mozilla to sign all that with even more detached metadata, but that’s just getting silly — and if that’s possible, why not just get them to sign flathub’s bindings when generating their commit in the first place? Which leads me to my actual suggestion, which is that: • You get third parties who are generating flatpaks (say, Mozilla) to add the flathub bindings in when they originally generate and sign a flatpak. • flathub then adds its signature on top as detached metadata, which should already be supported by OSTree (I think?). • flathub doesn’t need to add more bindings then. To reiterate for those who are reading along at home (not Rob, you know this already), IIRC the way that the P2P stuff was originally designed, the idea was for bindings to be addable by re-generating the commit metadata (and re-signing it). If that security model were to change (by supporting adding bindings in detached metadata), we really should re- check the whole security model to check it doesn’t introduce flaws. I don’t think this is something which can just be tacked on with no consequences. A note about detached metadata: it is currently always pulled from the remote when pulling the associated commit metadata, and GPG verification always happens after all that data is pulled. So from that point of view, it would be workable. Yours delayedly, Philip
Attachment:
signature.asc
Description: This is a digitally signed message part