| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Check on every fetch of the private key if the expiration is less than
two months before it expire. And extend the expiration if needed.
- Resolves: #8217
|
|
We are not planning to regenerate keys (for now), only to extend the
expiration date.
|
|
|
|
We were considering to reset the sign_used flag to force the new key to
be resend as attachment in forthcoming emails. Although, this is not a
good solution, because we'll lose information about which keys the
client has signed.
|
|
Previously, we were sending the key attached as long as the contact
hasn't replied back. But with new key replace scenarios, we need to updated
the contact keyring with the new key.
We can implement autocrypt or similar in the future, but for now, let's
send the key attached on every email.
|
|
This was intended to offer the option of only extend the old key and
not change it for a new one. However, we don't plan to use this
behavior anymore.
|
|
|
|
This changes reflect python-gnupg naming.
With @aarni
|
|
Previously, new_expiry_date was calculated by the key creation date + 1
week, but the proper behavior is today + 1 week, accordingly with gpg
behavior.
|
|
- private key is not allowed to be fetched remotely
- fetch_remote needs to be specifically set
- if a new key is fetched (ie different KeyID), the validation
rule applies
|
|
date is extended
- this is required so that the key is re-attached to the first
outgoing email to all users who already have the expired key.
|
|
- private key is not allowed to be fetched remotely
- fetch_remote needs to be specifically set
- if a new key is fetched (ie different KeyID), the validation
rule applies
|
|
|
|
is renewed
- there is only one private inactive key that is the key
expiring last among all inactive keys
- if there is an inactive key, decryption with it, is tried
if it fails with the current active key.
|
|
- this flag is used by leap.mail to attach the new key
|
|
- if current key pair is expired, it'll be extended for a day first
- new key pair will be signed by the old key
|
|
- extends key pair (unlocked from soledad)
- extension period is counted from key creation date
|
|
|
|
- Resolves: #9030
|
|
- Resolves: #9023
|
|
There was a mismatch on the return values of Nicknym class and the
expectations. As most of the code was expecting an OpenPGPKey, but it
was returning the json as it came from the nickserver. Now is just
returning the key data.
|
|
There was common situations where two provider instances where running
in parallel. And was creating weird errors (like getting wrong api_uri)
because the bootstrap deferreds were global but the Provider objects
not.
I don't like much singletons, but I think now is simpler than before.
- Resolves: #9073
|
|
node-mail chokes if we don't.
|
|
- Resolves: #9003
|
|
|
|
Deal as well with sending key if key is outdated in the providers nicknym.
- Resolves: #8819, #8832
|
|
|
|
- Resolves: #8881
|
|
|
|
I've removed the add_listener method because it's not used anywhere.
|
|
When setting the listeners in the IMAP Folder, we avoid setting more
than one listener for the same imap mailbox (because in some situations
we were registering way too many listeners).
this was making the pixelated inbox registering the notification and
therefore the imap mailbox not being registered.
this MR also refactors the way pixelated is initialized, so that it
avoid creating a second Account instance. In this way, we make sure that
the pixelated mua and the imap server share the same collections for a
given mailbox, and therefore any of the two is able to get a
notification whenever the other adds a message to the mailbox.
- Resolves: #8846, #8798
|
|
mock a renamed method.
|
|
There was a test in the Keymanager refresher that was testing the
randomness of the refreshing intervals. It was producing a bunch of
intervals and checking that all of them where different. This test
(rarelly) fails some times, but this is not a sign of bad randomness.
- Resolves: #8813
|
|
In addition to the UnicodeError exception in _process_decrypted_doc
function, we have added ValueError to the exception list so that we can
catch any error in JSON parsing, specially a 'NODATA' error that we were
getting with some of the emails.
This is in reference to issues -
https://github.com/pixelated/pixelated-user-agent/issues/908 &
https://github.com/pixelated/pixelated-user-agent/issues/981 - to ignore
documents that have this problem and not have Soledad try to sync them
again and again.
with @deniscostadsc
|
|
with @deniscostadsc
|
|
Check if a new fetched key was signed by a old key with the same address.
Please do not merge before: https://github.com/isislovecruft/python-gnupg/pull/150
- Resolves #8112
|
|
|
|
- some pep8 problems
- some confusion with old and new code after merging
from old keymanager
|
|
disabled some tests that were failing, for some reason the twisted
logger doesn't want to be patched?
besides, I don't think it's a good idea to rely on log information for
tests. what is it really that we were trying to test there?
|
|
Port of the original commit:
8f1fe8dd4a54fd2bdda2fc78c339ce9b3d0fc331
by Zara Gebru that introduced updating keys in the background.
This was made in the legacy leapcode/keymanager repo, but was lost in
the merge to the unified bitmask-dev.
Original commit message follows:
--------------------------------
- refresh random key in random time
- add get key by fingerprint
- refactor nicknym methods to own file
- tests
- note this do not include a check for
revoked key, since that need some changes
in gnupg
- Related: #6089
|
|
Missing yield from _insert_key_docs, which returns a Deferred, was
causing tests to fail.
|
|
Before we used to have content_doc.content_type = 'text/plain;
charset="utf-8"'.
Currently, we have content_doc.content_type = 'text/plain'.
This change will give us, on top of that: content_doc.charset = 'utf-8'.
One can reconstruct the original one using .content_type and .charset.
|
|
|
|
|
|
this is a port of commit 2d9bec78f in the legacy keymanager repo.
Additionally, I'm here separating benchmarking tests from the main tox
run.
In my machine several of these benchmarking tests seem to be broken, due
to issue https://github.com/isislovecruft/python-gnupg/issues/157
|
|
|
