[Bug debuginfod/28204] extend webapi / verification with forthcoming signed-contents archives

["rgoldber at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=28204

--- Comment #19 from Ryan Goldberg <rgoldber at redhat dot com> ---
(In reply to Mark Wielaard from comment #17)
> Maybe prefixing or postfixing URLS with + or adding the name of the cert?
I'm leaning towards a combination of this idea with my original. We can use
DEBUGINFOD_IMA_POLICY to set the default ima verification response policy
(possibly renaming to DEBUGINFOD_IMA_DEFAULT_POLICY) and then we can use
DEBUGINFOD_URLS="url1+enforcing url2 url3+ignore". This seems like a simple way
the user can define policy at a granularity of their choice. I wrote up a quick
test patch for this and it seems pretty straightforward.

(In reply to Frank Ch. Eigler from comment #18)
> > Doesn't that give a false sense of "security"?
> > It still rejects some stuff, but doesn't really protect against "falsifying"
> > files, all a server has to do is not provide an IMA 
> 
> Yes, but trusted servers won't just do that.
It's up to the user to choose when to allow a permissive policy. Maybe not
using it as the default will alleviate these concerns? A user would have to
explicitly choose to 'let their guard down' when for instance using a trusted
server

> The difference between missing and invalid is that the latter is KNOWN bad.
> An invalid signature is evidence that the file has a problem.
I agree that the distinction is enough that having a 3rd mode seems like a good
bet. When using https://debuginfod.fedoraproject.org/ it doesn't feel like an
issue to me to use a file that doesn't happen to have a signature, but otoh I
wouldn't want one that I know is incorrect

-- 
You are receiving this mail because:
You are on the CC list for the bug.