There were issues in trying to do CPU tuning (see #279 and #157 for
examples).
The simpler approach, given the capacity of modern hardware and the
antiquity of OpenPGP's S2K parameters, is just to always use the
maximum S2K settings. This also saves us some CPU from running
calibration steps.
This commit also drops the test for #157 entirely, because that test
embeds assumptions about the way that calibration is done that are no
longer true.
If this is merged, we should close#279 without merging it.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Similar to the concerns in #297, there are noisy warnings produced
when encrypting data to or signing data with a primary key, if a
subkey is ultimately what ends up being used:
```
./generate-test-vectors:279: UserWarning: Key F231550C4F47E38E does not have the required usage flag EncryptStorage, EncryptCommunications; using subkey 4766F6B9D5F21EB6
encmsg = alice_key.pubkey.encrypt(payloadmsg, cipher=cipher, sessionkey=sessionkey)
```
This change converts these warnings to debug information.
In #298, we just removed the noisy warnings on consuming data -- the
caller really has no choice in how to consume the data, so there's no
point in sending them alerts. Either we can decrypt or verify with
the primary key or one of the subkeys, or we can't.
But in the situation where the caller is producing data -- signing or
encrypting -- we might want be a little bit noisier, because the user
really might have some obscure reason that they prefer to use a
specific subkey that the library isn't in a position to understand.
So giving the user a hint at debug-level about what's going on is
probably reasonable.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Commod0re requested this change, in line with the change I requested
in #297 about decrypting with subkeys. I think it's the right thing
to do.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
This warning doesn't appear to be actionable, and is likely to only
encourage users of PGPy to do extra gymnastics before calling
decrypt().
Closes#297
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
When the Signature Creation Time was supplied to the signing function,
we were ignoring the fact that it might have a different timezone than
UTC. But the stored timestamp is supposed to always be in UTC, so it
should roundtrip correctly.
This includes a test to ensure that we don't end up with a regression.
Closes: #291
These helper functions make it easy to verify which third-party
certifications are currently attested to by the primary key.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
This makes the No-modify flag for Key Server Preferences actionable,
by allowing the primary key holder the ability to indicate which
third-party certifications are acceptable for redistribution.
See https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/20 for
more details.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
In rfc4880bis version 08, we have a specification for the Intended
Recipients subpacket, which can help to defend against certain kinds
of subtle attacks that involve re-wrapping a signed message to encrypt
it to someone else.
See https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/19 and
https://0xacab.org/schleuder/schleuder/issues/158 for more details
about this subpacket.
Assuming that `alice` is the PGPKey of the sender, and `bob` is the
PGPKey of the recipient, The simplest way to use this when generating
a message in PGPy is:
```
msg = PGPMessage.new('test message')
msg |= alice.sign(msg, intended_recipients=[bob])
msg = bob.encrypt(msg)
```
And it can be checked on Bob's side with:
```
cleartext = bob.decrypt(msg)
for sigvfy in alice.verify(cleartext).good_signatures:
if bob.fingerprint in sigvfy.signature.intended_recipients:
print("meant for Bob")
```
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
This function allows the user to easily get the canonicalized
bytestring representation of the signature. This is useful for making
third-party confirmation signatures (sig type 0x50), as well as
Signature Target subpackets (subpacket 31), and other pointers to
specific signatures.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Key Server Preferences (RFC 4880 §5.2.3.17) is a bitfield, more like
Key Flags (RFC 4880 §5.2.3.21) than Preferred Hash Algorithms (RFC
4880 §5.2.3.8).
The caller should be able to invoke this as a set when calling
PGPKey.certify().
This patch also improves documentation for PGPKey.certify() to
indicate how to pass in these flags.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
While #262 made it possible to set creation times in some places, it
missed some others.
This makes the created= argument functional in all the contexts where
it could be useful.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
GnuPG has been including hashed Issuer Fingerprint subpackets by
default in signatures since 2016-10-08. This subpacket makes it
possible to distinguish between a bad signature and a signature that
we happen to not have the issuer's key for.
We add it here for normal signature, certifications, and revocations,
unless the signer explicitly requests that it not be included.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Over in #271, we discussed simplifying the lower-level UserID packet
object, and moving the <name,comment,email> splitting logic up into
the higher-layer PGPUID API.
This patch does that work, and also exposes an additional
PGPUID.userid property, which is the full UTF-8 string.
If this gets merged, it will obsolete #271.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
The exportable flag is already implemented, but it is not documented
in the docstring. This addresses that concern.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Some older versions of the python bindings for GPGME produce python
objects that reference the underlying gpg.Context objects.
When a gpg.Context is used in a "with" clause, it is disposed of at
the end, and any resulting objects that reference that context object
are dangling.
This doesn't seem to be a problem with gpgme 1.13.1 (the current
version), but i was seeing segfaults in the PGPy test suite when used
with gpgme 1.12.0 :(
These fixes should make PGPy's test suite more robust against this
kind of failure.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Without this change, the warning about IDEA is not properly rendered
in html, and ./setup.py build_sphinx itself produces a warning:
…/pgpy/constants.py:docstring of pgpy.constants.SymmetricKeyAlgorithm.IDEA:1: WARNING: Content block expected for the "warning" directive; none found.
…/pgpy/constants.py:docstring of pgpy.constants.SymmetricKeyAlgorithm.IDEA:2: WARNING: Explicit markup ends without a blank line; unexpected unindent.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
This is done by setting 'crosssign' to False in the prefs parameter to
the sign function.
You probably don't want to use this feature! It is likely to make
OpenPGP certificates without cross-signatures that some other
implementations will reject.
