[Bug debuginfod/28204] extend webapi / verification with forthcoming signed-contents archives
https://sourceware.org/bugzilla/show_bug.cgi?id=28204 --- Comment #11 from Mark Wielaard --- So as far as I understand this is now the three commits on top of users/rgoldber/try-bz28204c: https://sourceware.org/cgit/elfutils/log/?h=users/rgoldber/try-bz28204c I find it slightly easier when patches are simply posted to the mailinglist (using git send-email). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/28204] extend webapi / verification with forthcoming signed-contents archives
https://sourceware.org/bugzilla/show_bug.cgi?id=28204 --- Comment #12 from Mark Wielaard --- In config/profile.csh.in and config/profile.sh.in the prefix variable is explicitly set and no longer unset. Is that deliberate? 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. 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. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/28204] extend webapi / verification with forthcoming signed-contents archives
https://sourceware.org/bugzilla/show_bug.cgi?id=28204 --- Comment #13 from Mark Wielaard --- The configure checks might need to check whether the rpm development headers define the needed constants. On an rhel8 system this gives: checking for headerGet in -lrpm... yes checking for imaevm_hash_algo_from_sig in -limaevm... yes checking for EVP_MD_CTX_new in -lcrypto... yes but... Making all in debuginfod CXX debuginfod.o elfutils/debuginfod/debuginfod.cxx: In function ‘MHD_Response* handle_buildid_r_match(bool, int64_t, const string&, const string&, const string&, int*)’: elfutils/debuginfod/debuginfod.cxx:2026:47: error: ‘RPMSIGTAG_FILESIGNATURES’ was not declared in this scope if (!sig_hdr || 1 != headerGet(sig_hdr, RPMSIGTAG_FILESIGNATURES, &sig_tag_data, HEADERGET_ALLOC)) ^~~~ elfutils/debuginfod/debuginfod.cxx:2026:47: note: suggested alternative: ‘RPMTAG_FILESIGNATURES’ if (!sig_hdr || 1 != headerGet(sig_hdr, RPMSIGTAG_FILESIGNATURES, &sig_tag_data, HEADERGET_ALLOC)) ^~~~ RPMTAG_FILESIGNATURES make[2]: *** [Makefile:657: debuginfod.o] Error 1 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/28204] extend webapi / verification with forthcoming signed-contents archives
https://sourceware.org/bugzilla/show_bug.cgi?id=28204 --- Comment #14 from Mark Wielaard --- 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. Why is there a "permissive" policy? What is the use case for this? 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. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/28204] extend webapi / verification with forthcoming signed-contents archives
https://sourceware.org/bugzilla/show_bug.cgi?id=28204 --- Comment #15 from Mark Wielaard --- The basic idea having a collection of certs, and an signature for each file that is transported with the fetch operation that will be checked against those trusted certs is understandable. 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? -- You are receiving this mail because: You are on the CC list for the bug.
