The patch enables to use formats:
%define _sourcedir /my\ directory/my\ subdirectory
%define _sourcedir /my directory/my subdirectory
Formats, with directories in double-quotes or quotes:
%define _sourcedir "directory"
%define _sourcedir 'directory'
are not accepted.
Comment to Panu and Florian:
I did not add formats with double-quotes or quotes because
- the implemented format was the most strightforward possibility
- in rpm spec files double-quotes or quotes are not usually supperted too
The second allowed format is only a side effect of the implementation,
it was not my purpose.
The whole point of %trace is that some macro is being evaluated in a
surprising way, and you want to know what it is. This is often the
result of an unfortunately complex macro with difficult to see
intermediate results.
Shortening the output because it doesn't fit past 61 or so characters
does not help, and we have big screens these days. Don't do it.
Signed-off-by: Peter Jones <pjones@redhat.com>
This allows you to do 'rpmspec --trace -P foo.spec", which is much more
natural than editing the .spec itself to add %trace, and much more
convenient than using --eval yourself.
Signed-off-by: Peter Jones <pjones@redhat.com>
In %trace mode, evaluating a macro which is undefined causes an invalid
read of 1 byte when searching for the end of the string:
trillian:~$ valgrind rpmspec --eval '%trace' --eval '%{?myUndefinedMacro}'
==21534== Memcheck, a memory error detector
==21534== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==21534== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==21534== Command: rpmspec --trace --eval %{?myUndefinedMacro}
==21534==
1> %{?myUndefinedMacro}^==21534== Invalid read of size 1
==21534== at 0x55018D4: printMacro (macro.c:296)
==21534== by 0x5502DFC: expandMacro (macro.c:1077)
==21534== by 0x5503710: doExpandMacros (macro.c:1280)
==21534== by 0x5504AB6: rpmExpand (macro.c:1629)
==21534== by 0x508F59A: rpmcliAllArgCallback (poptALL.c:120)
==21534== by 0x6DAF71D: invokeCallbacksOPTION (popt.c:156)
==21534== by 0x6DAF75B: invokeCallbacksOPTION (popt.c:139)
==21534== by 0x6DB1428: poptGetNextOpt (popt.c:1515)
==21534== by 0x508F912: rpmcliInit (poptALL.c:302)
==21534== by 0x1095B2: main (rpmspec.c:63)
==21534== Address 0x8a010f3 is 0 bytes after a block of size 19 alloc'd
==21534== at 0x4C2DB9D: malloc (vg_replace_malloc.c:299)
==21534== by 0x5507C17: rmalloc (rpmmalloc.c:44)
==21534== by 0x5502788: expandMacro (macro.c:927)
==21534== by 0x5503710: doExpandMacros (macro.c:1280)
==21534== by 0x5504AB6: rpmExpand (macro.c:1629)
==21534== by 0x508F59A: rpmcliAllArgCallback (poptALL.c:120)
==21534== by 0x6DAF71D: invokeCallbacksOPTION (popt.c:156)
==21534== by 0x6DAF75B: invokeCallbacksOPTION (popt.c:139)
==21534== by 0x6DB1428: poptGetNextOpt (popt.c:1515)
==21534== by 0x508F912: rpmcliInit (poptALL.c:302)
==21534== by 0x1095B2: main (rpmspec.c:63)
==21534==
1> %{?_transaction_color}^
1> %{?_prefer_color}^
1> %{_netsharedpath}^
1> %{_install_langs}^
==21534==
==21534== HEAP SUMMARY:
==21534== in use at exit: 7,183 bytes in 71 blocks
==21534== total heap usage: 7,811 allocs, 7,740 frees, 3,500,361 bytes allocated
==21534==
==21534== LEAK SUMMARY:
==21534== definitely lost: 19 bytes in 1 blocks
==21534== indirectly lost: 0 bytes in 0 blocks
==21534== possibly lost: 0 bytes in 0 blocks
==21534== still reachable: 7,164 bytes in 70 blocks
==21534== suppressed: 0 bytes in 0 blocks
==21534== Rerun with --leak-check=full to see details of leaked memory
==21534==
==21534== For counts of detected and suppressed errors, rerun with: -v
==21534== ERROR SUMMARY: 5 errors from 1 contexts (suppressed: 0 from 0)
trillian:~$
This can easily be avoided by checking the first byte as well as the
second for our sentinal value (NUL).
Signed-off-by: Peter Jones <pjones@redhat.com>
After creating a specPkg from a spec file we must increase spec file
reference counter. Otherwise spec file may be accidentally deallocated
and usage of SpecPkg can cause an error.
We don't need two sets, instead do two rounds of signature checking:
once after just the header has been read, and once after the payload
has been read too.
The fooKeys strings freeing needs to be moved to the end as we can
now jump past it otherwise.
We really dont need three different variables to determine whether
the operation was success or not. Assume failure all along and
only assign success at the very end.
Rename the siginfo payload field to range, which better explains
what it means. Also make it a bitfield which allows expressing
the actual combinations: modern signature/digest items are on
header only, rpm v3 ones are on header+payload and in the future
we might have payload-only digest(s) as well.
No functional changes intended.
Apparently 50 bytes is not enough for everybodys dates:
LC_TIME=ko_KR.utf8 rpm -q --queryformat '%{installtime:date}\n' rpm
Lets hope nobody on this planet needs to deal with dates that read like
a short story. Aliens we dont consider, sorry.
Pass emsg around from the callers, actually emit an error if output
doesn't fit our buffer, allowing us to get rid of the old TODO note.
strftime() returning zero is not, generally speaking, always an error
because a format might be empty or the result could be empty, such
as %p/%P in many locales. However in our case the formats are known
to be non-empty.
Change the way individual digests within bundles are stored and accessed:
Previously the digest algo number was used directly as the index into
the bundle. Which works, but limits you to a single digest per algo,
and the array is likely to be rather sparse. To address both issues, use
an arbitrary integer ID to address the digests and always add new
digests in the first available slot. And yes the implementation is
a bit simplistic and taking some shortcuts, but so was the previous one.
Abstracting out the actual algorithm allows using eg rpm tag values
as the identifier, and also makes it possible to do multiple digests
of the same type on overlapping ranges. This is entirely backwards
compatible however if you simply use algorithm number also as the id,
so callers *need* to be updated.
Until now we have been reading and importing the headers, and then
pull out the original immutable image from the header in order to
do signature checking on unknown packages. Those header manipulations
are relatively complex and thus vulnerable operatations that are,
to add to the insult, totally unnecessary as the header on disk is
just the way we want it for signature checking as it is.
This changes the package reading process rather fundamentally: we first
read (and sanity-check) the header blobs, then do signature checking on
the still un-imported blob, and only then try to import the headers
(which could still fail, at least in theory). This reduces the amount of
code exposed to unverified headers considerably: the deep header internals
are avoided entirely, and there's one less signature checking code-path
to worry about as it's now unified with the one used by headerCheck().
There's a subtle change in the "preferred" signature type: rpmpkgRead()
used to prefer DSA over RSA, headerSigVerify() prefers RSA. However
that's rather academic as both signature types never co-exist in
the same package.
For normal use, all this shouldn't change anything at all.
After a successful import, the header owns the memory originally alloced
for the hdrblob. Set the blob allocation to NULL on successful import
so callers dont need to guess about freeing it in case of other failures.
Limit the maximum date to SOURCE_DATE_EPOCH or use origtime if not defined
similar to the tar --clamp-mtime option
based on a patch by Nicolas Vigier <boklm at torproject.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
Mistakes in %dev as "%dev(c,b,0) /dev/lirc"
will give unclear errors like:
Missing devmajor in %dev b
Make a copy of the all the arguments in brackets to make the error clear:
Missing devmajor in %dev(c,b,0)
As Python wheels do not contain targetted Python version in the directory/file
name of their metadata like Python eggs do, and since the Python version is not
contained in the metadata either, it is necessary to get it from elsewhere.
Here it is parsed from the path the metadata resides at
(e.g. /usr/lib/pythonX.Y/site-packages/...)
There is no need for /usr/bin/python when byte compiling files in
/usr/lib/pythonX.Y (only /usr/bin/pythonX.Y). Moved check so we do not exit
prematurely.
Fixes: rhbz#1411588
In V4 signature packets there are multiple data sections, whose length
is stored as two bytes before the data. We've been checking the data
boundaries, but a truncated/malformed packet might be missing the
length data too. Add + use a little helper function to check the
length is actually there.
Mistakes in %defattr/%attr such as "%defattr(123, root, root, x750)"
will give a confusing and misleading errors like:
error: Bad dirmode spec: %defattr(123)
Make a copy of the all the arguments to make the error sensible:
Bad dirmode spec: %defattr(644, root, root, x755 )
pgpPrtSubType() assumes there is at least one byte of packet body
for it to process, check the lower boundary too. The check for
pgpLen() zero return is slightly confusing and perhaps the reason
why this has been overlooked: zero return from pgpLen() is an error
alright, but in order to store the perfectly legal packet body length
you need one byte nevertheless, so pgpLen() returns 1 for zero-length
body.
Add a helper function for checking boundaries (can I have just one
teeny weeny bite - erm - byte, please?) and returning the version,
use systematically where it matters.
It *might* be okay to do this at start of pgpPrtPkt() once and for all,
but then AFAICT OpenPGP does not forbid zero length body in general,
plus there are multiple callers for getFingerprint() so might as well
check individually in the callers that actually care.
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!
There's a check for total number of tags, and their types and all
but absolutely no check for the actual tag numbers. So we end up
accepting negative tags which should not exist. The tag type should
really be uint32_t but that's another can of worms, lets have something
easily backportable for now.
This is enough to fix issues #133, #135, #136, #138 and #139 on the
level of detecting header structural inconsistency.
In case of disablers we continue to the next item without
freeing possible error message from rpmSigInfoParse(), handle
this similarly to the other signature parameters.
"Other" signature types are sizes and the like whose values we don't
care about in here, but whose types we validate and want to be sane.
So take errors from rpmSigInfoParse() into account, but skip
rpmVerifySignature() because it doesn't make sense for the "other" types.
On the other hand, unknown types we should just skip, this is necessary
to avoid unnecessarily breaking forward-compatibility.
Introduced in recent header read/init/parse refactoring: when
hdrblobInit() fails via hdrblobRead(), the allocated memory is freed
but hdrblobInit() would already have assigned it to blob->ei.
Normally this is not an issue but rpmpkgVerifySigs() codepath differs
from the other paths in that it does not end in importing the header,
so it needs to free blob->ei by itself. Which doesn't go so well
if hdrblobRead() already freed the memory pointed to by blob->ei.
Ensure it's set to NULL on failure to prevent this kind of accidents.
Panu Matilainen