[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 #23 from Ryan Goldberg <rgoldber at redhat dot com> ---
(In reply to Mark Wielaard from comment #22)
> This still feels odd. Since you cannot distinguish between non-sig f36
> package (okish?) and non-sig f38 packages (bad?). I think you have to either
> trust or reject all non-sig packages from such a server.
I see where you're coming from but what policy would you use for
https://debuginfod.fedoraproject.org? We'd have to ignore then, which seems
like one of the primary users of such verification might just skip it all
together.

> I'll look at the code to see if I understand what this means in practice.
> Are those the messages presented to the user (in verbose mode? always?). And
> does this mean all three cases warn (or only the second and third)? And is
> it just a message or does it also mean actual rejection in some cases?
2008   if(NULL != url_ima_policies && ignore != url_ima_policies[committed_to])
2009   {
2010     int result = debuginfod_validate_imasig(c, target_cache_tmppath, fd);
2011     if(0 == result)
2012     {
2013       if (vfd >= 0) dprintf (vfd, "the signature is valid\n");
2014     }
2015     else if(EINVAL == result || enforcing ==
url_ima_policies[committed_to])
2016     {
2017       // All invalid signatures are rejected.
2018       // Additionally in enforcing mode any non-valid signature is
rejected, so by reaching
2019       // this case we do so since we know it is not valid. Note - this not
just invalid signatures
2020       // but also signatures that cannot be validated
2021       if (vfd >= 0) dprintf (vfd, "ALERT: this download is being rejected
since the IMA signature could not be verified\n");
2022       rc = -EPERM;
2023       goto out2;
2024     }
2025     else
2026     {
2027       // By default we are permissive, so since the signature isn't
invalid we
2028       // give it the benefit of the doubt
2029       if (vfd >= 0) dprintf (vfd, "the signature could not be
verified\n");
2030     }
2031   }
2032 

Here is the relevant snippet

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