| Age | Commit message (Collapse) | Author |
|---|
|
This changes reflect python-gnupg naming.
With @aarni
|
|
|
|
The KEYMANAGER_FINISHED_KEY_GENERATION event is used to send a welcome
mail to the users, which was causing a new welcome mail when
regenerating a key. We removed the event from regenerate_key method.
We should implement a KEYMANAGER_FINISHED_KEY_REGENERATION event when
it's needed.
|
|
python-gnupg doesn't accept address as parameter for --edit-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
|
|
|
|
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: #9119
|
|
|
|
|
|
|
|
|
|
- Resolves: #9094
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- 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.
|
|
Apparently, this would allow us to run in Elementary OS.
-Resolves: #9076
|
|
for some reason the implementation was returning a list of default flags
for every mailbox, that's incorrect according to the spec.
we have the plan to implement special mailboxes soon, but for now I'm
merging this as it's needed to get nylas prototype working.
- Resolves: #9031
|
|
When content-type was set in the message headers instead of the
MIMEPart (e.g. when not using MIMEParts in the message) bitmask would
ignore it and add the content as text/plain. This caused problems with
Nylas.
To fix this, if the message is not Multipart I'm keeping the
assumption that everything is going to have the maintype of "text" but
copying the subtype from the original message.
This also decodes the original message's payload before attaching the
old content to the new message to make up for the loss of encoding
information.
-Resolves: #9064
|
|
|
|
|
|
These two details were blocking mail service from working in osx.
|
|
- Resolves: #9099
|
|
|
|
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
|
|
we make a distinction between the system-wide bitmask-root, which should
be placed there by the maintainers of whatever packages your
distribution uses, and the bitmask-root that is placed by the bundles
(using polkit).
since the bundles copying over the helper from user-writeable folders
is a potential attack vector, we prefer to use the package's version if
present.
also, if we cannot find either, we abort the launching of the VPN. we've
discussed that this might move to the service initialization instead,
but I think the cases in which this is needed should be rare.
I fix also a corner-case in which we were using getcwd() at import time.
if you execute code and then remove the installation path, this will
raise a traceback in bitmaskctl. I think it's nicer to catch the error
properly when starting.
|
|
|
|
|
|
|
|
|
|
|
|
we're doing something that shouldn't be done, that is relying on private
methods of the imap server implementation.
until I get to cleanup properly and submit patches for the several things
we're patching in the imap server implementation, keeping up with the
evolution of the imap server implementation is the only thing to do.
specially when we want to get 0.10 out of the door asap.
|
|
- Resolves: #9084
|
