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
[Bug debuginfod/30991] New: Bug 30010 - srcfiles tarball feature
https://sourceware.org/bugzilla/show_bug.cgi?id=30991 Bug ID: 30991 Summary: Bug 30010 - srcfiles tarball feature Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: halamour at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- Following the implementation of PR3, it may be useful to implement an addition that fetches all source files related to a program, places them in a tarball/zip and sends that to stdout. This may be done using srcfiles to fetch the source files, then libarchive to tarball. % eu-srcfiles --zip deadbeef > file.zip -- You are receiving this mail because: You are on the CC list for the bug.
Re: [PATCH] PR28204, debuginfod IMA
Hi Frank, On Thu, Sep 07, 2023 at 08:55:10AM -0400, Frank Ch. Eigler via Elfutils-devel wrote: > Here's a squashed/rebased version of the big IMA patch. I also > tweaked a few documentation oriented bits, and removed the > "ima:default" tag. Thanks. Sorry the reviews take so long. But it is a big concept and new code. Getting a good feeling for the concept and the code is hard. 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. > commit 4e45a08aee42958298a3fad6043cbf96243d13a5 (HEAD -> > users/fche/try-bz28204, origin/users/fche/try-bz28204) > Author: Ryan Goldberg > Date: Mon Aug 14 13:51:00 2023 -0400 > > debuginfod: PR28204 - RPM IMA per-file signature verification > > Recent versions of Fedora/RHEL include per-file cryptographic > signatures in RPMs, not just an overall RPM signature. This work > extends debuginfod client & server to extract, transfer, and verify > those signatures. These allow clients to assure users that the > downloaded files have not been corrupted since their original > packaging. Downloads that fail the test are rejected. It is not just corruption, since it is a cryptographic signature, it is also a proof that the files are what the distro actually packaged and distributes. > Clients may select a desired level of enforcement for sets of URLs in > the DEBUGINFOD_URLS by inserting special markers ahead of them: > > ima:ignore pay no attention to absence or presence of signatures > ima:permissive require signatures to be correct, but accept absent > signatures > ima:enforcingrequire every file to be correctly signed > > The default is ima:permissive mode, which allows signatures to > function like a checksum to detect accidental corruption, but accepts > operation in a mix of signed and unsigned packages & servers. I still think "permissive" is confusing. Since it is a term also used by e.g. selinux, but doesn't work that way. And it doesn't seem connected with the threat-model that enforcing protects against. Since it is a different concept maybe it shouldn't be part of this patch. It is a form of integrity checking, but doesn't protect (or warns) about integrity failures. As pointed out in another bug (#30978) if you want to do checking for (accidental) corruption of files you can also use the .gnu_debuglink CRC. Or maybe add this is a followup to this patch, adding an ima:checking and crc:checking marker (or maybe a generic checking marker that might do both)? > NB: debuginfod section queries are excluded from signature > verification at this time, and function as though ima:ignore were in > effect. imho this is odd. You either enforce the data produced by the server is certified, or it isn't. I understand that doing that for the section data is difficult because you effectively have to download and check the whole file. But it feels wrong to claim to enforce the signatures and then not do it. > IMA signatures are verified against a set of signing certificates. > These are normally published by distributions. A selection of such > certificates is included with the debuginfod client, but some system > directories are also searched. See $DEBUGINFOD_IMA_CERT_PATH. These > certificates are assumed trusted. Including default system directories seems fine. But I don't think elfutils should ship certificates itself. That is the job of the distro or user. We aren't in a position to make sure the certificates are valid and/or can be trusted. If we ship certificates we also need some mechanism to invalidate them if they get compromised. > > Signed-off-by: Ryan Goldberg > Signed-off-by: Frank Ch. Eigler > > diff --git a/ChangeLog b/ChangeLog > index 6aed95b6974e..b3b1a8ebc93a 100644 > --- a/ChangeLog > +++ b/ChangeLog > @@ -1,3 +1,9 @@ > +2023-08-14 Ryan Goldberg > + > + * configure.ac (ENABLE_IMA_VERIFICATION): Look for librpm, libimaevm > and libcrypto > + * (DEBUGINFOD_IMA_CERT_PATH): Default path for ima certificate > containing > + dirs. See also profile.*.in. > + > 2023-03-27 Di Chen > > * NEWS: Support readelf -Ds for using dynamic segment to Please feel free to move ChangeLog entries into the commit message. That might make rebases simpler. > diff --git a/config/ChangeLog b/config/ChangeLog > index ce1f74f621aa..30fc3deea09e 100644 > --- a/config/ChangeLog > +++ b/config/ChangeLog > @@ -1,3 +1,10 @@ > +2023-08-14 Ryan Goldberg > + > + * profile.csh.in: Set DEBUGINFOD_IMA_CERT_PATH directly. > + * profile.sh.in: Set DEBUGINFOD_IMA_CERT_PATH directly. > + * elfutils.spec.in: Add BuildRequires rpm-devel, > + ima-evm-utils-devel, openssl-devel, rpm-sign. > + > 2023-02-21 Mark Wielaard > > * eu.am (USE_AFTER_FREE3_WARNING): Define. > diff --git a/config/elfutils.spec.in
Re: PR30000 - introduce new srcfiles tool
Hi Housam,
On Thu, Sep 28, 2023 at 11:00 AM Housam Alamour via Elfutils-devel
wrote:
>
> Here is the new srcfiles tool ready for review.
Thanks for working on this.
I was not able to apply the patch from your email due to some line
breaks that your email client may have inserted. `git format-patch` and
`git send-email` are useful for emailing patches with the right format.
However I was able to test the patch using your try-pr3 git branch.
> diff --git a/doc/srcfiles.1 b/doc/srcfiles.1
> new file mode 100644
> index ..245c2d27
> --- /dev/null
> +++ b/doc/srcfiles.1
srcfile.1 does not install since it's missing from doc/Makefile.am.
> @@ -0,0 +1,125 @@
> +.\" Copyright 2023 Red Hat Inc.
> +.\" Mon 2023-Sept 23 Housam Alamour
> +.\" Contact elfutils-devel@sourceware.org to correct errors or typos.
> +.TH EU-SRCFILES 1 "2023-Sept-25" "elfutils"
> +
> +.de SAMPLE
> +.br
> +.RS 0
> +.nf
> +.nh
> +\fB
> +..
> +.de ESAMPLE
> +\fP
> +.hy
> +.fi
> +.RE
> +..
> +
> +.SH "NAME"
> +eu-srcfiles \- Lists the source files of a dwarf/elf file.
DWARF and ELF are usually capitalized.
> +
> +.SH "SYNOPSIS"
> +eu-srcfiles [\fB\-0\fR|\fB\-\-null\fR] [\fB\-c\fR|\fB\-\-cu\-only\fR]
> [\fB\-v\fR|\fB\-\-verbose\fR] INPUT
This description of the arg format differs from `eu-srcfiles --help`
$ eu-srcfiles --help
Usage: eu-srcfiles [OPTION...] [FILE]
[...]
The --help description implies that `eu-srcfiles ./prog` should work
for some executable named prog but this is not the case.
The man page is correct that I have to include -e or --core for this
to work and that '-e a.out' is used as a default file name.
> +
> +.SH "DESCRIPTION"
> +\fBeu-srcfiles\fR lists the source files of a given \s-1dwarf/elf\s0
> +file. This list is based on a search of the dwarf debuginfo, which
> +may be automatically fetched by debuginfod if applicable. The target
> +file may be an executable, a coredump, a process, or even the running
> +kernel. The default is the file 'a.out'. The source file names are
> +made unique and printed to standard output.
> +
> +.SH "OPTIONS"
> +The long and short forms of options, shown here as alternatives, are
> +equivalent.
> +
> +.SS "Input Options"
> +
> +Only one INPUT option may be used. The default is '-e a.out'.
There are some input options, such as -k, that are listed in --help but
not included in the man page.
> diff --git a/src/srcfiles.cxx b/src/srcfiles.cxx
> new file mode 100644
> index ..c948269d
> [...]
> +int
> +main (int argc, char *argv[])
> +{
> + int remaining;
> +
> + /* Parse and process arguments. This includes opening the modules. */
> + argp_children[0].argp = dwfl_standard_argp ();
> + argp_children[0].group = 1;
> +
> + Dwfl *dwfl = NULL;
> + (void) argp_parse (&argp, argc, argv, 0, &remaining, &dwfl);
> + assert (dwfl != NULL);
> + // Process all loaded modules - probably just one, except if -K or -p is
> used.
The use of /* */ and // for comments is inconsistent. Although to be
fair it's inconsistent in parts of elfutils too!
> diff --git a/tests/run-srcfiles-self.sh b/tests/run-srcfiles-self.sh
> new file mode 100755
> index ..075ff7d2
> --- /dev/null
> +++ b/tests/run-srcfiles-self.sh
> @@ -0,0 +1,45 @@
> +#! /bin/sh
> +# Copyright (C) 2023 Red Hat, Inc.
> +# This file is part of elfutils.
> +#
> +# This file is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License as published by
> +# the Free Software Foundation; either version 3 of the License, or
> +# (at your option) any later version.
> +#
> +# elfutils is distributed in the hope that it will be useful, but
> +# WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program. If not, see
