| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
%mutable
- is defined for files and links. It means update until modified.
In more details:
- if a file/link is the same as in new package then touch it,
- if a file/link is the same as in old package then upgrade it as "normal" file/link,
- else do nothing.
%noupdate
- is defined for all file types used internally by rpm. It is for cases, where packager wants just the initial content, never to be touched by rpm again.
In more details:
- if the file does not exist, then create it,
- if the file exists, then do nothing.
|
| |
|
|
|
|
|
| |
Take advantage of the disabler data added in commit
5aeb8ed1cf5462ddc703b6d04838cc7d8b46b747 to permit fine-grained
disablers on this path. Neither the API or the cli actually supports
passing them at the moment so it's just an internal improvement for now.
|
| | |
|
| |
|
|
|
| |
No functional changes (at least intended ones), just makes it easier
to see what is what exactly.
|
| | |
|
| |
|
|
|
|
|
| |
The gpg HOME is in the builddir testing directory.
But the keys to import are in the srcdir data/keys directory.
Signed-off-by: Mark Wielaard <mark@klomp.org>
|
| |
|
|
|
|
|
|
|
| |
It only makes sense to add a minisymtab for executables and shared
libraries. Other executable ELF files (like kernel modules) don't need it.
Since those don't have a dynsym section trying to add it will fail and
produce confusing errors from nm.
Signed-off-by: Mark Wielaard <mark@klomp.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
Some packages depend on the build-ids as generated during the build
and cannot handle rpmbuild recomputing them before generating the
package file list. Add -n, --no-recompute-build-id to debugedit and
add -n to find-debuginfo.sh set by defining the %_no_recompute_build_ids
macro for such packages. %_no_recompute_build_ids can not be used together
with %_unique_build_ids.
Signed-off-by: Mark Wielaard <mark@klomp.org>
|
| | |
|
| |
|
|
|
|
|
|
| |
The OpenPGP time fields are unsigned four-octet numbers, storing
it as the uint32_t it actually is makes using the value that
little bit saner.
Way too many places to update as we still have no API for this, sigh.
|
| |
|
|
|
|
|
|
| |
It only ever worked as root, which we don't want to encourage for the
test-suite anyway, and commit 86c523da6fa1cada0c5753c14bb1f2fdd436d28d
broke it even for root since plugins are globally disabled in the test-suite.
We can always reintroduce it later if it becomes feasible...
|
| | |
|
| |
|
|
| |
Not useful in itself, but paving way for next steps.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Originally introduced in commit f5203aea8bd83dc18e48dda4a564429c0e48bab4
in 2004, pgpPubkeyFingerprint() has been returning the 64 bits long
Key ID from the tail of 160 bits long fingerprint, not the actual
fingerprint.
Add a new public API for retrieving the Key ID specifically, adjust
the handful of internal users to use it and make pgpPubkeyFingerprint()
return the actual fingerprint. It's an API break sure but there are
unlikely to be any callers outside rpm and we're breaking the API + ABI
left and right in this release so doesn't matter...
|
| | |
|
| |
|
|
|
|
|
| |
The sole user within rpm was removed over six years ago, never seen
a single user outside rpm, and even then it's just a wrapper around
rpmBase64Decode() and pgpPubkeyFingerprint() with a bizarre
return code. Bye bye...
|
| |
|
|
|
| |
Support for insecure V3 public keys was dropped six years ago, not
something todo... Also we have supported SHA256 for a good while now.
|
| |
|
|
|
|
|
|
|
|
|
| |
Sigh, there are endless minute details that can make seemingly
reproducable builds non-reproducable, including:
- optflags leaking from distro settings and all (so override)
- the distro name we're building on (so override)
- payload compression (so don't compress)
One possible failure case is the OS, these all expect Linux as the
build platform and that's not so easy to override.
|
| |
|
|
|
| |
Should've been in commit 7ba0b8ff6f92a5658ac465d2057f0f28f4a61856,
no need to scare people (including myself) with unexpected FAILs...
|
| |
|
|
|
|
|
| |
Grab data + its length to helper variables by whatever appropriate
means early on and use those to access the data. In particular, this
supposedly adds support for string arrays as signature data.
While at it, add a test for NULL or too short data.
|
| |
|
|
|
|
|
| |
gpg2 wants to leave gpg-agent running in the background which is fine,
until we pull the rug from underneath it by nuking the test root it
was launched in, causing us to hang on --addsign tests. Shut down
any agents running in the test root before nuking it for an update.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This seems more trouble than it's worth on the outset, but then the
new data is not really being used yet.
|
| |
|
|
|
|
| |
Rename the oddball sigtInfo struct to rpmsinfo, and the "constructor"
to rpmsinfoInit() which will make a nicer pair for Fini() once we'll
need that.
|
| | |
|
| |
|
|
|
|
| |
For purposes of the generic signature checking machinery, only the last
value is ever needed so handling it in rpmsinfoInit() is far more
appropriate.
|
| |
|
|
|
|
|
|
|
|
|
| |
pkgconf (alternative to freedesktop's pkgconfig implementation)
uses this flag to stop resolving dependencies after some level.
In our case, we are not interested in checking dependencies from
buildroot at all, we just generating top-level dependency list.
References: https://bugzilla.redhat.com/show_bug.cgi?id=1401463
Reported-by: Martin Sehnoutka <msehnout@redhat.com>
Signed-off-by: Igor Gnatenko <ignatenko@redhat.com>
|
| |
|
|
|
| |
Just to be consistent with all the other digests etc, hardcoded
for now. Adjust tests accordingly.
|
| |
|
|
|
|
|
|
|
|
| |
Essentially reverts commit 40efa628a513fa43e47b0151d69c9fa8c8a56ba4
but with two differences: use $(abs_srcdir) instead of $(srcdir)
for base of HOME which seems to make things work fairly reliably.
Knock wood, and watch out for 'em pixies... The other thing is
to drop -q(uiet) from the import commands, those were a leftover
from importing in the test itself, but better import just once
because we're not here testing gpg really.
|
| |
|
|
|
|
|
|
| |
In case that binary compiled from source generated in /tmp, a
/usr/src/debug/tmp directory will be created with the same mode as
/tmp, a.k.a 777, which should be avoided.
Fixes: rhbz#641022
|
| |
|
|
|
|
| |
It was working just fine here locally, really. And now its not.
Comment it out for now, my testsuite hacking quota is full for today.
Sigh.
|
| |
|
|
|
|
|
|
|
| |
This is tricky and flimsy as we criss-cross over the fakechroot border:
getting gpg and gpg-agent to work in the fake root environment seems
non-trivial (mismatch about homedir expectations I think) so we
run signing outside the root and verification inside. And anything
on the outside needs to avoid absolute paths in results as those
would change from user to user etc. Still, better than not having it...
|
| |
|
|
|
|
|
|
|
| |
Add a pre-signed copy of the hello binary rpm, plus the public
and (passwordless) secret key for testing purposes. Run a couple
of simple rpmkeys --import and -Kv tests to see basics are working.
As a side-effect we now have a simple reproducability test as well.
It ain't much but it's more than we had before...
|
| |
|
|
|
| |
For now this is just the tag, but gives us a single place to change
it when it becomes necessary to do so.
|
| | |
|
| |
|
|
|
|
|
|
| |
Commit 8192746196745e15517e49230de183a0211017b6 enabled digest checks
for empty files, which is fine for modern era packages but rpm didn't
always generate a proper digest for them. Handle that as the special
case it is: preserve the digests checks as they are, but additionally
test and accept zeros too for MD5-era zero-length files.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
fdigest cannot possibly be NULL here because the surrounding loop
would have terminated in that case, and removing that distraction
makes the actual test a whole lot more obvious.
|
| |
|
|
|
|
| |
Makes it easier to see that there are no hidden side-effects
etc involved when the variable is truly block local and not function
wide.
|
| |
|
|
|
| |
...and move the initialization next to the file signature init
where it logically belongs.
|
| |
|
|
|
|
|
| |
This currently fails due to regression originating from
commit ead9cdd587bbf052722f0f8598e0983e565e3415 and
7f47cbbd7d1600ae280e48a655c9e870cf9361e0, which exist just because
we didn't have this testcase...
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
As specifying target will load & set macro definitions according to
target specified, it's still useful to provide it anywhere where ie.
--eval may be used, as by specifying --target first, it'll change the
target specific macros to load which is perfectly sane and useful for
checking macro specific definitions.
Remove now redundant --target= argument for rpmspec as it's now global.
|
| |
|
|
|
|
|
|
|
|
|
| |
Makes it possible to work around trouble of installing packages that use
file capabilities in user namespaces.
It simply ignores the capabilities as opposed to setting a setuid bit.
This is a safer things to do, but possibly has a negative impact on some tools
(such as ping being usable only by the superuser).
https://bugzilla.redhat.com/show_bug.cgi?id=648654
|
| |
|
|
|
|
| |
Besides the logic being completely wrong to begin with, it wasn't
actually handling the failure to allocate a digest at all. Do that,
and return values according to documentation.
|
| |
|
|
|
|
|
|
| |
This is an internal helper for debug logging and should've never been
part of the API in the first place. We're removing all sorts of things
on this round anyway so it's a fine opportunity for removing this too.
It's not as if anybody used this outside rpm because it's ... not
exactly useful.
|
