depends.c: save us one rpmdsNew in addObsoleteErasures.

- replaces rpmdsAnyMatchesDep with rpmdsNVRMatchesDep

depends.c: unused parameters in addUpgradeErasures, addObsoleteErasures.

- remove them.

Implement scriptlet start and stop callbacks (RhBug:606239)

- Adds two new transaction callbacks: RPMCALLBACK_SCRIPT_START and
  RPMCALLBACK_SCRIPT_STOP which get issued for every scriptlet we run.
- On script start, callback can optionally return an FD which will
  override transaction-wide script fd to make it easier to accurately
  collect per-scriptlet output (eg per-scriptlet temporary file).
  Callback is also responsible for closing the fd if it returns one.
- For both callbacks, "amount" holds the script tag number. On stop
  callback, "total" holds the scriptlet exit status mapped into
  OK/NOTFOUND/FAIL for success/non-fatal/fatal errors. Abusing "notfound"
  for warning result is ugly but differentiating it from the other
  cases allows callers to ignore SCRIPT_ERROR if they choose to
  implement stop and start.

Eliminate rpm cli callback internals from the API

- rpmcliHashes*, and rpmcliProgress* and rpmcliPackagesTotal are
  implementation details of rpmShowProgress() and are useless outside
  of it. Make them static, these shouldn't have been exported to
  begin with.

Eliminate pointless rpmcliPackagesTotal fiddling

- The total number of packages equals transaction order count, which
  is passed as total to transaction start callback. In particular
  messing with this from rpmtsAddInstallElement() is just stupid.
- This will break callers that are relying on rpmcliPackagesTotal value
  outside a running transaction, but that's just stupid anyway. The
  correct way to get number of elements in transaction set is calling
  rpmtsNElements(), which has been there for a good part of a decade.

fix the signatures of the METH_NOARGS callbacks

Various Python method callbacks have signatures of the form:

  static PyObject *
  foo(some_object_subclass *obj)

and are registered within the PyMethodDef tables with the METH_NOARGS
flag [1], with a cast to (PyCFunction) due to the PyObject/subclass
mismatch.

However, such callbacks do receive two arguments: they are invoked with
a signature of this form:

  static PyObject *
  foo(some_object_subclass *obj, PyObject *ignored)

The CPython interpreter only uses METH_NOARGS to allow it to pass NULL as the
second parameter: there are still two parameters.  The dispatch code is in
Python's Python/ceval.c:call_function:

            if (flags & METH_NOARGS && na == 0) {
                C_TRACE(x, (*meth)(self,NULL));
            }

The fact that this has ever worked may be a coincidence of the
platform/compiler's calling conventions, and I don't think it's guaranteed to
keep working.

[1] http://docs.python.org/c-api/structures.html#METH_NOARGS

Signed-off-by: Ales Kozumplik <akozumpl@redhat.com>

fix use-after-free within rpmfdFromPyObject's error-handling

These lines within python/rpmfd-py.c: rpmfdFromPyObject
are the wrong way around:

Py_DECREF(fdo);
  PyErr_SetString(PyExc_IOError, Fstrerror(fdo->fd));

If fdo was allocated by the call above to PyObject_CallFunctionObjArgs,
it may have an ob_refcnt == 1, and thus the Py_DECREF() frees it, so
fdo->fd is reading from deallocated memory.

Signed-off-by: Ales Kozumplik <akozumpl@redhat.com>

Allow deprecations to work accross colors (RhBug:713323)

This enables package maintainers to:

- Force removal of a no longer supported multilib library (the patch also
  removes the check against obsoleting packages of the same name).

- Deprecate packages of different header color than the package's. Note:
  even x86_64 packages can have header color 1 in which case we are
  currently left with no means to deprecate them from another x86_64
  package. (RhBug:751574)

depends.c:skipColor() is not longer a macro

- Prevents double evaluation of the 'ocolor' parameter.

mark strings extracted from PyArg_Parse* as "const"

- Various places within the bindings use PyArg_ParseTuple[AndKeywords] to
  extract (char*) string arguments. These are pointers to the internal
  representation of a PyStringObject, and shouldn't be modified, hence
  it's safest to explicitly mark these values as (const char*), rather
  than just (char*).

Signed-off-by: Ales Kozumplik <akozumpl@redhat.com>

typo in header-py.c.

handle errors when constructing lists in the Python bindings

- Various functions in the Python bindings construct lists of objects, but
  assume that all calls succeed. Each of these could segfault under
  low-memory conditions: if the PyList_New() call fails,
  PyList_Append(NULL, item ) will segfault. Similarly, although
  Py_List_Append(list, NULL) is safe, Py_DECREF(NULL) will segfault.

Signed-off-by: Ales Kozumplik <akozumpl@redhat.com>

fix memory leaks in invocations of PyObject_Call

- Various functions in the Python bindings have expressions of the form:

  PyObject_Call(callable,
                  Py_BuildValue(fmtstring, ...), NULL);

  This leaks memory for the case when Py_BuildValue succeeds (it returns a
  new reference, which is never freed; PyObject_Call doesn't steal the
  reference): the argument tuple and all of its components will not be
  freed (until the process exits).

Signed-off-by: Ales Kozumplik <akozumpl@redhat.com>

Oops, newlines dont belong in format extension output

- Thinko in commit 6acef96d9e1eddb588e24f924f6cf9d29ea48d64, duh

Fix brace matching on multiline constructs in perl.req (RhBug:752119)

- /usr/lib/rpm/perl.req scans for the opening brace type on lines, but
  then only scans for closing curly braces ('}') instead of the proper
  losing brace type when that closing brace occures on a different line.
  This means that any use/require statements that occur after the
  multi-line q{} statement but before the first closing curly brace in
  the file will be ignored.

Signed-off-by: Panu Matilainen <pmatilai@redhat.com>

Pull in updated + new translations from Transifex

Teach debugedit about .debug_macro dwarf section (RhBug:759272)

Allow pre- and posttrans to omit interpreter or body (again)

- While most scriptlets have both an interpreter and a body, neither
  is strictly required: body can be omitted in cases like special
  purpose executables (eg -p /sbin/ldconfig) and for interpreter,
  /bin/sh is used if missing. This has been "broken" from somewhere
  around rpm 4.7.x and nobody noticed :)

Cache all but FAIL results from rpmdb header verification

- This makes a huge difference in performance if you have lots
  of unsigned packages (NOTFOUND verify result) or signed packages
  without key (NOKEY verify result) installed, as we previously
  kept checking the same headers over and over again.

Purge rpmdb header verification cache on added pubkeys

- When new keys are added, any previous NOKEY results can become
  invalid: either they become OK or FAIL, and its the FAIL case
  we want to catch.
- For removed keys, previous OK could become NOKEY but that doesn't
  make the header any less valid, so leave the cache alone on removal.

Enable fast-import mode for headers from rpmdb

- Assume our home turf is safe enough for this - in order to reach
  the rpmdb, headers must've gone through the more rigorous checking
  that's done through the rpmReadPackageFile() paths, plus in
  default configuration we'll be doing further verification on the
  header before loading the headers so the risk seems acceptable
  for the speed gain.

Implement "fast" flag to headerImport()

- regionSwab() calling dataLength() on headerImport() is one of the
  busiest paths in rpm, and dataLength() on string types is a very
  expensive call as it has to walk through the string looking for \0's.
  The data size is actually available most of the time by just looking
  at offsets (idea lifted from rpm5.org), which is an order of magnitude
  faster than crawling string data. The downside (there always is one)
  is that with offsets, string data is not validated to contain
  sufficient number of \0's, which means malformed headers could cause
  us to crash, burn and overflow when accessing the string data.
- The new "fast" mode enables offset-based calculation at callers
  discretion, ie if the caller can reasonably assume the header is
  sane (known to be previously validated etc), using the fast-flag
  will make header loading/importing considerably faster.
  For now, only headerImport() will use the fast mode but it might
  make sense to remember the setting in the header and use for other
  operations as well.

Update internal callers to use headerExport(), no functional changes

Add an enhanced interface for unloading, aka exporting, headers

- Most callers need the size of the blob as well, which the unloader
  internals know perfectly well but the interface doesn't support
  passing it. So callers were forced to make a second call to
  headerSizeof() to recalculate the size. Duh.
- Rename and export doHeaderUnload() as headerExport(), update internal
  callers to use the new name. headerExport() is hopefully a bit
  more obvious as a name than headerUnload() which doesn't actually
  undo the effect of headerLoad() for that header, but merely exports
  the data by serializing into on-disk format.
- Header size is not size_t really, its capped to fixed much lower
  size. Use unsigned int to better match reality.

Update internal callers to use headerImport() instead of headerLoad()

- Pass size where possible, this is a bit redundant in places since
  its already checked in various places but wont hurt anyway.

Add an enhanced interface for loading, aka importing, headers

- Unlike headerLoad(), headerImport() takes a blob size argument
  to allow sanity checking the size calculated from the blob itself
  against the "physical" passed-in blob size so its a bit safer.
  Note that header size is capped by various things - its not size_t.
- headerImport() also takes a flags argument to allow controlling
  various aspects of importing.
- Implement "take copy of blob" as a flag to headerImport(), push
  the copying into headerCreate() where we already know the blob
  size, avoiding the need to do double-calculations on headerCopyLoad()..
- headerLoad() and headerCopyLoad() are now just compat wrappers
  around the new interface.

Consolidate header alignment calculations to helper function

- Replace no less than five copy-paste versions of the same thing into
  an inlined helper function. No functional changes.

Optimize string tag length calculations in regionSwab()

- Calling memchr() is circa 35% faster on my system than doing the
  same manually, and this in one of the most critical paths rpm has...

Fix classification of ELF binaries with setuid/setgid bit, oops...

Identify "font collection" (data etc) as fonts also (RhBug:757105)

Make gpg-pubkey headers properly verifiable

- The pubkey headers have been rpm v3 all the way until now, whoops :)
  Pull the actual key part of the header into immutable region and
  stomp a sha1 digest on the result, allowing a (much) better
  verification on loading. This part inspired by stumbling on a
  related discussion on rpm5.org mailing list so credits where...
- Since we only insert either literally constant data or data retrieved
  from the actual key into the immutable part of the header, the
  calculated digest is constant for a given key regardless of where
  and when it was imported. This gives some added verification and/or
  cross-checking possibilities (eg was the imported key exactly the
  same as what shipped etc)

Sanitize makePubkeyHeader() calling semantics

- Create the header in makePubkeyHeader() as the name suggests,
  return the newly created header to caller on success.
- Move the installtime & -tid addition to the "install" part,
  makePubkeyHeader() only does the part that is specific to pubkey
  headers, again as the name suggests.
- No functional changes

Make gpg-pubkey buildtime reflect the public key create time

- Pubkey buildtime has until now been the time of import, which equals
  install time/tid. Which is of course the time when that header
  does get created, but it seems rather redundant to have the same
  thing recorded in three places. Having the key creation time
  easily (easier than un-hexifying the version string, duh)
  available seems like a potentially useful thing. Buildtime is
  "wrong" for this, but ... so is everything.
- With this change, the "meat" of the pubkey headers is now constant
  and repeatable regardless of where and when a key gets imported,
  so we could stomp a digest on it and it'd be unique for that
  particular key everywhere.

Add key userid into gpg-pubkey headers as "packager"

- The userid has only been available in a mildly obfuscated format
  through summary, but this seems like a useful thing to have in
  a directly usable format without requiring callers to parse out
  the gpg() wrapping around it.
- Yes its a wonky mapping, but so is everything else wrt
  gpg-pubkeys, and adding a tag just for this also seems silly.
  Using vendor tag could be another possibility, dunno.

Log an error on attempt to sign V3 packages (RhBug:517818 & others)

- We haven't been able to sign V3 packages in the last decade or so,
  might as well spit out an error on it instead of silently failing.

Fix dribble length calculation on headerLoad()

- When calculating length of dribbles, we need to take into account the
  size up to that point, otherwise the alignment can be wrong causing
  the sizes not to add up.
- With that mystery solved, we can now make the final length check
  as strict as it should be.

Ehm, %pretrans failure shouldn't abort the entire transaction

- Brainfart in previous commit (71c6b06b3f240021f2ece46f9cf7aa891f716710):
  %pretrans failure should only cause that package to fail, not
  abort the entire transaction. Doh.
- Failures are tracked via transaction elements but pre/posttrans
  were specifically filtered out. All we need is removing that filtering
  and the warn-only vs error logic in psm takes care of the rest.
  The transaction.c changes in previous commit were just unnecessary.

Make %pretrans failure fail the install (RhBug:736960)

- %pre and %preun scriptlets cause the package install/erase to fail,
  whereas %pretrans return has simply been ignored ever since its
  introduction somewhere in rpm <= 4.4.x. This is just inconsistent,
  make %pretrans more like the other %pre-scriptlets. %posttrans
  exit code is still essentially ignored, just like %post and %postun etc.
- This can obviously affect installability of existing packages: if
  they have been careless about their %pretrans exit code or outright
  relying on the "yes it spits errors in some situations but who cares"
  behavior, they will now fail to install at all. The way to write
  "portable" %pretrans scriptlets is ensuring non-error exit.

inverse the macro definition condition in c87ad03.

- thanks zpavlas for pointing this out.

python: use the more modern PyCapsule over PyCObject (RhBug:623864).

- rpm.header.new() will still keep accepting PyCObject for now in case a
  client library depends on this.
- involves macro trickery to make rpm buildable against python 2.6 still.

cosmetic: indentation in rpmdbNextIterator.

- the hunk looked confusing with the wrong indentation.

Recognize "<epoch>:" as a part of a label (ticket #117)

- for instance this works now:
  $ rpm -q perl-4:5.14.1-188.fc16.x86_64
  perl-5.14.1-188.fc16.x86_64

Do not attempt running the test suite without fakechroot (ticket #851).

Partially resolves ticket #851.

Avoid XZ dependency in test-suite

- The two "hello" binaries packages used for various multilib checks were
  accidentally using xz payload compression, causing test-suite to
  fail when rpm was configured without xz support. Rebuild them with gzip
  compression instead to avoid silly failures - gzip compression
  support is mandatory, xz is not.

Doh, somehow managed to miss the warnings from these missing includes :(

- Should've been in commit 70f063cb773bedb7d336429d9bc8ed1d4e5d18f4

Make base64 encoding/decoding part of rpmio public API

- Base64 is present in headers and all, it's only reasonable that
  our API users have access to this functionality without having
  to link to other libraries. Even if we didn't want to carry the
  implementation forever in our codebase, we should provide a wrapping
  for this (much like the other crypto stuff) for the reason stated above.
- A bigger issue is that our dirty little (badly hidden) secret was using
  non-namespaced function names, clashing with at least beecrypt. And we
  couldn't have made these internal-only symbols even on platforms that
  support it, because they are used all over the place outside rpmio.
  So... rename the b64 functions to rpmLikeNamingStyle and make 'em public.
  No functional changes, just trivial renaming despite touching numerous
  places.

Eliminate uses of pgpDig in package signing routines

- No functional changes, just eliminates pile of unnecessary allocations
  and other calls, simplifying the code a bit.

Eliminate uses of pgpDig in package reading & signature checking

- No functional changes, just eliminates pile of unnecessary allocations
  and other calls, simplifying the code a bit.

Take advantage of pgpPrtParams() directly in pgpsigFormat() extension

- No functional changes, just bypassing an unnecessary round-trip to
  a function really intended for other purposes, now that we can.

Switch to using rpmKeyringVerifySig() internally

- Change rpmVerifySignature() to take just the signature parameters
  instead of the whole dig (this is an internal API so we're free
  to mess with it) from which it only needed the signature params.
- The internal low-level verifySignature() is thus reduced to
  to a call to rpmKeyringVerifySig() and spitting some silly
  strings to msg.
- With this, keyring can now use and reuse the its internally stored
  pgp key parameters instead of having to parse the same PGP packets
  over and over. As a result, signature checking is faster now. Not
  dramatically so but measurably nevertheless.

Add a signature verification method to keyring

- At least within rpm itself, callers aren't particularly interested
  in the actual key that matches a given signature, they just want
  simple good/bad/nokey answers. This makes life simple for them
  and avoids exposing further rpmPubkey internals through APIs.

Split keyring find-by-signature to helper function, document...

- Document the broken rpmKeyringLookup() behavior / side-effect,
  the new helper uses the values from our stored pgp parameters though.
- Shouldn't make any difference functionality-wise, but we'll need
  the helper function shortly.

Parse pubkey parameters on rpmPubkeyNew() already and store results

- Yet more pre-requisites for separating key and signature management.
  In addition this gains us more thorough initial sanity checking and
  will allow reusing the parameters instead of having to parse
  the same packets over and over again on every single verification
  against this key. Unfortunately rpmKeyringLookup() is so braindead
  it prevents us from doing this right now, we'll need a better
  interface to take advantage of the stored pgp key parameters.

Add an alternative API for parsing PGP packets

- pgpPrtParams() returns a pointer to an allocated pgpDigParams
  on success, eliminating the need for callers to worry about
  freeing "target buffer" on failure and bypassing the now rather
  useless pgpDig middleman. Also allows specifying the expected
  packet type so if we expect a key we'll error out if we get a signature
  instead.
- pgpPrtPkts() is basically just a wrapper to pgpPrtParams()
- Further pre-requisites for separating key and signature management.
- Yes, pgpPrtParams() is a stupid name for this. However all the saner
  ones are already taken for other purposes (for which the names are
  just as bad/misleading, sigh)

Allocate signature and pubkey dynamically within pgpDig on PGP parse

- This way we can parse the whole thing into a private storage first
  and only if its actually successful we return anything through the
  pgpDig. Previously we would return partial garbage on failure
  and/or consecutive calls unless manually "cleaned" as we were
  parsing directly into the pgpDig.
- Dynamic allocation is a pre-requirement separating management of
  keys and signatures: while they walk hand in hand much of the time,
  they come from different sources and have different lifetimes and
  should be managed separately.
- Dynamic allocation of these is also a pre-requirement for handling
  more than one public key, ie mainly subkeys.

Use pgpDigGetParams() in pgpVerifySig() compat wrapper too

- The fewer places that "know" about pgpDig allocation internals the better...

Don't make assumptions about how pgpDig allocates things

- Only call pgpDigGetParams() on the public key once we've at least
  tried to fetch it via rpmKeyringLookup(). This way we dont assume
  things about how pgpDig internal allocation is done - currently
  it does return what's essentially a static pointer into pgpDig,
  but this is not a reasonable assumption for an opaque type.
  No functional changes.

Revert "Take advantage of pgpDigParamsCmp() in rpmKeyringLookup()"

- This only "works" because of other brokenness in the sig/key
  parsing, revert while we can
- This reverts commit 4c51eff3f0fa5e67494b6b192aa1c087f57abed6.

Tolerate NULL key in pgpVerifySignature()

Do not let 'rpm -q foo-' find package 'foo'. (RhBug:488567)

- Includes a test suite for the case.

Signed-off-by: Panu Matilainen <pmatilai@redhat.com>

Eliminate unused params member from pgpDigParams

- Rpm has never used this for anything, amounting to helluva lot
  unnecessary free()'s over the years.

Take advantage of pgpDigParamsCmp() in rpmKeyringLookup()

- Besides eliminating a couple of direct struct accesses,
  pgpDigParamsCmp() does a much more thorough job of comparing
  the parameters than we ever did here (ie less chance for returning
  ok for for a wrong key, although because the interface is as
  braindead as it is, it doesn't make a whole lot of difference)

Use pgpDigParamsAlgo() throughout the codebase

- Tedious but straightforward conversion to use the API instead
  of going to the struct directly.
- Remove digest.h includes where no longer necessary

Add ad API for retrieving algorithm values from digest parameter containers

- Mildly annoying but necessary in order to make pgpDigParams properly
  opaque some day (and also allow sane access to this data)

Add an API for comparing two digest parameter containers

- Lift the digest parameter comparison from librpmsign to rpmpgp.c
  where it really belongs.

And finally, make pgpDig struct fully opaque

- As long as this was exposed and relied on, we couldn't really
  make any changes to how this stuff is stored. Now we have a chance...

Eliminate direct pgpDig accesses from signing code

Eliminate direct pgpDig accesses from pubkey importing

Eliminate direct pgpDig access from package reading code

Eliminate direct pgpDig accesses from lowlevel signature code

Eliminate direct pgpDig accesses from keyring

Add a dumb API to retrieve pubkey / signature params from pgpDig

Take advantage of parsePGPSig() in pgpsigFormat() too

- Doesn't make for less lines in this case but unifying the accesses
  is good anyway.

Unify the parsePGP() variants from package.c and rpmchecksig.c

- Hide allocation inside the helper, automatically free on failure
- Return pointer to the signature parameters on success to simplify
  life for callers
- Don't bother checking or reporting the signature version: the
  pgp parser errors out if it encounters unsupported version and
  does not scrible anything to the version field in that case,
  mumbling about "V0 signatures" is not particularly helpful.
- Log the bad package names from rpmpkgReadHeader() too

Hide pgpDig alloc etc details in the parsePGP helper

- Return a pointer to the signature part on success, hide allocation
  (and free on failure) in the helper. Makes life a little bit
  saner for the callers and limits the places where we access
  the full pgpDig further.

Process all keys and signatures we find

- We still can't store more than one signature / key at a time, but
  since we can easily *process* them without trashing already stored
  values, lets do so to avoid returning errors from legal packets.
  Also pay attention to only store data matching our expected type,
  ie dont store signature data into pubkey parameters and vice versa.
- This mostly affects pubkey packets which can have more than one
  key present and which (can) also carry certification signature
  which we currently do not handle properly at all.

Make pgpPrtPubkeyParams() return an int like all the others do too

- No functional changes, just making the interfaces consistent

Add another pgpVerify variant which takes key and sig as separate args

- pgpVerifySig() is now just a dumb wrapper around pgpVerifySignature()
  which does the real work.
- Update the sole caller to use the new interface instead, deprecate
  the old dig interface.
- First steps towards getting rig of pgpDig which always was a
  strange creature and now is nothing but a nuisance and obfuscation.
  Yes keys and signatures walk hand in hand much of the time, but
  they come from different sources and want to be handled as
  separate data really.

Eliminate couple of unnecessary pgpDig usages

- stashKeyid() only wants the signature, not the whole dig
- dig argument to readFile() was simply unused

Clean up pgpPrtPkts() and friends a bit

- Use decodePkt() for added initial sanity check + grabbing the "main" tag
  instead of duplicating the tag decoding here.
- Call decodePkt() from the main parse loop instead of pgpPrtPkt(),
  and return simple ok/error codes from pgpPrtPkt() and do the
  length calculation in the main loop.
- Besides making the code simpler and more obvious this fixes some
  fishy cases where we previously would've returned 0 for success
  despite there being an error.

Bury all NSS specifics into a separate source

- Not everybody needs/wants the certified monster that NSS is
  (along with all its quirks), this leaves room for alternative
  compile-time selectable crypto backends. Besides that, we get
  a clean functionality separation for the PGP parser and the
  cryptography parts.
- The whole crypto abstraction works inspired + somewhat based on
  Michael Schroeder's similar patch in Suse, kudos.
- TODO: port beecrypt support from Suse to the new interface.

Add a couple of missing includes, masked by NSS headers

Implement PGP key & sig algorithm specific part OO-style

- Collect the crypto algorithm specific bits into new struct
  with function pointers for the necessary set/verify/free methods,
  adjust callers to operate on these. This will allow nice and
  clean switching for different underlying crypto implementations
  with differing supported algorithms etc with minimal internals exposure.
- pgpSignatureNew() and pgpPubkeyNew() never fail to avoid having
  to check for NULL's over and over, they just return a "null object"
  object for which all operations return failure instead.
- This shreds out some of the output --prtpkts used to give. Wouldn't
  be hard to preserve but the stderr fprintf() spew is not very
  useful nor library-like behavior.

Lift RSA/DSA specific signature verification to helper functions

- Use function pointers to call appropriate helper, cleaning up
  pgpVerifySig() a bit. Supposedly no functional changes, just
  further isolation of NSS specifics.
- Pass down pubkey and signature as separate pointers, we'll
  want to get rid of pgpDig eventually as it only obfuscates things.

Lift RSA/DSA key MPI calculations to helper functions

- Same as commit 8473a5b6ce2050a8e899b0be4a012f5724eb0b6d, only for keys
- Use function pointers to call appropriate helper etc, cleaning up
  pgpPrtPubkeyParams() considerably. Supposedly no functional changes,
  just further isolating NSS specifics behind generic interfaces.

Lift RSA/DSA signature MPI calculations to helper functions

- Use function pointers to call appropriate helper, cleaning up
  pgpPrtSigParams() considerably. Supposedly no functional changes.
- Also serves as first step towards isolating NSS-specific bits
  and pieces behind more generic interfaces to enable using
  alternative crypto "engines" later on.

Remove now redundant NULL digparam checks within the PGP parser

- Since the only entry to these is pgpPrtPkts() and that ensures
  the internals are never called with non-NULL digp... Cleans up
  and simplifies the internals.

Arrange temporary storage for parsing if called with NULL dig

- The only known caller with NULL dig is in the rather useless
  wrapping of prtPrtPkts() in the python bindings, but since in
  theory some other callers could use this just for validating
  a PGP packet .. preserve the behavior since it's easy. The
  actual benefit here is that this frees the parser internals
  of having to check for NULL pointers everywhere.

Added sanity checks on pgpPrtPkts() entry

- Error out cleanly on NULL pkts pointer (caller error but not worth
  dying for)
- Error out early if packet is clearly not valid

Eliminate bunch of unused/useless debug cruft from pgp parser

Split digest parameter freeing into a separate helper function

- The data is all the same except for rsa/dsa specific bits,
  to me this calls for a function. We might want to export
  pgpCleanDigParams() or such later on but for now keep it static.
  No functional changes.

Store the rsa/dsa parameters in pgpDigParamers struct directly

- Avoids having to pass around pgpDig pointers in addition to
  pgpDigParamrs pointers. The type (key vs sig) is determined
  early on in pgpPrtPkts() and doesn't change, and the rsa/dsa
  data is associated with that always. No functional changes,
  just makes the whole thing just a little bit cleaner.

Verify PGP signature packet sizes and number of MPIs match expectations

- Similar to commit 807b402d95702f3f91e9e2bfbd2b5ca8c9964ed9 but
  for signature packets: packet must be larger than the "intro"
  structure, and verify the calculated sizes match our expectations.

Eliminate buggy pgpPrtComment()

- Removes another source of stupid bugs: for rpm's purposes we're not
  interested in PGP comment tag contents, and the implementation
  here was unsafe as it assumes there always is a terminating \0
  somewhere in the packet which might not be true for a malformed packet.

Verify PGP key packet sizes and number of MPIs match expectations, part II

- Same as commit 807b402d95702f3f91e9e2bfbd2b5ca8c9964ed9 but for
  retrieving the actual key data instead of its fingerprint.
- Only look inside keys whose pubkey algo we actually support:
  DSA and RSA. Anything else is better left untouched and treated
  as an error to avoid nasty surprises.

Verify PGP key packet sizes and number of MPIs match expectations

- A key packet must be larger than the "intro" structure to have
  room for the trailing MPIs, ie in order to be valid. This also
  ensures we can safely access the pubkey algorithm data.
- Verify the number of trailing MPI's and their total size matches
  the expectations and packet size exactly before bothering with
  digest calculations.
- Also use sizeof(keyid) instead of "magic eight" and memcpy()
  instead of memmove(), the argument keyid and memory returned
  from rpmDigestFinal() cannot overlap.

Verify MPI size is within packet boundary in pgpMpiItem()

- Malformed data can claim the MPI size to be "arbitrarily" large,
  pass packet end pointer to pgpMpiItem() and validate we have enough
  bytes in the packet to contain the MPI before copying.

Remove support for V3 public keys

- V3 keys have been long since deprecated and extinct for all practical
  purposes for more than a decade by now (for example, Red Hat Linux 6.0
  from 1999 was the last RHL to use a V3 key for signing). RFC-4880
  says V3 keys MUST NOT be generated (they have a number of weaknesses),
  but implementations MAY accept them. We choose not to accept them
  anymore, eliminating a code path that would essentially only get
  triggered by malformed packages. The said code path also contained
  a few buffer overflows and other bugs, so its more than just
  "good riddance."
- Worth nothing is that only support for V3 *keys* is removed, V3
  signatures are still supported along with V4 ones.

We dont deal with secret keys, leave them alone

- As we only do OpenPGP signature verification and never signing /
  encrypting content ourselves, we have no need to know anything
  about secret keys. One less place to worry about, tripping up
  on bad data that we dont even try to use would be pretty dumb.

Centralize PGP packet decoding and sanity checking into helper function

- Stricter sanity checking on both old and new packet types - whereas
  new format packets were mostly covered by pgpLen() changes already,
  old format has similar case where malformed packet could cause us
  to read beyond packet (buffer) end.
- Collect the necessary packet data into a struct that's nicer to
  pass around (taking advantage of this mostly left for next steps)