PATCH PR30962, debuginfod

commit e967988e419121cad1d7f40013a316059b1173f0 Author: Frank Ch. Eigler Date: Tue Oct 10 16:21:00 2023 -0400 PR30962: debuginfod: full paths for X-DEBUGINFOD-FILE/ARCHIVE response headers Previous code was inconsistent in offering basename versus full pathname for these

Re: PATCH PR30962, debuginfod

Hi - > I think this makes sense, but it would be good to see an example of the > paths this now exposes. e.g: % debuginfod-find -v debuginfo /bin/ls [...] x-debuginfod-size: 502024 x-debuginfod-archive: /mnt/fedora_koji_prod/koji/packages/coreutils/9.3/4.fc39/x86_64/coreutils-debuginfo-9.3-4.fc3

Re: PATCH PR30962, debuginfod

Hi - > OK. But I think you should add an explanation or example to "Front-end > proxies can also elide sensitive path name components" paragraph. So > the user is fully aware what those "sensitive path names" are. Maybe > even add that debuginfod-find -v example so people can double check. OK, re

[PATCH] debuginfod PR29472: metadata queries

users/fche/try-pr29472 branch. Before a final commit, might nuke the ChangeLog bits and copy key content over into the git commit message. commit 8dd1108b6779b8efd5e4037e0653de7702839cc8 Author: Frank Ch. Eigler Date: Tue Apr 11 23:35:25 2023 -0400 PR29472: debuginfod: add metadata query

Re: PR30000 - introduce new srcfiles tool

Hi - On Thu, Sep 28, 2023 at 10:59:38AM -0400, Housam Alamour via Elfutils-devel wrot > Here is the new srcfiles tool ready for review. This lgtm. - FChE

Re: [PATCH] PR28204, debuginfod IMA

Hi - Thanks for the review. > [...] > BTW. The diff doesn't show the newly added binary files. So the patch > cannot be applied. Please use git send-email or git format-patch for > that. I would not expect the emailed patch to apply, esp. with all the other work done in the intermediate months,

Re: [PATCH] PR28204, debuginfod IMA

Hi - > > I would not expect the emailed patch to apply, esp. with all the other > > work done in the intermediate months, which is why the code is also in > > the git branch. The binary files do not seem effectively reviewable > > anyway. > > It would be really convenient though. And modern git

regarding the "Abusing gdb Features for Data Ingress & Egress" paper

Hi - A few days ago, I was pointed to a paper [1] from a security researcher that deals with debuginfod. The first half of the paper is a fine overview of how the system works. [1] https://www.archcloudlabs.com/projects/debuginfod/ The second half takes a turn toward security concerns. I'd lik

Re: [PATCH] PR28204, debuginfod IMA

Hi, Mark - > > Considering how easily the trybots can process the actual code - and > > have done so before posting the patch for review - we can consider > > some CI well done already. After approval but before merge, it would > > undergo another round of trybotting. With such workflow, patchw

Re: [PATCH] readelf: Support .gdb_index version 9

Hi - > OK. BTW the description of the gdb_index at the top > https://sourceware.org/gdb/current/onlinedocs/gdb/Index-Section-Format.html > doesn't resolve anymore. It is now > https://sourceware.org/gdb/current/onlinedocs/gdb.html/Index-Section-Format.html Added another httpd redirect to make th

Re: [PATCH] PR28204, debuginfod IMA

Hi - > >\fIima:optimistic\fP Every downloaded file with a known-invalid > >signature is rejected, protecting against some types of corruption. > > I like this wording more. But maybe it would be helpful to split the > patch into one that implements ima:enforcing and another that adds the

[patch] debuginfod.8

commit 06e0aacb4b288403bd02a0820dd0f87c7f017a2b (HEAD -> master) Author: Frank Ch. Eigler Date: Tue Nov 14 14:09:40 2023 -0500 doc/debuginfod.8: clarify source file handling Added text about the archive common-prefix heuristic, mentioned the new eu-srcfiles tool, and g

Re: [PATCH] PR 30991: srcfiles tarball feature

Hi - > > > - // This is a common symptom for dwz-compressed debug files, > > > - // where the altdebug file cannot be resolved. > > Was it intended to remove this comment? Yes, it was copy/pasted from debuginfod by mistake. - FChE

[PATCH] PR31265 - rework debuginfod archive-extract fdcache

Hi - I plan to roll out this improvement to all the servers I look after, via COPR builds or such, it's that impactful. commit 7bfc10acc7f0e00c5bc45416d1bf8ee183d79ff3 (HEAD -> master) Author: Frank Ch. Eigler Date: Thu Feb 8 19:33:55 2024 -0500 PR31265 - rework debuginfod

Re: [PATCH v2] dwarf_getaranges: Build aranges list from CUs instead of .debug_aranges

Hi - > > We could then also introduce a new public function, dwarf_getdieranges > > (?) that does the new thing. But it doesn't have to be public on the > > first try as long as dwarf_addrdie and dwfl_module_addrdie work. (We > > might want to change the interface of dwarf_getdieranges so it can b

Re: [PATCH] debuginfod: Remove unused variable

Khem Raj writes: > Recent commit acd9525e9 has removed all references to max_fds > therefore remove it, moreover clang18 is happier Thanks, merged as obvious. - FChE

Re: [PATCH] debuginfod.cxx: periodically malloc_trim()

Hi - > From: Di Chen > Date: Mon, 18 Mar 2024 09:06:19 +0800 > Subject: [PATCH] debuginfod.cxx: periodically malloc_trim() > > Add malloc_trim() for releasing memory which is allocated for temporary > purposes, e.g. answering queries, adding data to the database during > scans. > > https://sour

Re: [PATCH] srcfiles: fix unused variable BUFFER_SIZE

Hi - > The const variable BUFFER_SIZE is used only on the zip_files > function witch is only available with LIBARCHIVE. Thanks, merged as obvious. - FChE

[rfc] [patch] PR28204: debuginfod ima signature verification

_match): Added extraction of the + per-file IMA signature for the queried file and store in http header. + * (find_globbed_koji_filepath): New function. + * (parse_opt): New flag --koji-sigcache. + * debuginfod-client.c (debuginfod_query_server): Added policy for +

Re: Inquiry about Development Features and Integration of Source Code Version Control Systems

Hi - > [...] Specifically, I am interested in understanding how the > Debuginfod Server can facilitate the direct download of source code > from Git repositories. [...] Can you explain under what situations you think this would be helpful? The main challenge is that compilers don't generally ha

Re: Inquiry about Development Features and Integration of Source Code Version Control Systems

Hi - > Support for reading source code directly from a code hosting service > (such as GitHub) has been supported for years by Microsoft via > SourceLink[1]. [...] Thanks for that reminder. Yeah, eventually that could be an alternate way. > [...] > > Can you explain under what situations you th

Re: [rfc] [patch] PR28204: debuginfod ima signature verification

Hi, Mark - > > - to drop "permissive" mode > > We discussed a bit on irc about "wording". But I think it isn't really > how it is worded, but that there is just different features. What is > called "enforcing" is an authenticity scheme. While "permissive" is > more like an (optional) error-detec

Re: [rfc] [patch] PR28204: debuginfod ima signature verification

Hi - > > IOW, without a "permissive" mode being available at all, we could not > > ask users to enable this new code at all for our own federated > > servers, nor even for fedora. That's because no server can guarantee > > the availability of signatures for all content they can serve. > > I don'

Re: [rfc] [patch] PR28204: debuginfod ima signature verification

d-find.1, doc/debuginfod_find_debuginfo.3: Update SECURITY. * tests/run-debuginfod-ima-verification.sh: New test. * tests/debuginfod-ima: Some new files for the tests. * tests/Makefile.am: run/distribute them. Signed-off-by: Ryan Goldberg Signed-off-by: Frank Ch. Eigler diff -

Re: [rfc] [patch] PR28204: debuginfod ima signature verification

Hi - On Tue, Apr 16, 2024 at 06:15:00PM -0400, Frank Ch. Eigler wrote: > The following is the candidate patch for the basic functionality. > It's been corrected for whitespace & error codes, given more complete > docs and commit message. See also the users/fche/try-bz2824f bra

Re: [PATCH] Fix 'make coverage' when used with lcov version 2.0+

Hi - On Fri, May 10, 2024 at 12:53:39AM +0300, Dmitry V. Levin wrote: > > Pushed as commit ca8ad4648197 > > What's the purpose of sending proposed patches to the mailing list > if reviews are silently ignored? Please be collegial and don't exaggerate. - FChE

Re: [PATCH] Fix 'make coverage' when used with lcov version 2.0+

Hi - > > > What's the purpose of sending proposed patches to the mailing list > > > if reviews are silently ignored? > > > > Please be collegial and don't exaggerate. > > The fact is that the review was silently ignored, which is, from my point > of view, an extraordinary event, The review *si

Re: [PATCH] Fix 'make coverage' when used with lcov version 2.0+

Hi - > Well, even if it happened unintentionally, it was ignored just the same > as if it happened on purpose. I hope the technical reasons for that > are now fixed, and won't cause any problems next time. You have been in the open source community long enough to know that emails sometimes just

Re: [PATCH] Support nullglob in profile.sh.in

Hi - > > Don't block on stdin when /etc/debuginfod/*.certpath expands to nothing. > > Signed-off-by: Andreas Schwab Thanks, committed as obvious. > I slightly prefer "cat but this variant is also fine. I see your point, but the other five cases in the profile.* use this formulation, so for s

Re: [patch] debuginfod metadata extension

Hi - > Thanks for the patch, some suggestions below. Thanks, adding the following 'git diff -w' to the patch you reviewed: > [...] > I was experimenting with metadata queries to a local server that indexed > a single rpm (binutils-2.41-8.fc40.x86_64.rpm). The following commands > produced JSON w

PATCH: debuginfod configury rework

Hi - A few buildbots are unhappy with the debuginfod configury from yesterday. It's right: it's rather convoluted. This patch reworks and harmonizes all of that stuff. Author: Frank Ch. Eigler Date: Mon Jun 3 18:14:52 2024 -0400 rework debuginfod configury Rewo

git/master snapshot debuginfod deployed to fedora.stg server

Hi - Open for your experimentation needs, on a recent fedora client and a fresh build of elfutils, env DEBUGINFOD_URLS='ima:enforcing https://debuginfod.stg.fedoraproject.org' \ DEBUGINFOD_IMA_CERT_PATH=/etc/keys/ima \ DEBUGINFOD_VERBOSE=1 \ debuginfod-find debuginfo /bin/ls should r

make dist considered harmful: odd gotcha with building elfutils rpms

Hi - While trying to get a reliable fedora-copr build of the git/master snapshot of elfutils, I ran into a problem that took me too long to figure out. I was running "make rpm" from an elfutils build tree, which involves running a "make dist" substep to produce a complete buildable source tarball

Re: make dist considered harmful: odd gotcha with building elfutils rpms

Hi - > That is certainly a bug, dist targets shouldn't be conditional. Thanks! > [...] > > But I think the root cause is more the continued reliance > > on "make dist", made necessary by the exclusion of generated autoconf* > > materiel in the source tree. > > I really don't think putting gen

Re: make dist considered harmful: odd gotcha with building elfutils rpms

mark wrote: > [...] Having each committer push generated files with their own > variant of the tools causes generates updates that are hard to sanity > check by others. Indeed. Luckily, configury changes are rare, and distractingly wordy generated-code-diffs are rarer. And if they are indeed

Re: [PATCH] Add man pages for some libelf functions

Aaron Merey writes: > [...] By the way, in addition or instead of using tarballs for carrying this bulk content toward review, a git branch holding it all work about as well. - FChE

Re: [PATCH 1/2] libdwfl: specify optional sysroot to search for shared libraries and binaries

Hi - > [...] For example, we might be looking at a core file from an ARM > system using elfutils running on an x86 host. [...] Makes sense. By the way, to what extent would debuginfod (serving files from that sysroot) work for this same use case? - FChE

Re: [PATCH 1/2] libdwfl: specify optional sysroot to search for shared libraries and binaries

Hi - > > > [...] For example, we might be looking at a core file from an ARM > > > system using elfutils running on an x86 host. [...] > > > > Makes sense. By the way, to what extent would debuginfod (serving > > files from that sysroot) work for this same use case? > [...] > Frankly I don't kno

Re: [PATCH 0/3] debuginfod: speed up extraction from kernel debuginfo packages by 200x

Hi, Omar - Thanks. I wish this sort of amazing kludge weren't necessary, but given that it helps, so be it. I'd like to commend you on the effort needed to match your code up with the stylistic idiosyncracies of the debuginfod c++ code. It looks just like the other code. My only reservation is

Re: [PATCH v2 0/5] debuginfod: speed up extraction from kernel debuginfo packages by 200x

Hi - > This is v2 of my patch series optimizing debuginfod for kernel > debuginfo. v1 is here [7]. This generally looks great to me. I'll send it through the testsuite trybots here. But there isn't an xz-y test case yet. Is there a smallish seekable-xz rpm file that you have or could make tha

Re: [PATCH v2 0/5] debuginfod: speed up extraction from kernel debuginfo packages by 200x

Hi - > [...] I'll send it through the testsuite > trybots here. [...] There was some success and there was some failure. :-) all 11 runs: https://builder.sourceware.org/testruns/?commitishes=&has_expfile_glob=&has_trsfile_glob=&has_keyvalue_k=testrun.git_describe&has_keyvalue_op=glob&has_keyva

Re: [PATCH v3 0/7] debuginfod: speed up extraction from kernel debuginfo packages by 200x

Hi - > This is v3 of my patch series optimizing debuginfod for kernel > debuginfo. v1 is here [7], v2 is here [8]. This version fixes a couple > of minor bugs and adds test cases. [...] Thanks, LGTM, running through try-buildbots to make sure. - FChE

debuginfod service for rpmfusion content

Hi - We have recently started snapshotting rpmfusion content for purposes of distributing its debugging data. https://debuginfod.systemtap.org/ is a part of the elfutils debuginfod federation, and is now serving all present and forseeable-future rpmfusion debug content. https://bugzilla.rpmfusi

[patch] debuginfod metadata query timeout enforcement

Hi - Proposed patch for a problem we spotted recently in unreleased code: commit b853004e723d058f97362dbfdc40d1c49ea2ef51 (HEAD -> main) Author: Frank Ch. Eigler Date: Tue Sep 3 11:27:36 2024 -0400 debuginfod: service metadata queries in separate, timed-out connections

Forw: [RFE] Improve handling of framepointer-based backtraces for function prologue samples

Hi - wcohen wrote this to linux-perf-users@, touching on unwinding and especially eu-stacktrace comparison subjects. https://www.spinics.net/lists/linux-perf-users/msg44812.html - FChE

Re: don't run elfutils as root in ABRT

Hi - On Fri, May 05, 2017 at 06:25:30PM +0200, Adam Šulc wrote: > [...] > Do you have any idea how to pass the open file descriptor into the > function? Or what is the best way how to achieve this? Via file name "/dev/fd/232" ? - FChE

Re: [PATCH v3] Use fallthrough attribute

Hi - On Sat, Feb 10, 2018 at 03:26:43AM +0100, Mark Wielaard wrote: > I added ChangeLog entries and pushed it to master. What's a ChangeLog entry? :-) - FChE

Re: dependency

Hi - > is there a reference for the last stable version of Elfutils? > [...] > https://sourceware.org/elfutils/ftp/0.168/elfutils-0.168.tar.bz2 Each elfutils release is "stable". Are you looking for a fixed URL for the most recent release? - FChE

Re: [PATCH] Skip run-readelf-compressed.sh test if built without bzip2

Hi - > It might just be git am. It does display fine in my mua too, it is just > git am doesn't seem to like the raw message: > > https://sourceware.org/cgi-bin/get-raw-msg?listname=elfutils-devel&date=2019-q1&msgid=67ff4de2-fd5a-0ba8-0b5d-173c5619a88b%40qt.io That could be because of sourceware

Re: Elf64_Phdr

Hi - > If I have a Elf64_Phdr, why can't I straight change its elements, like, I'm > getting seg fault when trying to do: > (see gdb output) > > ... received signal SIGSEGV, Segmentation fault. > ... > 957 oldPhdr->p_vaddr = 0x1235; > (gdb) p/x oldPhdr > $11 = 0x3ffb4bf0040 The elf_begin(

Re: [RFC PATCH 0/2] elfutils: don't use dlopen() for libebl modules

Hi - > [...] > My understanding of the benefit of separate modules is that we don't > need to link all backend modules into every elfutils binary. I did some > measurements to that end: > > Dynamic backends (status quo): > 44K ./libasm/libasm.so > 380K./libdw/libdw.so > 120K./libelf/l

Re: [RFC PATCH 0/2] elfutils: don't use dlopen() for libebl modules

Hi - > This is actually with dynamically linked binaries -- the size increase > is because we link libebl.a directly into all of the binaries in > addition to libdw.so: > > objdump_LDADD = $(libasm) $(libebl) $(libdw) $(libelf) $(libeu) $(argp_LDADD Is there some reason to keep doing that? -

Re: [RFC PATCH 0/2] elfutils: don't use dlopen() for libebl modules

Hi - > Some of the binaries use libebl, and although libebl is linked into libdw.so, > the libebl symbols are not exported by libdw. So, libebl is linked in > statically for the binaries. > > This is why I suggested exporting those symbols from libdw.so. (I also > considered adding a libebl.so, b

Re: eu-dbgserver vs. valgrind --debuginfo-server=ipaddr:port

Hi, HP - > Hi. I attended FChE's debuginfo-server talk at the GNU Tools > Cauldron (nice meeting you there BTW). Yes, lovely! > I happened to re-read the valgrind manpage yesterday (grr: > --error-exitcode isn't the default) and stumbled upon a "new" > feature mentioned there: apparently valgri

patch 0/2 debuginfod submission

Hi - Aaron Merey and I would like to propose debuginfod for merge into elfutils mainline, after a couple of months of work. As a reminder, this is an http server (written in C++11) for debuginfo-related artifacts (elf/dwarf/source files), plus a C client library & command line tool. It comes wit

patch 1/2 debuginfod client

gned-off-by: Aaron Merey Signed-off-by: Frank Ch. Eigler --- ChangeLog | 6 + Makefile.am | 4 + config/Makefile.am | 2 +- config/libdebuginfod.pc.in | 12 + configur

Re: patch 0/2 debuginfod submission

Hi, Mark - > I only browsed through the code quickly, but I like what I see. > For now just a comment on the libdwfl integration. Righto. > It is guarded by ENABLE_DEBUGINFOD, which is off by default. > I think the support should always be enabled in libdwfl whether or not > the debuginfod ser

Re: patch 0/2 debuginfod submission

Hi - > Ah, I was not thinking that far yet. I was just worried about the > dlopen/dlsym dance being done on every call. Which does its own file > search to find the library. So simply setting debuginfod_so = (void *) > -1; on first failure to make sure dlopen/dlsym it is never called > again. Rev

patch 3/3 debuginfod client interruptability

-11-04 Frank Ch. Eigler + + * debuginfo-client.c (debuginfod_set_progressfn): New function + for progress/interrupt callback. + (debuginfod_clean_cache, debuginfod_query_server): Call it. + * debuginfo.h: Declare it. + * debuginfod_set_progressfn.3, *_find_debuginfo

patch 4 debuginfod: symlink following mode

From: "Frank Ch. Eigler" Date: Wed, 6 Nov 2019 18:53:31 -0500 Subject: [PATCH 1/2] debuginfod 4: symbolic link traversal mode In order to support file/rpm archives that are organized via symlink trees, add an "-L" option to debuginfod, meaning about the same as for

patch 5 debuginfod: prometheus metrics

From: "Frank Ch. Eigler" Date: Thu, 7 Nov 2019 04:00:16 -0500 Subject: [PATCH 2/2] debuginfod 5: add /metrics endpoint This webapi extensions allows admins to hook up debuginfod to a prometheus-compatible monitoring system for general situational statistics. The metrics are simple e

Re: patch 1/2 debuginfod client

Hi - > A few comments on the first (top-level) part, just to make progress. Thanks. > > diff --git a/config/libdebuginfod.pc.in b/config/libdebuginfod.pc.in > No Requires on libelf or libdw? Correct, the debuginfo client code does not call into elfutils. > My only concern is that these might

Re: patch 1/2 debuginfod client

Hi - > Hurrah! Documentation! Thanks. > > But given that all other documentation is under doc/ could you move it > there (guarded by DEBUGINFOD). It is just more consistent. If you leave > it in this subdir I think you should also move the existing > documentation files (and I think that is not w

Re: patch 1/2 debuginfod client

Hi - > > It'd be fractions of a second per configure run ... worth worrying > > about? > > Probably not, but if it is easy to hide after the check, why not do it? > Don't if it requires nasty trickery though. OK. > > > > +PKG_PROG_PKG_CONFIG > > > > +AC_ARG_ENABLE([debuginfod], AC_HELP_STRING([

Re: patch 1/2 debuginfod client

Hi - > [...libdw* debuginfod_find_* calls] > But given that they are almost similar, I would suggest to move both > into their own file sharing most of the code to do the dlopen dance. Where? It can't be in the solib. We're talking about sharing, what, two copies of three or four lines of code

Re: patch 2/2 debuginfod server etc.

Hi - > > +++ b/config/debuginfod.service > > +[Service] > > +Group=debuginfod > > +#CacheDirectory=debuginfod > > +ExecStart=/usr/bin/debuginfod -d /var/cache/debuginfod/debuginfod.sqlite > > -p $DEBUGINFOD_PORT $DEBUGINFOD_VERBOSE $DEBUGINFOD_PATHS > Why is CacheDirectory commented out, I canno

Re: patch 2/2 debuginfod server etc.

Hi - > Like with the client manpages, I think they should go into the doc/ dir > just because all manpages are there at the moment. OK. > > -bin_PROGRAMS = debuginfod-find > > +bin_PROGRAMS = debuginfod debuginfod-find > > +debuginfod_SOURCES = debuginfod.cxx > > +debuginfod_cxx_CXXFLAGS = -Wno-

Re: patch 5 debuginfod: prometheus metrics

Hi - > Could you also add a reference to the Prometheus Exposition format. I > see it is already in a comment in the code. Best to also add it as See > also in the docs. OK. > > +control. The \fI/metrics\fP webapi endpoint is probably not > > +appropriate for disclosure to the public. > > So,

Re: patch 4 debuginfod: symlink following mode

Hi - > > In order to support file/rpm archives that are organized via symlink > > trees, add an "-L" option to debuginfod, meaning about the same as for > > find(1) or ls(1): to traverse rather than ignore symlinks. > > Could you give an example of when exactly this is necessary? Because some fi

Re: patch 2/2 debuginfod server etc.

Hi - > And I don't like the pretty big testfiles, which aren't self-contained. > You have to fetch them from a remote koji server. It would be much > better to have a (small) self-contained .spec file that can be used to > generate the rpms. Frank is already working on that. Well, one did not h

Re: patch 2/2 debuginfod server etc.

Hi - > > +// Roll this identifier for every sqlite schema incompatiblity. > > +#define BUILDIDS "buildids9" > > + > > +#if SQLITE_VERSION_NUMBER >= 3008000 > > +#define WITHOUT_ROWID "without rowid" > > +#else > > +#define WITHOUT_ROWID "" > > +#endif > > + > > +static const char DEBUGINFOD_SQLITE

Re: patch 1/2 debuginfod client

Hi - > I was just thinking put them together in one file. .. or a header? > Otherwise, just add a comment in both that there is similar code in the > other file and if you update one, then you probably want to update the > other too. Did this for now. - FChE

Re: patch 1/2 debuginfod client

Hi - > It also seems that how you did it on the branch: Yeah, maybe a different automake version made it work after my earlier failing tests. (dead horse PS. It remains my opinion that we should commit auto* generated files into git.) > > Possible, but since these bits are just getting transcr

Re: patch 3/3 debuginfod client interruptability

Hi - > Attached is a variant that adds debuginfod_begin and debuginfo_end > (names matching elf/dwarf_begin/end) and adds a debuginfod_client > handle to each other function. Sure, if you like. Would you be sympathetic to supporting a client=NULL entrypoint to the lookup functions, ergo no begi

Re: patch 2/2 debuginfod server etc.

Hi - > Now that we have the metrics maybe we can poll those to see if the new > files have been indexed? Sort of indirectly. But then we're back to polling, which itself needs a timeout, so the logic is made at least as complicated. > The reason I am complaining about this, is that make check

Re: patch 5 debuginfod: prometheus metrics

Hi - > > > see it is already in a comment in the code. Best to also add it as See > > > also in the docs. > > > > OK. > > Thanks, that would be good. Done. > > > > +control. The \fI/metrics\fP webapi endpoint is probably not > > > > +appropriate for disclosure to the public. > > > > > > So,

Re: patch 2/2 debuginfod server etc.

Hi - > > I see where you're going with it, it's a reasonable concern. For now, > > we can consider it covered by the "debuginfod should be given > > trustworthy binaries" general rule. > > This does keep me slightly worried. Even "trustworthy binaries" could > be produced by buggy compilers. T

Re: patch 1/2 debuginfod client

Hi - > > > But since the user won't see the URL generated they might not notice > > > what is really going on. They will just see that something wasn't > > > found, won't they? > > > > Yes, so the only benefit would be the generation of a different error > > message for impossible buildids. > >

Re: patch 2/2 debuginfod server etc.

Hi - > > > This does keep me slightly worried. Even "trustworthy binaries" could > > > be produced by buggy compilers. > > > > Those would be untrustworthy binaries. > But then every binary could be untrustworthy :) If we have legitimate concerns about the correctness of toolchains that the bui

Re: patch 1/2 debuginfod client

Hi - > > Doing a redundant initialization later is not a problem; there is a > > counter in there. The problematic case would be > > - a multithreaded application > > - loading debuginfod.so multiply concurrently somehow > > - and calling the solib ctor concurrently somehow > > - and all of this

Re: patch 2/2 debuginfod server etc.

Hi - > [...] What I want is simply make it easy for the user to say where > they expect the sources are. So there is no surprises. If this were a mandate, it would be a hassle, for any build that's more than one directory wide. > > The -F mode is suitable for sharing build trees. By definitio

Re: patch 1/2 debuginfod client

Hi - On Tue, Nov 19, 2019 at 09:15:20PM +0100, Mark Wielaard wrote: > > That's what the doc says. What the code does, as far back as the year > > 2001, is have a static flag/counter in curl_global_init() that > > prevents multiple initialization. > > But the warning isn't about multiple initiali

Re: patch 2/2 debuginfod server etc.

Hi - > I am simply interested in knowing what is done for outgoing https > connections to be authenticated. What would it take to use the trust > roots for validating the server certificates? OK, I misunderstood. Certificate-authority certificates in the trust root (compiled-in directories) serv

Re: patch 1/2 debuginfod client

Hi - > But it isn't just about interference with other libcurl activity. If > you look at the curl_global_init code you see that it actually calls > a lot of code in other libraries. It is the curl_global_init code > that shouldn't be run in a multi-threaded environment. That it is > acceptable to

Re: patch 2/2 debuginfod server etc.

Hi - > It simply splits the paths into those scanned for rpms, those scanned > for files and (optional) paths that are extra trusted prefixes for > source files. The paths that are scanned for files are trusted source > prefixes by default. There is a new option to also remove those using > -N, --

Re: patch 2/2 debuginfod server etc.

Hi - > On irc you mentioned that you didn't like that -R and -F didn't take > wildcards. The attached makes it so that they now do (you do have to > escape them or put them in single quotes, so the shell doesn't expand > them first). I stopped using -R PATH and -F PATH because it was clear that d

Re: patch 2/2 debuginfod server etc.

Hi - > > If the perceived problem is that build tree scans (-F) may contain > > binaries that refer to source files that are not appropriate for > > later sharing, then IMO this is too much change, and unnecessarily > > complicates other valid usage. > > Yes, that (and references to any other sou

[patch pushed] debuginfod: Tweak groom cycle for memory freeing

Hi - After an irresistible sales job on irc, pushed to master: diff --git a/debuginfod/ChangeLog b/debuginfod/ChangeLog index a1d17b5f9a23..f37c85302886 100644 --- a/debuginfod/ChangeLog +++ b/debuginfod/ChangeLog @@ -1,3 +1,8 @@ +2019-11-25 Frank Ch. Eigler + + * debuginfod.cxx (groom

RFC: deb/ddeb support for debuginfod

o gravely offended by the preservation of the 'rpm' term that we must hide it. commit bb6a05faf5905e55f3289c70388b339113f843dd Author: Frank Ch. Eigler Date: Sat Nov 30 10:46:44 2019 -0500 deb/ddeb support prototype diff --git a/debuginfod/debuginfod.cxx b/debuginfod/debuginfo

RFCv2: debuginfod debian archive support

ot;-A" (any archive), because libarchive can recognize and unpack a large variety of formats. WDYT? This patch is also on the elfutils.git fche/debuginfod-deb branch. Author: Frank Ch. Eigler Date: Sat Nov 30 10:46:44 2019 -0500 debuginfod server: support .deb/.ddeb archives

rfc/patch: debuginfod client $DEBUGINFOD_PROGRESS env var

short, so bumped it to 30s. Signed-off-by: Frank Ch. Eigler diff --git a/debuginfod/ChangeLog b/debuginfod/ChangeLog index 8aa2944..a9483d0 100644 --- a/debuginfod/ChangeLog +++ b/debuginfod/ChangeLog @@ -1,3 +1,13 @@ +2019-12-04 Frank Ch. Eigler + + * debuginfod-client.c

Re: RFCv2: debuginfod debian archive support

an to merge this next week. commit 1d9ff81da0f5e1c7383b255c15529402035ad5bf Author: Frank Ch. Eigler Date: Fri Dec 6 16:08:50 2019 -0500 debuginfod: deb support, tests Using a synthetic .deb/.ddeb from a Ubuntu 18 machine, extend the debuginfod testsuite with some .deb proce

Re: RFCv2: debuginfod debian archive support

-- or upstream policy change, which is nothing to worry about. If you think separate metrics for .deb vs .rpm archives might be useful, can do. > Note that in some of the unpatches code there are still references to > rpms in some logs and comments that should also be "archive".

Re: rfc/patch: debuginfod client $DEBUGINFOD_PROGRESS env var

Hi - > > debuginfod: usability tweaks, incl. $DEBUGINFOD_PROGRESS client > > support > > > > This facility allows a default progress-printing function > > to be installed if the given environment variable is set. > > I like this idea but have a bit of a security concern about the

Re: rfc/patch: debuginfod client $DEBUGINFOD_PROGRESS env var

beb09f4aa0634e89cf3ed513c66abec6bc65009f Author: Frank Ch. Eigler Date: Fri Dec 13 11:51:37 2019 -0500 debuginfod client: progress notification v2 diff --git a/debuginfod/debuginfod-client.c b/debuginfod/debuginfod-client.c index 7a0a17519f42..55aab7b5b9a1 100644 --- a/debuginfod/debuginfod-client.c +++ b/debuginfod/debuginfod

Re: RFCv2: debuginfod debian archive support

deb) is not stored in the database, as this would break the current schema, and is really not needed. In any case, it's easily recovered for purpose of separate metrics. Following sur-patch added to fche/debuginfod-deb branch: commit 02694cd29672d6912569a4bfe03b703bc134a821 Author: Frank

Re: rfc/patch: debuginfod client $DEBUGINFOD_PROGRESS env var

Hi - > > That's not that serious a category of concern. Environment variables > > are not under control of untrusted agents. FWIW, $DEBUGINFOD_CACHE is > > considerably more dangerous in that regard (cache cleaning!). > > You have a way to make me even more scared of security issues than less >

Re: rfc/patch: debuginfod client $DEBUGINFOD_PROGRESS env var

Hi - > The code looks good in general, do note that if you rebase/squash to > onto master there is a slight conflict with the curl_res/curlm_res > fixlet. Since GCC10 isn't out yet, just yell if this gives you trouble > and I do/test it for you. I'll figure it out and merge. > [...] > I would a

Re: rfc/patch: debuginfod client $DEBUGINFOD_PROGRESS env var

Hi - > There is of course some i/o delay involved. But the majority of the > time is cpu bound because the file needs to be decompressed. > Not that it would help us now, but I wonder if it would be worth it to > look at parallel compression/decompression to speed things up. Yeah, maybe. > pick

PATCH: debuginfod: extracted-file cache

ndex cc4187bf0325..b56c2c158ae3 100644 --- a/config/ChangeLog +++ b/config/ChangeLog @@ -1,3 +1,7 @@ +2019-12-26 Frank Ch. Eigler + + * debuginfod.service: Set PrivateTmp=yes. + 2019-12-22 Frank Ch. Eigler * elfutils.spec.in (debuginfod): Add BuildRequire dpkg diff --git a/co

  1   2   3   4   >