Beecrypt upstream is dead for seven years, this is not a healthy situation
(death tends to have that effect...) for any component, and even less
so for security sensitive component. Deprecate for later removal now
that we have multiple nicer alternatives.
In the three years that LMDB support has been in the tree, and four
since upstream promised 1.0.0 in a couple of months, there have been
no upstream changes towards eliminating the key size limitations that
we need. And in the meanwhile it has become clearer that LMDB is not
the promised land it seemed on the outset, instead it has issues
like requiring the database size to be pre-determined (#902).
Drop support for LMDB, there's active development going on in the area
of database backends and we cannot afford to drag along an experimental
backend that is blocked on upstream design limitations and shows no signs
of moving forward. We can always bring it back if the upstream situation
changes.
This commit implements a read-only backend that allows accessing
of BerkeleyDB databases without using the BerkeleyDB library.
The code supports btree version 9-10 and hash version 8-10.
There are two use cases for this:
1) Conversion of an existing BerkeleyDB to a different
backend.
2) Allowing package scriptlets to do database queries while
in a transaction that replaced rpm with a version that
no longer links against BerkeleyDB.
If both BerkeleyDB and the read-only backend are enabled, rpm will
default to BerkeleyDB.
As of sqlite 3.22.0, a database in WAL mode can be opened readonly
if one or more of the following is true:
1) The -shm and -wal files already exists and are readable
2) There is write permission on the directory containing the database
so that the -shm and -wal files can be created.
3) The database connection is opened using the immutable query parameter.
Regular users running queries cannot have permission to create, and
immutable databases can only exist on readonly media (because all locking
is disabled) so there's no choice but to leave the -shm and -wal files
around at all times, a little ugly as it might be.
libgcrypt from 1.8.5 provides a pkg-config file as well as the traditional
libgcrypt-config script. As pkg-config is more resiliant in the face of
complicated build environments (for example cross-compilation and sysroots)
prefer the pkg-config file, falling back to libgcrypt-config if that doesn't
exist.
LGTM flags localtime() as a "dangerous" function, which seems a bit
over the top to me, but as we're flirting with threads, it certainly
is not thread-safe.
All normal functionality is expected to work. Automatic generation
of missing index tables is missing, but that's not relevant at this time.
Going forward, we'll also want some sort of compatibility tracking
for the sql schema.
The database scheme basically just mirrors what BDB does, using strings
for strings and blobs for everything else due to the way integers are
handled in the sqlite C API, for now at least. Some amount of schema
changes are to be expected before this is considered final.
Performance is similar or better with BDB in the current unsafe CDB
model, but sqlite uses proper database transactions so this is expected
to be an order of magnitude more robust.
Many things are stupid and/or kind of backwards here due to the internal
API, which I've avoided changing in order to keep it backportable for the
time being. https://github.com/rpm-software-management/rpm/pull/836 is
needed but otherwise this should drop quite trivially into 4.14.x too.
However as we're planning for a longer term future here, it would be dumb
to limit ourselves by what's possible with an internal BDB-oriented API,
so I've fairly major changes planned in that direction.
-Werror is a bit tricky as it'll cause autoconf tests fail left and right
if it's just passed normally via CFLAGS, so we need to sneak it in
by some other means.
Note that while developers should always enable this, -Werror must never
ever be a default as it'll eventually just cause bogus build failures
when old releases get built with newer compilers.
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?)
Python 2 will be EOL by the time of the next major rpm release,
time to retire the Python 2 bindings. Specifically we require
Python >= 3.1 for surrogateescape-support.
AC_OPENMP supports --enable/disable-openmp out of the box, but as it
only sets OPENMP_CFLAGS *if needed by the compiler to support openmp*,
it's utterly useless for conditional building. And because AC_OPENMP
doesn't set $ac_cv_prog_c_openmp to anything if --disable-openmp was
used, we need to test that it's neither empty nor unsupported to
determine if we actually have openmp, in order to set an autoconf
define that we can actually use to conditionalize aspects of the
build on. Argh.
Enable OpenMP use in librpmbuild and set the number of OMP threads
from rpm config after spec parsing. The place matters as we want to
allow individual specs to control and disable parallel builds.
Use dwelf_elf_begin() for reading ELF files for build-id generation on
versions that have it to support compressed ELF files such as kernel
modules (RhBug:1650072,1650074). Note that debugedit still cannot handle
compressed files, this is only for build-id generation.
When enabled, log audit events for package install, update and remove.
The log includes the operation, package nevra, signature check result,
whether signatures are being enforced enforced and overall operation
result code. Package install/update/remove are logged as such,
obsoletion is logged as install + remove (whereas the erasure element
on updates is silent). Enable compilation in CI.
Loosely based on initial RHEL 7-8 implementations by Pavlina Moravcova
Varekova and Florian Festi (RhBug:1555326, RhBug:1607612)
Python 2 EOL is closing in fast, time we start looking forward instead
of backward too. Document how to build for Python 2 for now, and update
version requirements.
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.
Commit 9e64f8d5b7 was supposed to allow
this but actually building the internal BDB requires with_external_db to
be "no", whereas in the automatic case it was "maybe", resulting in
the internal BDB not actually getting built at all.
If host kernel supports user namespaces, this allows non-privileged users
to perform chrooted operations such as installations and verification.
With caveats. Only root:root ownership is supported in the namespace, so
packages with other file ownerships will fail to install properly, chown()
fails with -EINVAL similarly to what happens on squashed NFS-mount. We
don't handle that particularly gracefully.
Also add the obligatory disabler, and use it for the test-suite for
now. Only two tests (61 and 342) actually fail because of it, simply
because things are ... different with user namespaces.
There's an increasing number of placing wanting to know the number of
CPU's for parallel processing, and increasingly these things are running
in containers and such where the total host CPU count is not meaningful.
The oldest patch version available from http://ftp.gnu.org/gnu/patch/
is patch 2.5 from August 1997, the same year when commit
636fc4bec9 added support for
"modern patch programs", 21 years ago almost to date. A bit of digging
around reveals that GNU patch 2.1 released in 1993 and patch 2.2 earlier
in 1997. Makes me think perhaps we can risk dropping support for 2.1
without a huge uproar from the community... RIP old fella.
Older Python versions are long since past their EOL, we don't need to
support them either. Python 2.7 is also the least incompatible version
compared to Python 3, going forward. Nuke the now unnecessary compat
macros.
These things are up to distro/platform build policies, it's not as if
rpm actually required position independent code. And as it happens,
doing the right thing renders PR #350 unnecessary.
If /etc/passwd contains multiple users with UID 0 then user_with_uid0 will
contain a line feed which results in config.h containing:
#define UID_0_USER "root
(i.e. without a closing quote.)
The same problem occurs with /etc/group.
Let's only emit the first match in each case so that there is only ever a
single result.
If syncfs() is available (ie on Linux), only sync modified filesystems.
In order to do this, keep the diskspace information around throughout
the transaction.
Skip the sync entirely on chroot installations for now, but this
too should be configurable (always/auto/never or so).
There's a bit of a chicken-egg problem with post-transaction plugins:
for example systemd_inhibit should only be released after syncing,
but OTOH some other plugins might be performing actions whose results
should be syncing. Leaving it alone for now.
Simplifies things a bit and also makes "PYTHON=python3 ./configure" work,
whereas it previously barfed on figuring the library names like
"libpython3.6m"
v2 (Neal Gompa)
* Switch from RPM_CHECK_LIB to PKG_CHECK_MODULES
* Fix notation of file name in lmdb.c
* Remove MDB_FIXEDMAP flag to prevent portability issues
* Add comment that lmdb is an option for %_db_backend
Closes: #281Fixes: #128
glibc 2.25 introduced (really long and annoying) warnings for each use
of the major/minor macros from the wrong header:
lib/cpio.c: In function ‘rpmcpioHeaderWrite’:
lib/cpio.c:245:13: warning: In the GNU C Library, "major" is defined
by <sys/sysmacros.h>. For historical compatibility, it is
currently defined by <sys/types.h> as well, but we plan to
remove this soon. To use "major", include <sys/sysmacros.h>
directly. If you did not intend to use a system-defined macro
"major", you should undefine it after including <sys/types.h>.
dev = major(st->st_dev); SET_NUM_FIELD(hdr->devMajor, dev, field);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Adjust the configure check to correctly detect the header to include
that doesn't produce those warning producing macros.
Tested against RHEL7 (glibc 2.17) and Fedora 26 (glibc 2.25).
Signed-off-by: Mark Wielaard <mark@klomp.org>
Commit edd709e453 introduced a
dependency on ima-evm-utils >= 1.0, silently breaking build with
older versions that eg Fedora has. Explicitly test for sign_hash()
that takes all the necessary arguments and error out cleanly if
not present/too old.
Older versions of glibc included an fts implementation that didn't have
Large File Support on 32-bit systems. We worked that around by bundling
fts into rpm codebase. Thanks to Mark Wielaard, glibc >= 2.23 has LFS
support in fts.
Unfortunately, we can't drop bundled fts because we have to support
build with other libcs which do not implement fts at all or their
implementations do not provide Large File Support.
Signed-off-by: Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
[pmatilai: Added comment to configure.ac as the test is rather subtle,
thanks for Mark Wielaard for the explanation]
Panu Matilainen