schleuder issueshttps://0xacab.org/schleuder/schleuder/-/issues2020-02-08T14:03:27Zhttps://0xacab.org/schleuder/schleuder/-/issues/350Introduce systemd features to improve security2020-02-08T14:03:27ZgeorgIntroduce systemd features to improve securitysystemd supports features like `ReadOnlyDirectories` and dropping capabilities. We should make use of them, to improve the security of the overall system.
One caveat, tough: AFAIK, different versions of systemd support different "dropp...systemd supports features like `ReadOnlyDirectories` and dropping capabilities. We should make use of them, to improve the security of the overall system.
One caveat, tough: AFAIK, different versions of systemd support different "droppable" capabilites. If one is using a list of capabilites and only one of them isn't supported, all of them are ignored.
This needs research and further discussion, for now that's just a starting point to keep track of it (and to counter my bad memory..)Next Big Thinggeorggeorghttps://0xacab.org/schleuder/schleuder/-/issues/346Add a possibility to reveal which e-mail-adress has administrative privileges2018-05-03T22:35:21ZppAdd a possibility to reveal which e-mail-adress has administrative privilegesAs far as I know, if one uses e-mails with special keywords to administrate an encrypted list, there is no possibility to get to know which e-mail-adresses have administrative rights and which not. This is not a problem as long as there ...As far as I know, if one uses e-mails with special keywords to administrate an encrypted list, there is no possibility to get to know which e-mail-adresses have administrative rights and which not. This is not a problem as long as there is only one administrator. But as soon, as there are at least two of them, they cannot know if the other one added someone with administrative privileges.
My suggestion is: add this information for the keyword x-list-subscriptions. The information whether an e-mail-adress is disabled for message distribution or not is included in there already.
What do you think?https://0xacab.org/schleuder/schleuder/-/issues/345Cc: headers not copied when resending a mix of encrypted and unencrypted emails2020-01-06T16:08:11ZsajolidaCc: headers not copied when resending a mix of encrypted and unencrypted emails## Expected Behavior
When sending emails with multiple `x-resend-cc:` commands, each receiver should receive an email with `Cc:` headers corresponding to all the receivers put in `x-resend-cc:`, independently of whether the email they r...## Expected Behavior
When sending emails with multiple `x-resend-cc:` commands, each receiver should receive an email with `Cc:` headers corresponding to all the receivers put in `x-resend-cc:`, independently of whether the email they receive is encrypted or not.
## Actual Behavior
When using two `x-resend-cc:` commands, one to address A that gets resent encrypted and another to address B that gets resent unencrypted, then neither A nor B get the other address in the `Cc:` headers of the email they receive.
## Steps to Reproduce the Problem
1. Send an email with two `x-resend-cc:` commands: one to address A for which there is a public key in the keyring of the mailing list and another to address B for which there is no public key in the keyring of the mailing list.
2. Check the `Cc:` headers of the emails received by address A and B.
## Specifications
- Version: 3
- Installation method (package, gem...): I would have to ask my sysadmins
- Mail client version: Thunderbird 52.7.0Next Big Thinghttps://0xacab.org/schleuder/schleuder/-/issues/332schleuder will attempt to send email to an address it cannot encrypt messages to2018-03-16T13:27:12Zfleishschleuder will attempt to send email to an address it cannot encrypt messages toToday I found a few messages stuck in my postfix queue. At first glance they just looked like the remote SMTP server was to blame, but upon closer inspection I realized I had fat-fingered an email address and subscribed someuser@somedoma...Today I found a few messages stuck in my postfix queue. At first glance they just looked like the remote SMTP server was to blame, but upon closer inspection I realized I had fat-fingered an email address and subscribed someuser@somedomain.com instead of someuser@somedomain.org. The schleuder list had **no key** for the erroneous email address someuser@somedomain.com, but was still attempting to send a message to the subscriber in spite of the following Send control list option being set:
`
Send encrypted only?
Only send messages if they can be encrypted to their receiver.
`
I didn't think to crack open the message in the queue to verify what it was, but thinking through it logically I'd expect they were actual messages bound for the list and encrypted to the proper key for someuser@somedomain.org, despite being emailed to someuser@somedomain.com). Obviously this use case arose out of user error, but it got me wondering if there shouldn't be an extra check (perhaps as an option) that the key associated with a subscriber email has at least 1 matching email userID.https://0xacab.org/schleuder/schleuder/-/issues/329feature request: allow schleuder to send a welcome message to new subscribers...2020-01-05T13:09:06Zfleishfeature request: allow schleuder to send a welcome message to new subscribers with the list public key attachedThis idea came up in testing a use case where the list public key wouldn't necessarily be uploaded to the key server. While sending email to listname-sendkey@listhost.domain.com works fine, for less technical users it would be useful to ...This idea came up in testing a use case where the list public key wouldn't necessarily be uploaded to the key server. While sending email to listname-sendkey@listhost.domain.com works fine, for less technical users it would be useful to preempt the need for this step and just have them receive a copy of the public key along with a brief message about the list and maybe even how to interact with the list via email commands. Maybe even an option to include a blurb about the web interface, since not all deployments may have that available. I'm thinking something along the lines of how mailman mailing lists send welcome messages to new subscribers, but also tailored to make getting started with schleuder easier for the masses who may be less technically inclined.https://0xacab.org/schleuder/schleuder/-/issues/328Show name if no email is present in UID and proposal for new "oneline" output...2020-01-02T22:02:43ZpazShow name if no email is present in UID and proposal for new "oneline" output formatIn #227 we chose a "oneline" format to represent a key in a single line. Apparently not including an email address is more common than expected. It doesn't produce actual error if the email misses from the description but it creates conf...In #227 we chose a "oneline" format to represent a key in a single line. Apparently not including an email address is more common than expected. It doesn't produce actual error if the email misses from the description but it creates confusion (see e.g. #325).
Thus I suggest to include the "name"-part of the UID if no "email" is present.Next Big Thinghttps://0xacab.org/schleuder/schleuder/-/issues/314Neater on-body header2020-01-02T23:39:29ZemmapeelNeater on-body headerCurrently, headers in Schleuder 3.2.1 are most times:
```
From: name <email@example.com>
To: schleuderlist@sekret.org
Cc:
Date: Wed, 31 Jan 2018 19:50:02 -0200
Sig: Unsigned
Enc: Unencrypted
```
Then you need to tidy ...Currently, headers in Schleuder 3.2.1 are most times:
```
From: name <email@example.com>
To: schleuderlist@sekret.org
Cc:
Date: Wed, 31 Jan 2018 19:50:02 -0200
Sig: Unsigned
Enc: Unencrypted
```
Then you need to tidy up the emails when you answer, if you want to keep important information (like author)
etc.
Also, if you for example are answering an external email you will need to add the new [complain censored] mandatory X-LIST-NAME on your answer, so I propose the order of the headers be:
```
To: schleuderlist@sekret.org
Cc:
From: name <email@example.com>
Date: Wed, 31 Jan 2018 19:50:02 -0200
Sig: Unsigned
Enc: Unencrypted
```
Also I would like not to get a whole line saying I have no information. So I think
- I don't need the CC: header if the email has no CC
- If the email is unsigned and unencrypted I would move this information to the From line
Like this:
```
To: schleuderlist@sekret.org
From: name <email@example.com> unencrypted - unsigned [yeah small caps]
Date: Wed, 31 Jan 2018 19:50:02 -0200
```
And if it is the kind of emails I like to receive, then:
```
To: schleuderlist@sekret.org
From: name <email@example.com> ENCRYPTED - SIGNED WITH 239874652878ETCFINGERPRINT
Date: Wed, 31 Jan 2018 19:50:02 -0200
```https://0xacab.org/schleuder/schleuder/-/issues/311X-ADD-KEY results message could be more informative2020-01-02T23:42:13ZemmapeelX-ADD-KEY results message could be more informativeUsing Schleuder v3.2.1
When adding a new key to schleuder's keyring, now I get an answer:
```
Import result:
[key fingerpprint]: imported
```
Previous versions where adding:
```
pub 4096R/[censored] 2017-06-29
uid [censored] <[ce...Using Schleuder v3.2.1
When adding a new key to schleuder's keyring, now I get an answer:
```
Import result:
[key fingerpprint]: imported
```
Previous versions where adding:
```
pub 4096R/[censored] 2017-06-29
uid [censored] <[censored]@riseup.net>
sub 4096R/[censored] 2017-06-29
sub 4096R/[censored] 2017-06-29
--> imported
ImportResult.inspect:
=> #<GPGME::ImportResult:0x[censored] @imports=[#<GPGME::ImportStatus:[censored] @result=0, @fpr="[censored]", @status=1>], @imported=1, @secret_read=0, @new_user_ids=0, @not_imported=0, @no_user_id=0, @new_revocations=0, @unchanged=0, @secret_unchanged=0, @considered=1, @new_signatures=0, @imported_rsa=1, @secret_imported=0, @new_sub_keys=0>
```
I would like to get back:
* The keyids of the imported key
* The type of key, because ofr example if it is a 1024 dsa key I don't want to use it
* The expiration date
And get also:
* A better ImportResult, specially a message instead of @status=1
* Maybe the mesage could include the gpg --with-fingerprint --list-keys [keyid] information?
* It would be nice to know if this address is subscribed to the list, as a memberhttps://0xacab.org/schleuder/schleuder/-/issues/294provide easy+secure backup/restore mechanism2018-10-28T11:48:23Zdkgprovide easy+secure backup/restore mechanismWhat sorts of things does a schleuder installation need to back up to protect against bad things happening?
how can it avoid having the backups be a source of weakness to the encrypted mailing list itself?
how can we make it easy to re...What sorts of things does a schleuder installation need to back up to protect against bad things happening?
how can it avoid having the backups be a source of weakness to the encrypted mailing list itself?
how can we make it easy to restore a schleuder instance from such a backup?
-----
It's tempting to just say "copy everytihng in `/etc/schleuder` and `/var/lib/schleuder`", but that would mean copying secret key information, API keys, etc, which would make the backup itself a really tempting target for the purposes of decrypting messages sent to a schleuder list, or for compromising access to the REST api.
In the event of a catastrophic failure, it might make the most sense to
* generate a new key for each list
* to revoke the old keys
* to re-generate all API keys
If we want to streamline this process, then the backup might need to contain revocation certificates for the keys in question (not the secret keys themselves) and avoid shipping API keys entirely. The backup might also not need to contain all the keyrings, or maybe just pointers to them?
I'm imagining this as something that might even be doable from the `schleuder-cli`, so that the client connecting to the REST API could make a backup of configuration of a schleuder installation, and that backup could then be replayed upon reinstallation by the new schleuder user to get back to the same state (albeit with different keys).Futurehttps://0xacab.org/schleuder/schleuder/-/issues/284Throttle concurrent Schleuder-processes2020-01-05T13:16:46ZpazThrottle concurrent Schleuder-processesWe should throttle the number of parallel Schleuder-processes in order to avoid having processes killed due to memory-shortage when a lot of emails are being delivered at once.
With this we would not need an incoming queue anymore (#75).We should throttle the number of parallel Schleuder-processes in order to avoid having processes killed due to memory-shortage when a lot of emails are being delivered at once.
With this we would not need an incoming queue anymore (#75).https://0xacab.org/schleuder/schleuder/-/issues/278Introduce and ship apparmor profile2020-01-02T23:33:05ZgeorgIntroduce and ship apparmor profileCurrently this does get evaluated, but it seems, Debian will enable apparmor by default in the next release buster. We should ship a profile to make use of that and strengthen the security of the overall system.Currently this does get evaluated, but it seems, Debian will enable apparmor by default in the next release buster. We should ship a profile to make use of that and strengthen the security of the overall system.Next Big Thinggeorggeorghttps://0xacab.org/schleuder/schleuder/-/issues/247Make LoggerNotification#notify_admin respect send_encrypted_only2020-01-04T19:41:22ZpazMake LoggerNotification#notify_admin respect send_encrypted_onlyCurrently it sends out messages in the clear if no usable key is found for the respective admin, regardless of the list's setting of `send_encrypted_only`.Currently it sends out messages in the clear if no usable key is found for the respective admin, regardless of the list's setting of `send_encrypted_only`.Futurehttps://0xacab.org/schleuder/schleuder/-/issues/243Add a global footer for administrative mails2020-01-04T12:31:04ZMuri NicanorAdd a global footer for administrative mailsquoting @n_g from #240
> I see how it can be helpful and I'm thinking whether it could make sense to offer a global configuration option to add a
> footer for administrative emails, where one could add your text example pointing the we...quoting @n_g from #240
> I see how it can be helpful and I'm thinking whether it could make sense to offer a global configuration option to add a
> footer for administrative emails, where one could add your text example pointing the webschleuder installation or e.g.
> further documentation. Or just make a global configuration option with a webschleuder address and if that one is set, the
> footer gets added. I think adding also a link to the online documentation would be helpful.
one could also add a contact email of the schleuder providerFuturehttps://0xacab.org/schleuder/schleuder/-/issues/242Improve the text of the administrative emails2020-01-04T12:31:00ZMuri NicanorImprove the text of the administrative emailsThe administrative emails are a bit scarce in their explanation what they are about. Especially for admins that don't know much about gnupg keyrings or mailinglists. It would be great to extend their content, i.e.:
> Hello
>
> This is ...The administrative emails are a bit scarce in their explanation what they are about. Especially for admins that don't know much about gnupg keyrings or mailinglists. It would be great to extend their content, i.e.:
> Hello
>
> This is an automated mail from the listname@domain.tld mailinglist, which you're are an administrator of.
>
> While doing a regular check of all subscriptions of list listname@server.tld we were pinning a matching key
> for the following subscriptions
>
> ...
>
> This means ...
see also the initial ticket schleuder/schleuder#240Futurehttps://0xacab.org/schleuder/schleuder/-/issues/236allow memory hole headers as anti-replay mechanism if user omits x-listname2024-03-11T18:25:43Zdkgallow memory hole headers as anti-replay mechanism if user omits x-listnamememory hole provides signatures over relevant headers. if a cryptographically-signed To: header includes foo-request@example.org, then there is no need to require the message to contain x-listname to defend against replay attack (as not...memory hole provides signatures over relevant headers. if a cryptographically-signed To: header includes foo-request@example.org, then there is no need to require the message to contain x-listname to defend against replay attack (as noted in #158). memory hole is more convenient (for MUAs that already implement it), so it would be a usability improvement to accept it as a legit anti-replay mechanism.Future2020-12-01https://0xacab.org/schleuder/schleuder/-/issues/235Make start_ and stop_smtp_daemon tear down also on failing tests2017-07-14T07:55:24ZngMake start_ and stop_smtp_daemon tear down also on failing testsAt the moment, tests that require a smtp daemon start and stop that daemon at the beginning and the end of the test case.
This is a) cumbersome and b) it has the disadvantage that if an expection fails, rspec aborts the further executio...At the moment, tests that require a smtp daemon start and stop that daemon at the beginning and the end of the test case.
This is a) cumbersome and b) it has the disadvantage that if an expection fails, rspec aborts the further execution of the test case and hence the smtp daemon is never stopped and the next test execution fails, because a new smtp daemon can't bind on the testing port, as the previous one is still listening there.
I guess, the plumbing and boilerplate for these kinds of tests could be improved with onboard mechanisms of rspec.https://0xacab.org/schleuder/schleuder/-/issues/228Distinguish between a Subscription's key and a random keyring entry in check_...2020-01-04T12:29:22ZngDistinguish between a Subscription's key and a random keyring entry in check_keys notificationAt the moment keys check notifies about all keys in your keyring.
The output should be split in 2 sections: Keys of subscriptions and all other keys in the keyring. This way an admin can easily identify if something urgen needs to happe...At the moment keys check notifies about all keys in your keyring.
The output should be split in 2 sections: Keys of subscriptions and all other keys in the keyring. This way an admin can easily identify if something urgen needs to happen.
For a list that e.g. is an address of a project, that is especially used to communicate with addresses outside of the list, the majority of the keyring might be random keys that were used once in a while, but are not relevant for the list to function.
While `refresh_keys` should still refresh all these keys, I don't think keys check should report anything about them, as otherwise lists as decribed before will always get a huge list of expired/revoked keys.
As noted in #227 the output must also be more descriptive and e.g. divided by keys for subscriptions and keys not related to a subscription. And then we could only send out the check email if any of the subscriptions is affected.Futurehttps://0xacab.org/schleuder/schleuder/-/issues/220Notify admins on missing keys for subscriptions2020-01-04T12:27:49ZngNotify admins on missing keys for subscriptionsIf a list is configured to send out only encrypted emails, but a subscription doesn't have a key selected, schleuder will notify the subscription about that problem. However, admins - who are usually aware of what to do - are not notifie...If a list is configured to send out only encrypted emails, but a subscription doesn't have a key selected, schleuder will notify the subscription about that problem. However, admins - who are usually aware of what to do - are not notified.
=> Admins should be notified as well about missing keys.Futurehttps://0xacab.org/schleuder/schleuder/-/issues/216provide minimal API access for mail transport agents2020-01-02T23:41:56Zdkgprovide minimal API access for mail transport agentssome mail transport agents (e.g. exim4) have to decide whether to route a message to schleuder or not, without having privileges to access the schleuder installation directly.
It'd be great if there was a minimal-privilege level for the...some mail transport agents (e.g. exim4) have to decide whether to route a message to schleuder or not, without having privileges to access the schleuder installation directly.
It'd be great if there was a minimal-privilege level for the schleuder api that would allow only information about what e-mail addresses schleuder expects to accept. Then the MTA could use that api query to decide whether to route mail to schleuder or not.
the postfix integration we already have works around this because it's running as a user with enough privileges to directly query the sqlite3 schleuder database, fwiw.https://0xacab.org/schleuder/schleuder/-/issues/204Help users to replace their own key2020-01-05T13:20:22ZpazHelp users to replace their own keyReplacing a key for a user is a common task and should be easier. Essentially it's three steps:
1. import the new key
2. assign the fingerprint of the new key to the subscription
3. delete the old key (optional)
Deleting the old key sh...Replacing a key for a user is a common task and should be easier. Essentially it's three steps:
1. import the new key
2. assign the fingerprint of the new key to the subscription
3. delete the old key (optional)
Deleting the old key should only happen if X-DELETE-KEY is not listed as admin-only.
Users should be able to use this feature for their own subscription. Admins should be able to use it for any subscription.pazpaz