| Age | Commit message (Collapse) | Author |
|---|
|
|
|
not that I really want to keep qt5 for a long time, but this seems the
short way to a working systray for the next release.
|
|
|
|
This adds a make target which allows for headless builds. It runs
pyinstaller and copies some required files.
|
|
Thunderbird produces message ids with '-' in them.
|
|
To get the status of a single message providing it's mailbox and
message-id. For now it only returns encryption/signature status.
- Resolves: #6914
|
|
To have consistency with all API calls related to messages and start all
of them with msg_*
|
|
- To be able to call bitmask.js from Thunderbird (for the Bitmask
Thunderbird extension), we need to set `api_url' and also read the
`authtoken' file from disk. This commit adds support for that and
restricts the changes by using window.location.protocol.
- Add function for fetching bitmaskd status.
Signed-off-by: Ruben Pollan <meskio@sindominio.net>
|
|
|
|
This deferred was not used anywhere, but it was called twice.
Provider is a singleton so multiple logins into the same provider where
producing it to be called mor than once.
- Resolves: #9171
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Chech the hash of the installed bitmask root and sign as not installed
if doesn't match the one we have in the bundle. Also for running
bitmask-root, if there is more than one (in /usr/local/sbin and
/usr/sbin) run the one with higher version number.
- Resolves: #9020
|
|
using virtualbox executor for gitlab-runner
|
|
|
|
Pin the provider.json and the ca cert for the public providers.
- Resolves: #9074
|
|
|
|
apparently, lzo and mbedtls do not like gpg.
|
|
this will be used by bundles, and it's needed now that ifconfig and
other net-utils are being deprecated.
|
|
|
|
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
|
|
|
|
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.
|
|
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.
|
|
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
|
|
|
|
|
