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.
