[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 #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.