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.
- These platform specific scripts haven't been properly maintained
in over ten years, its way past time to get rid of these scripts
that forever confuse packagers as they assume these are actually
being used for something.
- Sure there's theoretical portability loss here, but judging by the
number of updates to these platforms over the last 10+ years... its
indeed theoretical. Any such portability issues just need to be
brought into the world of the "internal" dependency generator finally.
- Replace platform specific find-{requires,provides} scripts with
trivial wrapper scripts that just call rpmdeps with suitable
arguments. This way the generated dependencies using the legacy
external dependency are at least roughly on par with the internal
depgen as, well, they're generated by the same thing.
- Changing from find-{requires,provides} scripts to rpmdeps could
be done by just changing __find_{requires,provides} macros, but
a lot of packages directly refer to the scripts instead so this
way we cover far more ground and in an backwards compatible way.
This is needed as the new payload format for large files is not compatible with
rpm2cpio which basically just dumps the payload which happened to be cpio.
Use configure parameter --without-archive to not build this tool and get rid of the libarchive requirement.
- Preparation for making the indexed rpmfiles API public, API users
are not affected as rpmfiles.h is included from rpmfi.h now. rpmfi.h
is for the iterator part only.
- Autoconf leaves things like @localstatedir@ unexpanded at build-time
on purpose so the paths can be overridden during "make install".
However this leaves %{_var} in macros in its unexpanded state
unless --localstatedir is explicitly passed in, which does not
work very well for rpm.
- Process the main macros file through the same meat grinder as
the platform macros. Ugly as sin but... it brings the casual
"./configure; make; make check" sequence much closer to working.
- The pool stores "arbitrary" number of strings in a space-efficient
manner, with near constant (hashed) string -> id lookup/store and
constant time id -> string and id -> string length lookups.
- Credits for the idea go to the Suse developers working on libsolv,
the basic concept is directly lifted from there but details
differ due to using rpm's own hash table implementation etc.
Another minor difference is using size_t for offsets to permit over
4GB total data size on 64bit systems, the total number of id's in
the pool is limited to uint32 max however (like in libsolv).
- Any (re)implementation bugs by yours truly, this is almost certainly
going to need further tuning and tweaking, API and otherwise.
- Base64 is present in headers and all, it's only reasonable that
our API users have access to this functionality without having
to link to other libraries. Even if we didn't want to carry the
implementation forever in our codebase, we should provide a wrapping
for this (much like the other crypto stuff) for the reason stated above.
- A bigger issue is that our dirty little (badly hidden) secret was using
non-namespaced function names, clashing with at least beecrypt. And we
couldn't have made these internal-only symbols even on platforms that
support it, because they are used all over the place outside rpmio.
So... rename the b64 functions to rpmLikeNamingStyle and make 'em public.
No functional changes, just trivial renaming despite touching numerous
places.
- It contains piles of buffer overflow etc material and AFAIK this
has been unused for its entire lifespan of > 10 years, fixing
an unused piece of code seems like a waste of time. If somebody
shows interest later on it can be resurrected, but in the meanwhile...
- We'll probably want to make some changes to the plugin type system
before considered "ready", the current plugin slots are limited
to 32 and Meego folks apparently want to use a largish number
of slots. So we might want something like separate plugin type
(collection, security... etc) and then have 32 slots per each type.
Making this private for now to avoid having to potentially break
the API shortly after introduction.
- Dealing with the inevitable fallout and popt-foo needs more time
to handle, revert to the rpm 4.6-4.8 setup where rpmquery and rpmverify
are just symlinks to /bin/rpm, allowing especially query aliases
to work. Releasing an intermediate version where 'rpmquery --requires'
and the like dont work would do nothing but hurt the future intention
of splitting these things up for real.
- This effectively reverts commit 26125015e4
- Installing/erasing packages, querying and verifying require different
amount of privileges on the system. Having separate binaries for
these functionalities permits limiting the capabilities through
SELinux and other similar security mechanisms: for example quering
needs much less privileges than installing.
- For now, leaving /bin/rpm to be the Swiss Army knife it
always was: capable of install/erase, query and verify. Eventually
it should be turned into just a dumb wrapper which just execs
the per-functionality binaries, but leaving that for later stage,
as popt exec/aliasing doesn't quite seem to up to par with the task.
Having the separate binaries available at least makes it possible
for callers to specify the amount of privileges they need.
- Avoids having to link /bin/rpm with librpmbuild and everything it
might bring in (eg libmagic) which are not needed for core operation.
- Minimally preserve backwards compatibility with popt exec alias
- For now this is really just to allow building statically while
hacking, for "real world" use this has implications on collections
support etc which is not handled by this patch.
Panu Matilainen