Age | Commit message (Collapse) | Author | Files | Lines |
|
'?' is returned by getopt when option is unknown, making hard to
pinpoint the actual bogus option...
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
(cherry picked from commit 8192e580a0a962b8eb7f9d8fc07bd3f99ccf0ffe)
|
|
(cherry picked from commit 2d39f13064f6e6ff1a1633b708e7ba5622a7e8eb)
|
|
- SHA224-support was added around NSS 3.13, dont break compilation
with older versions just for this rarely used hash.
- HASH_AlgSHA224 is an enum so test for SHA224_LENGTH define instead
(cherry picked from commit e15e29823451663e27a5bec6c865b37901f1c315)
|
|
- Not much point in enumurating unsupported cases, or with switch-breaks
after returns.
- Recognize SHA224 too
(cherry picked from commit 466a6b554e7f7ded9f1c59646e6b64243ce16812)
|
|
- VFY_VerifyDigest() has been deprecated since NSS >= 3.12 and for
a good reason too: with VFY_VerifyDigest() caller needs to painfully
enumerate every possible supported enc + hash combination, only for
NSS to revert the process. Use the saner VFY_VerifyDigestDirect()
interface instead and test for its presence in configure.
- This means we now require NSS >= 3.12 but as that's already 4.5 years
old and included in ancient beasts like RHEL-4, this doesn't seem
exactly unreasonable requirement. And then there's always beecrypt...
(cherry picked from commit 9b995a7674adba08248fac79ae8b23ecbecc13de)
|
|
- No functional changes here (either), but using the proper constants
simply makes things that little bit clearer.
(cherry picked from commit 604da18bc267f89568081c1ab163c7fc45207220)
|
|
- NSS >= 3.14 introduces support for DSA2 and marks DSA_SUBPRIME_LEN
as deprecated. Use explicit DSA1_SUBPRIME_LEN (we only support DSA1
for now) instead where available, add compatibility define for
older versions.
- Also directly include <blapit.h> where its defined - blabit.h gets
included via cryptohi.h but being explicit about it avoids having
to redefine it again "just in case".
(cherry picked from commit 73be0fc7d9faab9f1120e2979f2ca1feed522195)
|
|
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
|
|
- We haven't removed or changed any interfaces in a way that would
require full soname bump, only a handful of new interfaces have
been added.
- There aren't actually any new interfaces in librpmbuild or librpmsign
but for sanity and consistency's sake they're all updated...
|
|
- This might've clashed with %dir in spec %files at some point as
indicated by the comments, but that should no longer be the case.
|
|
- Older NSS versions operate on global context, which can cause
all sorts of trouble when an API user tries to use NSS for their
own purposes: eg they might want to use NSS databases which is not
possible once we've initialized NSS with NSS_NoDB_Init(). Further
background on the subject at https://wiki.mozilla.org/NSS_Library_Init
- Use private private NSS context when possible (NSS >= 3.12.5) to
avoid such clashes, but keep support for older versions for now.
|
|
- Not all systems automatically restart signal-interrupted operations,
handle this centrally since its so easy to do. Also related to
RhBug:580974.
|
|
|
|
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
|
|
- When compiled without selinux support, stdlib.h doesn't get
included here. Wtf?
|
|
Add compatibility support for both lua-5.1 and lua-5.2,
assuming that the LUA_COMPAT might have been disabled.
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
|
|
- Use multiple chunks that get allocated as old ones get filled up
instead of reallocating, store direct pointers to the strings in
the id array.
- This prevents nasty surprises when previously retrieved pointer
to a pool string goes invalid underneath us due to somebody
adding a new string, and restores former rpm API behavior:
string pointers retrieved from eg rpmds and rpmfi are valid for
the entire lifetime of those objects.
|
|
|
|
- Just a simple s/sidpool/pool/ to match the implementation, "sidpool"
is a leftover from early draft version that somehow made its way
to the master tree.
|
|
|
|
|
|
- At the largest id, the end boundary is data, not offset size... doh
|
|
- Allow looking up and inserting partial key strings, this is useful
in various cases where previously a local copy was needed for
\0-terminating the key in the caller.
- Take advantage of rstrlenhash() in rpmstrPoolId(), previously the
length was only interesting when adding so we wasted a strlen()
on every call when the string was already in the pool.
|
|
- Being able to hash partial strings is needed for allowing string pool
to operate on partial strings...
|
|
- String hashing needs to walk the entire string anyhow, might as well
take advantage of this and have it return the string length to avoid
having to separately call strlen() in the cases where this matters.
- Move the implementation into rpmstrpool.c for inlining possibilities,
rstrhash() is now just a wrapper to rstrlenhash(). The generic
hash implementation could not take advantage of this anyway really.
|
|
- Before this, the slen argument was only good for avoiding an extra
strlen() but being able to handle shove and lookup partial strings
without local copy+modify in callers is handy, this is one of
the prerequisites for that.
|
|
- The pool itself can address its contents by id alone, storing
pointers to the strings only hurts as reallocation moving the
data blob requires rehashing the whole thing needlessly.
- We now store just the key id in the hash buckets, and lookup the
actual string for comparison from the pool. This avoids the
need to rehash on realloc and saves memory too, and this is one of
the biggest reasons for wanting a separate hash implementation for
the string pool. Incidentally, this is how libsolv does it too.
- Individual bucket allocation becomes rather wasteful now: a bucket
stores a single integer, and a single pointer to the next bucket,
a pointer which can be twice the size of the key data it holds.
Further tuning and cleaning up after the marriage of these two
datatypes left after the honeymoon is over...
|
|
|
|
|
|
- As the pool is hardwired to single hash type, these dont make
any sense here and the extra indirection will only hurt performance.
|
|
- The only data associated with a pool key is a single id, we dont need
an array for that
- Change poolHash get-entry return the id directly instead of pointer array
|
|
- There's a strict 1:1 relation between keys and data in the string
pool, this keeping count of data is pointless.
|
|
|
|
- The string pool is more specialized a data structure to be efficiently
handled with the generic hash table implementation in rpmhash.[CH]
and really requires quite a different approach.
- For starters, import a private copy generated roughly with:
gcc -E -DHASHTYPE=poolHash \
-DHTKEYTYPE="const char *" -DHTDATATYPE=rpmsid rpmhash.C
...and clean it up a bit: eliminate unused functions (except for
stats which we'll want to keep for debug purposes), make remaining
functions static and overall tidy up from the mess 'gcc -E' created.
Lots of redundant fluff here still, to be cleaned up gradually...
- This doesn't change anything at all, but opens up the playground
for tuning the pool hash implementation in ways the generic version
could not (at least sanely) be.
|
|
- No changes other than a rename for next steps...
|
|
- This way we have exactly one place for controlling hash (re)creation
size strategies etc.
|
|
- The previous size hint would actually cause us to shrink the hash
bucket allocation, requiring the hash to resize itself immediately
afterwards. As if the rehashes weren't expensive enough already...
|
|
- As a special case, two strings (ids) from the same pool can be tested for
equality in constant time (integer comparison). If the pools differ,
a regular string comparison is needed.
|
|
- realloc() might not need to actually move the data, and when it
doesn't we dont need to do the very expensive rehash either.
Unsurprisingly makes things a whole lot faster.
|
|
- Pool id -> string always works with a frozen pool, but in some cases
we'll need to go the other way, allow caller to specify whether
string -> id lookups should be possible on frozen pool.
- On glibc, realloc() to smaller size doesn't move the data but on
other platforms (including valgrind) it can and does move, which
would require a full rehash. For now, just leave all the data
alone unless we're also freeing the hash, the memory savings
isn't much for a global pool (which is where this matters)
|
|
- Pool id 0 is special case for "not found". Return an actual NULL
instead of an empty string.
|
|
|
|
- String -> id lookups need the hash table in place even if we're not
adding. We could do a linear search in such a case but...
|
|
|
|
- String pool offset resize was off by one, oops
- String pool data-area resize requires rehashing all the strings,
as the key pointers change. Ouch. Should be avoidable by extending
rpmhash to allow passing the pool itself around in comparisons as "self"
and using offsets as keys, but for now working counts more than speed.
- The unfreeze-sizehint calculation could be negative. Turn the initial
size into constant and use that as a minimum, otherwise rehashing
uses (more or less arbitrary) heuristics to come up with some number.
Lots of fine-tuning ahead...
|
|
- I suspect these will be used widely, to avoid having to include
rpmstrpool.h all over in headers...
|
|
- 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.
|
|
- Check for lowercase letters before uppercase. A very minor difference
as such, but our file digests use lowercase hex and this gets
called a lot from rpmfiNew().
|
|
- This reverts commit 4c1f7e335de1724661ce63c53186d161ab71a63f:
various things inside and outside of rpm actually do still depend
on the old behavior, and leak file descriptors otherwise.
As an easy backportable band-aid, revert back to the previous
behavior, to which various callers are tuned to fix the regression
introduced in rpm 4.10.0. The real fix would be something more like
"eliminate fdFree() and make Fclose() honor refcounts".
|
|
- Commit 4cb02aa928d3e41f636d0e01356c7a3cb51018ee asked to see
what breaks when mmap() is used, now we know: large package support
broke when enabling it. Could be fixed of course by eg adding
a size cap to the fsm part as well, but just doesn't seem worth it:
I fail to measure any meaningful performance improvement from mmap
usage in either case, and added complexity for what is close to
zero benefit just doesn't make sense... and various sources in fact
note the rpm usage (read through the entire file sequentially) as one
of the cases where mmap() is NOT beneficial due to mmap() high
setup + teardown cost + page fault speed (or lack of thereof).
|