Resetting priorities against daemons inheriting nice'd properties
from rpm is a workaround needed only on legacy SysV init systems,
but in systemd era this is nothing but counter-productive. So make
the functionality optional by moving it into a plugin.
This probably breaks the testcase because now we'd somehow need to
determine from the testsuite whether the plugin will be loaded or not,
but since the test is only enabled as root ... maybe its not that big
a deal.
Historically we have only checked build_ids when __debug_package was
defined. So don't terminate the build if __debug_package is unset, even
when _missing_build_ids_terminate_build is. Only warn.
Signed-off-by: Mark Wielaard <mark@klomp.org>
commit e6bdf7 made it so that we don't give a warning or error message
for non-kernel ET_REL object files with missing or bad build-ids. But
we still (unintentionally) failed generateBuildIDs which made us skip
generating the cpioList causing an obscure failure message.
Move the sanity check earlier so we don't process such object files at
all. And if there is any real error from generateBuildIDs give a clear
error message and explicitly set processingFailed.
Signed-off-by: Mark Wielaard <mark@klomp.org>
Only loadable ELF images (executables, shared libraries, kernel modules)
should have build-ids. So don't warn or error out when an object file is
found without one.
Signed-off-by: Mark Wielaard <mark@klomp.org>
As in, honor --nodigest for the new compressed payload digest too.
There's now _RPMVSF_NOPAYLOAD and RPMVSF_NOPAYLOAD meaning entirely
different things, there might be some confusion on the road ahead.
Better names for these things would be welcome...
Should've really been in commit daeb53bae7.
As a part of modernizing the crypto used by rpm, it's way past time
to use a stronger algorithm for the file digests. The jump from MD5
is not entirely smooth but at least Fedora and RHEL did that ages ago
and survived, others should too. And of course you can always flip
it back to MD5 if you really need to, for eg building packages for
ancient distro versions.
SHA1 has been getting a bit long in the tooth for many years by now,
add a more modern digest to eventually supplant it, for now just
prefer SHA256 over SHA1 if present when verifying. Using a hardwired
algorithm instead of configurable one to keep things on the simple
side when dealing with the signature header.
Signing could add the new digest for older packages but we don't do
that to avoid surprises when people are signing older packages.
There's no point comparing the weaker MD5 for equivalence when we
can determine it by looking at a stronger digest already. Also we
don't need the digest lengths here since SHA1 is ascii anyway.
This too is quite a fundamental change for macros: up to now, arguments
to parametric macros have not been expanded. It doesn't sound so bad
until you consider something like the case in RhBug:1397209:
%global rev 133
...
%setup %{?rev:-c}
%autosetup %{?rev:-c}
One would expect %setup and %autosetup behave the same when you replace
one with the other, but no. %setup gets "called" with -c, %autosetup
does not. Instead %autosetup receives a completely useless, literal
"%{?rev:-c}" as its argument. That's just brain-meltingly non-sensical.
This certainly has the potential to break advanced macro constructs,
but OTOH what breaks might well be only written that way in order to
work around the former behavior.
There are some funny subtleties involved as the argument expansion
must occur in the callers scope, ie before we create any of the
automatic macros. For example, Fedora's font packages break if only
this or the macro scope visibility enforcement is applied but start
working again once both are present.
When a parametric macro "calls" another parametric macro with fewer
arguments than it received, the inner macro would see the %<n>
macros of the outer call which is an obvious scoping violation
and quirky behavior, making macro writing harder than it needs be.
Similar scoping issues exist for manually defined macros but those
have further complications (because of %undefine semantics) that we
sheepishly avoid here by limiting the visibility enforcing to automatic
macros only (for now at least).
This changes the macro scoping rules quite fundamentally: macro
definitions are local to the parametric macro they were defined in,
and everything else is global. Among other things, this makes this
common spec idiom (RhBug:552944, RhBug:551971 etc) behave
deterministically because "foo" is placed into global scope:
%{?!foo: %define foo bar}
In theory it's certainly possible that this breaks somebodys carefully
crafted advanced macros but it seems quite unlikely, considering how
broken the alleged block-scoping has been. OTOH for macros defined
within parametric macros, nothing actually changes as that scoping has
always been enforced by rpm. The non-global define tracking is also
no longer needed for emitting warnings, because the case where it
was needed simply no longer exists.
Note that macro recursion depth is a different thing and still needs
to be tracked separately.
Since we actually setup all the same automatic macros whether there
are arguments or not, doing it centrally only makes sense. Shuffle
things around a bit in preparation for the next steps.
In some testcases we extract the BuildID with the file command.
Unfortunately the file command output changed slightly between versions.
Make the sed regexp more strict by only matching a hex-string.
Also properly "escape" [ and ] which inside an AT_CHECK should be [[ and ]].
Tested against file versions 5.11, 5.29 and 5.30.
Signed-off-by: Mark Wielaard <mark@klomp.org>
Commit bbfe1f8 (Add build-id links to rpm for all ELF files) and
Commit 5ef1166 (Make it possible to have unique build-ids across build
versions/releases)
Introduced new test spec files (hello-r2.spec, hello2cp.spec and
hello2ln.spec). Make sure they are added to EXTRA_DIST so the testcases
pass again with make distcheck.
Signed-off-by: Mark Wielaard <mark@klomp.org>
Introduce a new macro _unique_debug_srcs that when set will pass
--unique-debug-src-base "%{name}" to find-debuginfo.sh which will
move sources into a unique "<name>-<ver>-<rel>.<arch>" directory
under /usr/src/debug/ and makes debugedit rewrite the source paths
in the debuginfo to use that unique directory name.
Traditionally the debug src dir was named after the builddir which
was defined through the %setup macro which used the -n name argument
to define the builddir name and source archive to use. The builddir
might not be unique though between package versions.
Now that debugedit doesn't have strict base and dest dir length
restrictions for rewriting the source dir paths this can now be made
more flexible.
The added testcases show the difference between the old and new way.
The hello2.spec file defines the name of the package as hello2, but
uses the %setup marcro with -n hello-1.0 to use the hello-1.0.tar.gz
archive. This would traditionally result in a hello-1.0 builddir
which would be moved under /usr/src/debug. Possibly conflicting
with any other package (version) that used the same builddir name.
When defining _unique_debug_srcs to 1 that builddir will be moved
to <name>-<ver>-<rel>.<arch> instead (hello2-1.0-1.<arch>).
The testcases check that both the actual package source filess under
/usr/debug/src/ and the source paths as found in the .debug files are
under the traditional or new unique directory names depending on whether
the new _unique_debug_srcs macro is defined.
Signed-off-by: Mark Wielaard <mark@klomp.org>
debugedit --base to --dest rewriting of debug source file paths only
supported dest paths that were smaller or equal than the base path
(and the size should differ more than 1 character for correct debug lines).
All paths were changed "in place". Which could in theory mess up debug str
sharing.
This rewrite supports base and dest strings of any size (some limitations,
see below). This is done by reconstructing the debug_str and debug_line
tables and updating the references in the debug_info attributes pointing
to these tables. Plus, if necessary (only for ET_REL kernel modules),
updating any relocations for the debug_info and debug_line sections.
This has the nice benefit of merging any duplicate strings in the
debug_str table which might resulting on slightly smaller files.
kernel modules are ET_REL files that often contain a lot of duplicate
strings.
The rewrite uses elfutils (either libebl or libdw) to reconstruct the
debug_str table. Since we are changing some section sizes now we cannot
just use mmap and rawdata to poke the values, but need to read in and
write out the changed sections. This does take a bit more memory because
we now also need to keep track of all string/line references.
There are still some limitations (already in the original debugedit)
not fixed by this rewrite:
- DW_AT_comp_dir in .debug_info using DW_FORM_string can not be made
larger. We only warn about that now instead of failing. The only
producer of DW_FORM_string comp_dirs is binutils gas. It seems simpler
to fix gas than to try to support resizing the debug_info section.
- A DW_AT_name on a DW_TAG_compile_unit is only rewritten for DW_FORM_strp
not for DW_FORM_string. Probably no problem in practice since this
wasn't supported originally either.
- The debug_line program isn't scanned for DW_LNE_define_file which
could in theory define an absolute path that might need rewriting.
Again probably not a problem because this wasn't supported before
and there are no know producers for this construct.
To support the upcoming DWARFv5 in gcc 7 (not on by default), we will
need to add support for the new debug_line format and scan the new
debug_macro section that can have references to the debug_str table.
Signed-off-by: Mark Wielaard <mark@klomp.org>
Internal public API is quite an oxymoron, but surely these are not
the modules one needs to encounter first when coming to librpm.
Lump the stuff under IO, burying it last. Also gets rid of a
doxygen warning during generation wrt internalargv.
This is a bit wacky because the payload digest is not a part of the
signature header like everything else in "signature" checking, but
people are going to expect "rpm -K" to detect corrupted payload so
we better do it there anyway. We better do it during installation too
but that's another story.
It also takes a shortcut wrt the payload digest algorithm which is
supposed to be configurable and should be retrieved from
RPMTAG_PAYLOADDIGESTALGO, but as its currently hardwired to SHA256
on the build-side too it doesn't really matter ATM.
This should/could've been in commit 2b456b22f1
already, prior to that it was possible another sig/dig item was using
the same hash and nuking it would've messed up something else.
There needs to be a way to verify the payload before trying to uncompress
and unpack it:
- We have digests on the contents of individual files, but detecting
corruption in middle of installation, after all sorts of scripts might
have already run, is no good at all
- Compresssion libraries have vulnerabilities of their own
- The RPMv3 digest covering the payload is the obsolete MD5, and furthermore
it covers the header AND the payload, which is extremely cumbersome
to begin with but also vulnerable because it's in the unprotected
signature header.
This adds two tags: one for the actual digest, and another for the
algorithm, much like with filedigests. The digest tag is specified
as a string array to leave room for future expansion: the idea is
that there could be intermediate snapshots over the payload, and
the last one is always on the entire payload, so an array of just
one is compatible with this specification.
Getting the digest into the main header is fairly complicated since the
package format on-disk is exactly in the opposite order of how we need
to write things there, add a lenghty comment to writeRPM() to explain.
The MD5 digest needs to die, really - it forces a second read over
the entire header + payload for what is practically worthless hash.
Note that there's no code to actually verify this digest at the moment,
nor is there a way to configure the used algorithm, SHA256 is used as the
default for now.
Process header and payload as separate entities when reading through
the newly created package for digest calculation. This consolidates
the digest calculations to one place and hopefully makes the overall
logic that little bit clearer too. In order to do this we need more
control than "Fread() to the end", add another helper to handle
jumping around + reading specified ranges.
Not supposed to affect functionality except for a slight change in
an error message nobody ever sees, this is still preliminaries for
things to come.
Hide away the dirty details of header reload and writing into
a helper function. This may seem excessive at this point but
we'll need this later. No functional changes except for a nicer
error message if writing the fails.
AFAICT the only place that even remotely cares about the reload
is rpmdb rebuild, for others this just messes up things. Do the
reload manually in rpmdb and otherwise just leave it alone. This
allows headerCopy() to actually be used for, you know, copying
headers. Generally, that is.
The refcounting and freeing seem rather suspicious, has probably
been broken for ages. As if anybody knew such an argument exists,
never mind what it might do or when it might be necessary. Should
this really be necessary, it would have to be automatic, and it'd
be almost 20 years too late for that...
Having a couple of hardcoded sets of zeros is not so bad but this
is not sustainable route when adding more and configurable digests.
Instead create an actual digest of the requested type. The value
is not zeros but then those zeroes were only ever used as placeholders.
sigTarget is a bit misleading as there are various different "signatures"
we're dealing with here, on different ranges of the package. Using
the actual section names should make it clearer what everything really is.
Using the FLGS tags is awkward and inconsistent with other part of the code
routinly use the NAME tags to denominate the type of dependencies.
This is also going to make using parseRCPOT() easier for the rpmfc code
that is also based on NAME tags.
The missing space style-error has been recently coming common enough
somebody might think that IS the expected style, its not. Some of these
are actually very old, but fix across the board for consistency..
Strictly white-space only change.
Assume failure and only update the rc just before exit to remove
a whole pile of unnecessary assignments. Also remove the totally
unhelpful "bad csa data" error message , let it fail in cpio_doio()
instead with a nicer message.
There's never been an MD5 on the header, and never will for obvious
reasons. Also there's never been an SHA1 on the header+payload, and
never will either.
Remove unused junk, freeing a couple of bits along the way. Also
drop incorrect "unimplemented" comment from RPMVSF_NORSAHEADER,
RSA header signatures have been supported for .. ever by now.
No functionality affected by any of this.
Florian Festi