Once upon a time there may have been a point to having the extension in a
separate convenience library, but nowdays with Lua being mandatory there's
not a whole lot of point in complicating the build with all this fubar.
As a nice little bonus, we can now hide luaopen_posix() symbol.
Traditionally, %setup processing has figured out the commands needed
to extract the source in question. The problem with this is that it
happens at spec parse time, requiring access to sources that may not
even be there in plain spec queries.
Move the unpack logic from %setup internals to an `rpmuncompress` helper
executable which is now the only command %setup needs to know. This way,
spec parsing never needs to look at the actual source files, their
presence is only required for an actual build. Another advantage is
that the extraction machinery is now available to packagers without having
to call %setup with its side-effects on %buildsubdir and such.
Split the rpmbuild -ba test on missing sources into separate -bb and -bs
tests as these are now rather different: binary build only tests for
source presence if %prep is actually executed, and missing files
at source build stage are discovered at a later stage as well.
Remove include preinstall machinery leftovers preventing them from
getting pulled to dist tarballs. Regression introduced in commit
650ba79f22.
Strange that this wasn't caught by distcheck.
Introduced back in 2007 in 5831404601 the
point was to fake up a sane public header structure with minimal
internal disruption, TEMPORARILY. I think 15 years is temporary enough.
The machinery has worked rather well for what it is, but having the
headers appear in multiple locations is weird and confusing to people,
plus this "physical" separation makes it far more clearer what is
a public header and what isn't.
These APIs never belonged to rpmpgp.h anyway, it was only used for
being the least-worst fit within rpm. As if it was so hard to just
add a new header...
Handy for debugging and experimenting with macros, in and out of
spec context.
Placed in rpmspec because we don't want readline dependency on main rpm
executable, this is more of a packager tool anyway.
We don't want readline dependency in librpmio so need to do this the
hard way: add an optional callback through which rpmlua can supply
it's own readline-aware callback function.
Being able to run stuff easily in rpm context helps developing and debugging
scriptlets and macros too. Supports running one-liner statements from
the cli, regular scripts and an interactive session.
This is placed into a separate executable for, well, separation and
simplicity, but it'll also give us means to link to readline without
dragging that to main rpm dependencies (but that's left for later).
There's been an increasing interest in the wider community to use
the debuginfo tooling outside rpm context, and deep ELF format
internals are not rpm's core business anyhow, the reasons for it
being here are entirely historical. So without further ado, remove
the debuginfo tooling from rpm and rely on the external debugedit
project from now on.
Update INSTALL to document the new dependency, and add conditionals
to relevant debuginfo build tests. The lower-level debugedit and
sepdebugcrcfix tools are tested in the external project, no need
to duplicate that here.
More and more macros, scriptlets and other functionality has been getting
built around Lua, to the point that it has in practice been required for
several years now.
Maintaining the pretense of being optional comes at a cost in holding
back developments and having to check for that theoretical special
case. Lets make it a hard requirement and embrace it some more!
Back in 2013, the Berkeley DB license was changed in a way that prevented
most of open-source world to go along, rpm was no different. We now have
other options and a standalone migration path from BDB for those that
haven't yet done so.
Whatever else might be said about this partnership, it has been a long one.
Now's the time to part ways.
Fapolicyd (File Access Policy Daemon) implements application whitelisting
to decide file access rights. Applications that are known via a reputation
source are allowed access while unknown applications are not.
The rpm plugin allows us to use rpm database as a source of trust.
We used dnf plugin since the beggining but it only provides notification
when transaction ends. With "integrity checking" requirement we need
a continual addition of files which are installed during the system
update. With fapolicyd rpm plugin we can allow using of recently
added/updated files in scriptlets during rpm transaction.
The fapolicyd plugin gathers metadata of currently installed files.
It sends the information about files and about ongoing rpm transaction
to the fapolicyd daemon. The information is written to Linux pipe which
is placed in /var/run/fapolicyd/fapolicyd.fifo.
The data format is "%s %lu %64s\n". [path, size, sha256]
The fapolicyd rpm plugin can be enabled with "--with-fapolicyd"
configure option.
Related PRs:
https://github.com/linux-application-whitelisting/fapolicyd/pull/105https://github.com/linux-application-whitelisting/fapolicyd/pull/106
Signed-off-by: Radovan Sroka <rsroka@redhat.com>
NSS is a behemoth of a library which drags in a whole runtime subsystem
of its own which is often at odds with normal Unix system behavior
(hello SIGPIPE). Now that we have nicer alternatives available there's
little reason to lug this baggage along. NSS was deprecated in rpm 4.16
(commit 0b9efb93fb).
Adding a new header just for this seems a bit much but we'll be adding
stuff there shortly.
No functional changes as such, this is prerequisite for supporting
version comparison in expressions.
distcheck target depends on having the html docs present, but the paths
in make targets disagree. Hook it on the directory instead to allow
distcheck to work without requiring an extra compilation step before it.
libgcrypt is a much more straightforward and lightweight as a library,
doesn't come with a massive runtime library of its own, runtime which
messes with SIGPIPE and all, has a nice clearly compatible license (LGPL)
and is somewhat faster than NSS. What's not to like?
Change the default and add relevant documentation to INSTALL. Drop
the hopefully now unnecessary override from distcheck flags, and
switch CI over too. Note that in CI, openssl-devel is still needed
for ima-evm (missing dep in ima-evm-utils-devel?)
Replace the --with-external-db switch with the following simple logic:
if internal copy of BDB is detected, use it, otherwise look for an
external one. By default BDB is still required, but it's now possible
to build without it by using --disable-bdb argument to configure.
If no database is built in, we'll segfault for now, to be dealt with
in coming commits.
This is a rather historical moment, BTW.
LUA_PATH global variable is not consulted when loading libraries in
Lua >= 5.1, package.path has replaced it. Rpm's Lua library path
was always supposed to be /usr/lib/rpm/lua/ but this has been broken
for the last ten years or so, oops. Make the directory a first-class
citizen: create it on install, add a macro for it, make it actually
work and ensure it stays that way by adding a test for it.
rpmVerifyFlags are only relevant for the cli-oriented API's,
it makes no sense to have a separate header file just for these.
Back then the idea was to create additional APIs around verify
which would've kinda warranted a header of its own but that never
happened (for our purposes circa 10 years is close enough to forever)
The test-suite fails if python is not enabled. An alternative solution
could be disabling python tests when not enabled, but the python
tests cover things that are not covered elsewhere so especially
for dist cutting the tests are quite important.
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>
Autotools: add --with-crypto=openssl
This enables RPM to locate the appropriate flags for compiling
against OpenSSL for digest and hash functions.
This implementation changes the old behavior of
--with[out]-beecrypt toggling between beecrypt and nss. It will
now throw an error if attempting to use --with-beecrypt
indicating that the user should instead use --with-crypto=
See also:
https://github.com/rpm-software-management/rpm/issues/119
Doxygen >= 1.8.8 skips files with unknown (or missing) extension,
whereas previously they were assumed C-like. Rename the Doxyheader
files to Doxyheader.h to keep the C-association, adjust makefiles.
Thanks to Pavlina Varekova for chasing this down!
Trying to include AM_CFLAGS through a configure generated rpm.am file
doesn't really work because at the time automake runs configure doesn't
exist yet to process rpm.am.in. Just define the AM_CFLAGS substitution
inside the Makefile.am files themselves.
Rename rpm.am.in back to rpm.am.
Signed-off-by: Mark Wielaard <mjw@redhat.com>
Let rpm go into $(bindir) along with everything else, it just isn't
that special. Many distros are nowadays symlinkingbin to usr/bin anyway
which makes the special casing of /bin/rpm even more silly.
Somebody wants to put it someplace else, 'mv' is your friend and
I'm not going to stop you.
ChangeLog is listed as EXTRA_DIST but there's no rule to create it
so dist target is broken except when invoked with Makefile.maint. Which
nobody finds because its such a strange thing to have.
Move back ChangeLog generation into main Makefile.am but do not
require git to create it. Instead have a rule to create an empty
file to appease EXTRA_DIST no matter what, and only create the
real thing if we're in a git checkout and git command is present.
It's been deprecated and hidden behind compat defines for eight
years now, more than enough time for folks to port their stuff
to new APIs. If they ain't done by now ... well its time now.
Some old tools might still use the .gnu_debuglink section to find
separate debuginfo files instead of build-id style lookups. When
dwz has compresses the .debug files the original CRC in the main
ELF file will no longer match. Make sure to run sepdebugcrcfix
after dwz to recalculate the CRC.
The original fix was created by Jan Kratochvil based on code
from GNU binutils BFD. https://bugzilla.redhat.com/show_bug.cgi?id=971119
I added a testcase to make sure the CRCs were all correctly
updated after dwz has run to compress a debuginfo package.
And a change (plus testcase) to make sure implicit suid binaries
didn't accidentially got their suid flag bit.
Signed-off-by: Mark Wielaard <mjw@redhat.com>
Support for minisymtab (a minimal function symbol table in a compressed
section in the main binary) has been in gdb and elfutils based tools
since some years. Fedora has had this as rpm-4.10.0-minidebuginfo.patch
since 2012.
The patch adjusts macros to pass -m to find-debuginfo.sh when
_include_minidebuginfo has been set. find-debuginfo.sh now takes -m
as argument to generate the .gnu_debugdata ELF section to be added
to the main executable.
To support the testcases a new macros.debug is added that is used to
generate debuginfo packages in the rpmbuild.at testsuite.
The original support was added to Fedora rpm by Alexander Larsson.
Lubos Kardos fixed a bug in it when strip -g was used. I added some
configuration macros and two testcases to check the basic support works
and for the strip -g bug.
Signed-off-by: Mark Wielaard <mjw@redhat.com>
rpmquery and rpmverify are symlinks to rpm. The former are usually
installed in /usr/bin, the latter in /bin, so the symlink points to
../../bin/rpm. But for installations into other prefixes, the synlimk
should just point to the same directory.
Panu Matilainen