[Bug debuginfod/28204] extend webapi / verification with forthcoming signed-contents archives
https://sourceware.org/bugzilla/show_bug.cgi?id=28204 --- Comment #16 from Ryan Goldberg --- (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.
Re: Fwd: Anton Baltser, bug with libdebuginfod
Hi Anton, On Sun, 2023-07-30 at 22:05 +0300, anton baltser wrote: > Thanks for the quick response. > I did: > $ ./configure --prefix=/usr\ > > --disable-debuginfod \ > > --enable-libdebuginfod=dummy \ > > --libdir=/libm > $ make install : > Making install in tests > make[2]: Nothing to be done for 'install-exec-am'. > make[2]: Nothing to be done for 'install-data-am'. > make[2]: Nothing to be done for 'install-exec-am'. > /usr/bin/mkdir -p '/usr/include/elfutils' > /usr/bin/install -c -m 644 version.h '/usr/include/elfutils' [...] So this will also install debuginfod.h under /usr/include/elfutils Is that what you are asking about? Is it not doing that for you? > $ make check : > > Testsuite summary for elfutils 0.189 > > # TOTAL: 236 > # PASS: 232 > # SKIP: 4 > # XFAIL: 0 > # FAIL: 0 > # XPASS: 0 > # ERROR: 0 > > make[1]: Nothing to be done for 'check-am'. > > Is that right result? That looks correct yes. Cheers, Mark
Re: Fwd: Anton Baltser, bug with libdebuginfod
Yes, it works! Thanks for your help! On Mon, Jul 31, 2023, 18:43 Mark Wielaard wrote: > Hi Anton, > > On Sun, 2023-07-30 at 22:05 +0300, anton baltser wrote: > > Thanks for the quick response. > > I did: > > $ ./configure --prefix=/usr\ > > > --disable-debuginfod \ > > > --enable-libdebuginfod=dummy \ > > > --libdir=/libm > > $ make install : > > Making install in tests > > make[2]: Nothing to be done for 'install-exec-am'. > > make[2]: Nothing to be done for 'install-data-am'. > > make[2]: Nothing to be done for 'install-exec-am'. > > /usr/bin/mkdir -p '/usr/include/elfutils' > > /usr/bin/install -c -m 644 version.h '/usr/include/elfutils' > [...] > > So this will also install debuginfod.h under /usr/include/elfutils > Is that what you are asking about? Is it not doing that for you? > > > $ make check : > > > > > Testsuite summary for elfutils 0.189 > > > > > # TOTAL: 236 > > # PASS: 232 > > # SKIP: 4 > > # XFAIL: 0 > > # FAIL: 0 > > # XPASS: 0 > > # ERROR: 0 > > > > > make[1]: Nothing to be done for 'check-am'. > > > > Is that right result? > > That looks correct yes. > > Cheers, > > Mark >
Re: 答复: eu-strip on .rustc section produce error information
Hi Ziyang, On Sat, Jul 22, 2023 at 10:46:21AM +, chenziyang (C) wrote: > Thanks for reply. First you may get libtarget_1.so from > https://github.com/JetXujing/xujing/blob/main/libtarget_1.so Thanks. So using that trying to remove the .rustc section I do get: eu-strip: Cannot remove symbol [7873] from allocated symbol table [3] Note that this is a warning, not an error. The section is still removed. The issues is that in the original file the .rustc section is: $ eu-readelf -S libtarget_1.so.orig | grep .rustc [28] .rustc PROGBITS 006c71f2 00011e16 0 0 0 1 And symbol table 3 is: $ eu-readelf -S libtarget_1.so.orig | grep '\[ 3\]' [ 3] .dynsym DYNSYM d388 d388 00032598 24 A 4 1 8 Symbol 7873 in .dynsym is: $ eu-readelf --symbols=.dynsym libtarget_1.so.orig | grep 7873: 7873: 73238 OBJECT GLOBAL DEFAULT 28 rust_metadata_target_af70f9bf599b19f0 Note that symbol refers to ndx (section) 28. That is out .rustc section. Since .dynsym is an allocated symbol table it cannot simply remove that symbol. But since it refers to a section that is about to be removed it emits that warning and replaces the ndx (section) with UNDEF: $ eu-readelf --symbols=.dynsym libtarget_1.so.stripped | grep 7873: 7873: 73238 OBJECT GLOBAL DEFAULTUNDEF rust_metadata_target_af70f9bf599b19f0 > And I found the commit that trigger this error infor: > https://sourceware.org/git/?p=elfutils.git;a=commitdiff;h=7bf4b63a4980788e6c1969cae02f0483e79c069f;hp=4f7b5ba9624489b5a2f714569c29ef865d4dcd6f > Is this error info an expected behavior? Yes. It is an expected warning. Cheers, Mark
