We only actually used gethostbyname() for canonicalizing buildhost,
convert that to use getaddrinfo() instead, which actually has an
option for retrieving exactly what we want.
The other "use" was to initialize name services, but as we don't need
or use hostnames for any operation, we can just as well drop it. User
and group names are what we care about.
This plugin installs fsverity signatures for regular files, when a signature
is found in the RPM. It tries to enable them unconditionally, but fails
gracefully if fsverity isn't supported or enabled.
Signed-off-by: Jes Sorensen <jsorensen@fb.com>
Only accept OpenMP >= 4.5, due to the "priority" clause that we use
since commit 6f6f5e7, and also document that in the INSTALL file.
If explicitly required with --enable-openmp, fail configuration if the
version is not available.
https://www.openmp.org/wp-content/uploads/openmp-4.5.pdfResolves: #1315
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).
The special note requires remsh which is used internally, under
different name (with one underscore instead of two).
Those macros are not used anywhere in RPM, neither in Fedora as of
today.
References: https://github.com/rpm-software-management/rpm/issues/1211
Signed-off-by: Igor Raits <i.gnatenko.brain@gmail.com>
The NSS library often changes in ways that somehow breaks rpm,
and these days upstream does not care about consumers of NSS other
than itself. This inflicts untold amounts of suffering on users
of rpm in distributions where rpm is linked to NSS.
Now that we have a couple of good, well-supported options, there is
no reason to keep supporting NSS as an option.
So now, we are deprecating it for later removal.
Unlike that multiple statfs() variants, statvfs() is actually in
POSIX 1-2001 already and covers everything we need so there's little
point mucking with anything else. statvfs() is what Linux has been
using all along anyway this means no change on the primary platform.
If this actually regresses something, adding back OS-specific bits
is not a problem, but at least we'll get a clean start with that.
The message about telling your OS vendor about GNU utilities that
gets removed here dates back to 1997. The X syntax to chmod goes back
to at least 2004 specification of POSIX 1003.1, I think we can safely
assume that capability in 2020. And that OS vendors know about GNU :)
Our beloved gettext 0.16.1 version causes automake to complain about
AM_PROG_MKDIR_P being deprecated although we never directly use such
a macro for anything. This appears to have been fixed in gettext 0.18.2
so bump to that version, having been released in 2012 makes it, um,
mature enough, even for rpm purposes.
Berkeley DB 5.x is dead upstream ever since the license change some
seven years ago. Mark as deprecated for later removal now that we're
starting to have viable alternatives.
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.
Michal Domonkos