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
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
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=2019-q1=67ff4de2-fd5a-0ba8-0b5d-173c5619a88b%40qt.io
That could be because of sourceware's
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
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
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?
-
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,
-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
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
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.
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],
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
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
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
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,
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
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
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
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
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
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
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 sim
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.
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
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
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,
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
tream 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".
OK, will
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
(rpm vs 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 Ch.
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
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 processing
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
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
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)
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
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/debuginfod.cxx
index aa7ffcf..851d0bd 100644
; (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
Add suppor
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
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
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
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
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 =
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
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.
>
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
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
Hi -
> > I think it has a chance to be useful to other clients too, for example
> > for other proxy / authentication schemes. And given that there is a
> > shared library boundary, private APIs aren't in easy reach.
> > "separately" as in separate commits? ... I suppose, if it really
> >
/fche/pr25375)
Author: Frank Ch. Eigler
Date: Sat Jan 25 18:43:07 2020 -0500
PR25375: fdcache prefetching to reduce repeated archive decompression
diff --git a/debuginfod/debuginfod.cxx b/debuginfod/debuginfod.cxx
index 0acd70e4a916..7f432d7d9c41 100644
--- a/debuginfod/debuginfod.cxx
+++ b
Hi -
> > This latter is a bit long and should probably be abbreviated, wdyt?
>
> Might want to abbrev the build-id part to /81..aa/. The interesting
> part is which server is used imho.
Yeah, OK.
> > +/* Add an outgoing HTTP request "Header: Value". Copies string. */
> > +int
Hi -
> > + fdcache_prefetch = 64; // guesstimate storage is this much less costly
> > than re-decompression
> > + fdcache_fds = (concurrency + fdcache_prefetch) * 2;
>
> Here fdcache_prefetch is set and used before argp_parse () is called,
> which would set it to the user supplied value (if
be abbreviated, wdyt?
I'd start reviewing this from the debuginfod.h header file outward.
commit 4ace515d6b9ce92ea4a808eba4d608851ee9b56d (fche/pr25369)
Author: Frank Ch. Eigler
Date: Mon Feb 24 22:23:55 2020 -0500
PR25369: client api extensions, progress prettying
This batch of changes
Hi, Arjan -
> > clear-linuxelfutils
> >
> > indexed by filenameby buildid
> actually the clear side provides both build id and filename, the
> tools on the client (gdb and the like) try buildid
Hi -
A little extension lets us process arch-linux archives. Awaiting
for some small test .pkg's from the arch folks for the elfutils
testsuite. However, hand-testing on severa larger files works!
commit b51ae89befeb81c8b51b15b7168c6e616255b486 (fche/pacman-Z)
Author: Frank Ch. Eigler
Date
Hi -
Committed as obvious, after observing test failures on some VMs.
commit b260496cedbdec7615b01a5634fb416c18733a11 (HEAD -> master)
Author: Frank Ch. Eigler
Date: Mon Feb 3 14:11:53 2020 -0500
debuginfod test: assert curl & rpm2cpio during test prologue
On debian &
Hi -
> I really like how simple adding this feature is. Shows the design for
> adding new formats was done with some foresight.
Thanks!
> [...] I think it would be better if you could simply leave off the
> conversion CMD and just provide an EXT (without =). This would then
> just pass the
Hi -
> Yes, lets make =CMD optional. But why assume "cat"? Can't you then
> simply use fopen instaed of popen in the code to get the FILE* to pass
> to archive_read_open_FILE? Or even just open and archive_read_open_fd?
Sounds like a plan.
- FChE
Hi -
> Yes, lets make =CMD optional. But why assume "cat"? Can't you then
> simply use fopen instaed of popen in the code to get the FILE* to pass
> to archive_read_open_FILE? Or even just open and archive_read_open_fd?
One reason: the defer_dtor<>-based auto-closing of these objects is
Hi -
> My C++ is pretty terrible, but couldn't you handle that with something
> like:
Ah, yes, good eye, pclose and fclose are interchangeable function
pointers. (close(2) along the lines of your other suggestion wouldn't
be.)
- FChE
Hi -
> > My C++ is pretty terrible, but couldn't you handle that with something
> > like:
>
> Ah, yes, good eye, pclose and fclose are interchangeable function
> pointers. (close(2) along the lines of your other suggestion wouldn't
> be.)
pushed to master, with another instance of this
Hi -
> A debuginfod optimization, including docs & tests.
> Also on fche/debuginfod-fd-cache branch in git.
merged and pushed to master
This exhausts my pending patches for debuginfod, whew, with other
future work also to be tracked via elfutils bugzilla.
- FChE
Hi -
> This patch dramatically improves concurrency during scanning multiple
> and/or large directories, and thus speeds up file/archive scanning.
merged to master
- FChE
34e67018914cf9ebbef07065965755b6554fd66e (HEAD -> master,
origin/fche/debuginfod-PR25394)
Author: Frank Ch. Eigler
Date: Sun Jan 19 20:33:32 2020 -0500
PR25394: debuginfod mutex between grooming and scanning
Extended the work-queue concept with "idlers" - other threads that
block on the wor
Hi -
Pushed as trivial:
commit c406e5d82700cf87db8eae1f642b3c453b174372 (HEAD -> master)
Author: Frank Ch. Eigler
Date: Wed Jan 22 15:27:59 2020 -0500
debuginfod: diagnostics verbosity tweak
marxin reported "skipping hat= empty comp_dir" messages
we
Hi -
Committed the following patch. I anticipate occasional
updates to it as more debuginfod servers and clients come
on line.
commit cf7234fe3f95a99104f4a7e8956986c252fe0243 (HEAD -> master)
Author: Frank Ch. Eigler
Date: Wed Jan 22 12:00:59 2020 -0500
add debuginfod page
diff --
Hi -
> > > We do want a reproducible build.
> >
> > Can you give an example? Bootstrapping a new distro version/arch?
>
> Probably best explained at https://reproducible-builds.org/ most
> distributions are participating.
(I understood that part, just not how you thought build-time literals
Hi -
> Eep. We really should pick up this info during runtime instead of
> during build time.
That's what I thought at first too. However, doing it at run time
means doing work - a popen() etc. - over and over or saving in a
locked global. Since on a normal machine, the distro doesn't change
Hi -
Pushed as obvious:
elfutils.spec: dependency typo fix
Commit da0959cafda4 introduced a dependency on "debuginfod-client",
whereas it's really "elfutils-debuginfod-client".
Signed-off-by: Frank Ch. Eigler
diff --git a/config/elfut
Hi -
> > That suggests one timeout could be sufficient - the progress timeout
> > you the one you found - just not too short and not too fast.
>
> How about the attached (untested) patch?
That looks good, though I'd bump up the 60s -> 120s to give it a big
margin over already-observed
.
git diff -w follows:
commit b225b73266a068afa87ac06858c81688f0c00ea3 (HEAD -> fche/debuginfod-workq,
origin/fche/debuginfod-workq)
Author: Frank Ch. Eigler
Date: Tue Dec 31 20:06:30 2019 -0500
debuginfod: rework threading model for file/archive scanning
We switch from a thread
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
Hi -
commit 53aac40e9577168b886dfeecb77e5a72d2666fc9 (HEAD ->
fche/debuginfod-useragent, origin/fche/debuginfod-useragent)
Author: Frank Ch. Eigler
Date: Mon Jan 6 04:29:21 2020 -0500
debuginfod: pass a distro-summary User-Agent request header
It may be useful for a debugin
Hi -
> Should this add quoting to make the field boundaries unforgeable?
I'm thinking of adding a second output stream later on, for machine
consumption, with that info carefully quoted.
- FChE
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,
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
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
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
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,
/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 webapi, C
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
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
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
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:
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
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 arch
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
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
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
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
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.
>
>
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
d_globbed_koji_filepath): New function.
+ * (parse_opt): New flag --koji-sigcache.
+ * debuginfod-client.c (debuginfod_query_server): Added policy for
+ validating IMA signatures
+ * (debuginfod_validate_imasig): New function.
+ * debuginfod.h.in: Added DEBUGINFOD_I
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
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
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
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)
d.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 --git
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 branch.
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
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
1 - 100 of 341 matches
Mail list logo
