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.
