* Drebs wrote a patch to add '--list-packets' functionality to python-gnupg,
and I would like to include it without deleting its history. This is a
rather strange merge, however, because not only does it merge an entirely
different repo, but also an entirely different repo of an entirely different
project, Soledad.
* The file we wanted was src/leap/soledad/util.py, and the commands taken to
complete this merge were as follows:
git clone git@github.com:isislovecruft/soledad.git soledad-copy
cd soledad-copy
git remote rm origin
## Remove the files and any history which mentions those files which are
## not in the src/leap/soledad directory:
git filter-branch --subdirectory-filter src/leap/soledad -- --all
## Then do the same for every file and subdirectory which is not util.py:
git filter-branch -f --index-filter 'git rm --cached --ignore-unmatch \
src/leap/soledad/__init__.py' HEAD
git filter-branch -f --index-filter 'git rm --cached --ignore-unmatch \
src/leap/soledad/server.py' HEAD
git filter-branch -f --index-filter 'git rm --cached --ignore-unmatch \
src/leap/soledad/shared_db' HEAD
git filter-branch -f --index-filter 'git rm -r --cached --ignore-unmatch \
src/leap/soledad/tests' HEAD
git filter-branch -f --index-filter 'git rm -r --cached --ignore-unmatch \
src/leap/soledad/backends' HEAD
cd ..
git clone git@github.com:isislovecruft/python-gnupg.git python-gnupg-copy
cd python-gnupg-copy
git remote add soledad ../soledad-copy
git fetch soledad
git checkout develop
git merge -S --no-ff soledad/master
* https://bugs.g10code.com/gnupg/issue1179
* This bug has resurfaced several times in GnuPG's history, and as far as I've
understood it, it is due to a generation or an attempt at parsing a .gpg
file (a message/file, or one of the keyrings) which is generated/formatted
such that the GnuPG data packets comprise a certain number of bytes (562
bytes precisely) and/or the demarcation signal (two equal signs, '==') of
the trailing ctb (I assume 'ctb' stands for cipher text bytes; it's
everywhere in GnuPG's sourcecode) CRC checksum ends up on its own line, like
so:
-----BEGIN PGP MESSAGE-----
hQIMA1DJjYe0ARAPAQ/6A7PWiyfiBIpbJ7+XbaptYPB0muoi3rXF4cuIXU37uDug
04Cck+8u9hcMjhYd0pN6zJMJLO8CUOdUKJblpxPSYc7yanJDc33n1jsdkr7XNbbz
Xjh1z3EJZPhhp3YE7lqgnTTXQsGUihnhwiQqsuNgCVZfSwXpVFa+IHC+/AXhAPLl
/BoY6+YOupD8G4bOUCU/XBvQp8uH9kh9n9101+6SopJ94H354X0PtZJs5BISCW7g
/tUxAqxLesDaZkHF91HL7AJE8+/pheTc8vHGP+Zu8/Q5Lr+GW2cUrCXXxUV/xRIh
P7t7WDdU5V1BXyughEBP7Jwr8G3llKr42ZRVgvOyFIe+sMVibq2dEhxJr/sjR0j6
lYws+tZVWbmuxOnMDCjgIaEverU0nnd1SqQ/tS7yFh8lpBfMay2IdVVh+Bi3zDeT
Kb/h3tCjG0++h5FuG8UBWv13LRlfcF817ShnwoG80y4cESgCXxZGkd9DRExH8wy8
VJpIaVKiaZs5jlHLHX4JWy2IVmEvk/6xwZZwrNV4sGYzDGkxHLyTUUQu/NOkCtAb
2Zs9mGrtsSGSoP6lfKDk9hh8fJtPGxGzIezVR9WXYKeYAfGZOzMI1Ji1jF1fO21G
KqTaF2WnWfaWmsuICTiBntgNntZRsXwmMNkcBt5LVK8uRpWQqIQmAkN4vl6SgovS
QAHrC6D9mUmoNvKcS71aH4uZjkfYtNmgp8i5cmTP6UaGouVeqzDCtK/vIy1V/iaX
89vcdsILlMMVB/10Rtscyus
==suET
-----END PGP MESSAGE-----
When this happens, GnuPG *stops* parsing entirely before the CRC checksum
following the '==', and thus the next time it starts parsing again the
first thing it gets is the end header '-----END PGP MESSAGE-----'.
* My solution for hacking around this is to export directly to a keyring,
which can either be one we create for this purpose, or the keyring set as
self.pubring. I do not know yet if this will affect --list-keys.
Isis Lovecruft
Isis Lovecruft