https://sourceware.org/bugzilla/show_bug.cgi?id=28204
--- Comment #16 from Ryan Goldberg <rgoldber at redhat dot com> --- (In reply to Mark Wielaard from comment #12) > In config/profile.csh.in and config/profile.sh.in the prefix variable is > explicitly set and no longer unset. Is that deliberate? Taking a look at both files they seem to still contain `unset prefix` as their last lines. Would that not do the trick? > In debuginfod_validate_imasig the file_data = malloc(data_len); depends on > the (externally) given file size. It is then read in one pread call. And the > whole buffer is then given to EVP_DigestUpdate. Note that this might create > a giant malloc buffer, which might trigger OOM. pread might succeed with > fewer bytes than given. It needs to be called in a loop. But it would be > better if we could read it and feed it to EVP_DigestUpdate in (small) chunks. Sure, just looked at the docs for EVP_DigestUpdate and seems like this change should be pretty straightforward. > Is EACCESS the right error code to return when the signature couldn't be > checked/is invalid? That is the same as when we get > CURLE_REMOTE_ACCESS_DENIED. It might be good if it was an unique error code > so users can know that the file was not trusted. How do you feel about EPERM? Not exactly its usage but we've used up a good number of the more applicable ones with the CURL errors (EACCESS, EINVAL) (In reply to Mark Wielaard from comment #13) > The configure checks might need to check whether the rpm development headers > define the needed constants. Sure (In reply to Mark Wielaard from comment #14) > I think it is the user/distro packager who should decide which ima-certs to > ship. I don't think elfutils should come with ima-certs itself. >From what I've seen finding the correct certificates for IMA verification has been pretty tricky, so distributing a copy of these (at least early certificates) might be a good idea. Eventually the intention is for these certs to be shipped in a known location which we can easily add to the search path, but until then having a copy seems like the best bet imho. > Why is there a "permissive" policy? What is the use case for this? It might be that a user wants to be aware of what's going on but does not need to be quite so strict on rejection. Permissive won't allow incorrect signatures but will allow say an unsigned file whereas an enforcing client will reject anything that does not come with a valid signature > Should the policy be per debuginfod url? So you can point to an official > distro debuginfod which must be in enforcing mode, but can add a local one > with an "ignore" policy. I was thinking of keeping things simple, but don't have anything against moving to a per URL sort of approach. What kind of format would you want for such a thing? For urls foo:bar:baz would we want something like ignore::enforcing where blanks are the default? Don't love this structure since it seems a little unwieldy. I'll think on a better format for it. (In reply to Mark Wielaard from comment #15) > But I must admit that I am a little lost in the rpm and koji mechanisms to > extract those signatures. How easy will it be to extend to other platforms > that might store such signatures in different ways? The koji flag seems like a necessary evil in my opinion. At least the way it works is that when the flag is enabled we try the koji storage method and then fall back to the rpm itself, so to add another signature storage format we could do the same method, so adding more shouldn't be too difficult. Might require a little logic tweak but wouldn't think its too complex a change -- You are receiving this mail because: You are on the CC list for the bug.
