schleuder issueshttps://0xacab.org/schleuder/schleuder/-/issues2023-12-29T15:50:35Zhttps://0xacab.org/schleuder/schleuder/-/issues/163Reject fingerprints for which no key is present2023-12-29T15:50:35ZmalteReject fingerprints for which no key is presentWhen assigning a fingerprint to a key (via schleuder-cli) verify that its really a fingerprint.When assigning a fingerprint to a key (via schleuder-cli) verify that its really a fingerprint.https://0xacab.org/schleuder/schleuder/-/issues/164Enforce the use of 4096 bit keys and long fpr?2017-08-01T00:39:26ZgeorgEnforce the use of 4096 bit keys and long fpr?Reading #163: Should we enforce the use of 4096 bit keys, and long fingerprints? Going more into a direction of "secure by default". This needs discussion obviously, hence this ticket.Reading #163: Should we enforce the use of 4096 bit keys, and long fingerprints? Going more into a direction of "secure by default". This needs discussion obviously, hence this ticket.https://0xacab.org/schleuder/schleuder/-/issues/170[configuration] encrypt-only always on when resending to this list of emails2017-07-29T10:52:49Zemmapeel[configuration] encrypt-only always on when resending to this list of emailsI would like to have the possibility of maintaining a list of email addresses (that are external to the list, but that we mail a lot) so we **never, ever**, send them email unencrypted.
Specially useful when you get used to X-RESEND an...I would like to have the possibility of maintaining a list of email addresses (that are external to the list, but that we mail a lot) so we **never, ever**, send them email unencrypted.
Specially useful when you get used to X-RESEND and then the key of the external recipient expires.https://0xacab.org/schleuder/schleuder/-/issues/190option: keep original sender signature2021-05-03T08:06:17Zalexoption: keep original sender signatureCurrently, schleuder strips the orignal OpenPGP-signature of the sender, and adds a pseudo-header "Sig: Good signature from $sender", and signs this with the list key.
I see a use for this, but I don't think that this fits everyone.
Sc...Currently, schleuder strips the orignal OpenPGP-signature of the sender, and adds a pseudo-header "Sig: Good signature from $sender", and signs this with the list key.
I see a use for this, but I don't think that this fits everyone.
Schleuder "breaks" end-to-end-confidentiality by re-encrypting the content. This is the design, this is okay. But stripping the original signature also breaks end-to-end-integrity and end-to-end-authenticity. I think these are valuable peoperties to retain, *especially* because of the re-encryption.
Other people think so, too. Jan Jancar is implementing encrypted lists in mailman, and two of [his design principles](https://neuromancer.sk/page/gsoc/mailman#technical-details) are:
> * keep the original user’s signature
> * optionally strip the sender’s signature
When asked, why he's starting a new project over schleuder at all, the [second of three reasons](https://lists.torproject.org/pipermail/tor-project/2017-March/001050.html) was:
> keep the original sender's signature when resending to subscribers, which means a bit less trust in the server is necessary when the subscribers trust each other's keys. (AFAIK, Schleuder strips the signature and adds a header saying it was valid/not)
I didn't look into the details, but I assume this shouldn't be too hard to implement. AFAIU, MIME should make it rather easy to keep the original body and OpenPGP-signature throughout the resto of the re-encryption magic.https://0xacab.org/schleuder/schleuder/-/issues/194Deprecate haveged due to recent kernel developments?2022-09-13T11:03:29ZgeorgDeprecate haveged due to recent kernel developments?This needs more research. Just [a pointer](https://lists.cert.at/pipermail/ach/2017-May/002251.html) for now.This needs more research. Just [a pointer](https://lists.cert.at/pipermail/ach/2017-May/002251.html) for now.Next Big Thinghttps://0xacab.org/schleuder/schleuder/-/issues/196Show warning if weak key is used / extend trust_issues2020-01-04T12:23:01ZgeorgShow warning if weak key is used / extend trust_issuesFuturehttps://0xacab.org/schleuder/schleuder/-/issues/197Allow users to delete their own keys?2018-02-19T21:22:39ZgeorgAllow users to delete their own keys?- Should users be able to delete their own keys, even if the list settings forbids users to delete keys?- Should users be able to delete their own keys, even if the list settings forbids users to delete keys?https://0xacab.org/schleuder/schleuder/-/issues/199Allow deletion of keys only when no subscription uses them2017-05-16T12:53:40ZgeorgAllow deletion of keys only when no subscription uses themhttps://0xacab.org/schleuder/schleuder/-/issues/200config option: Post delete hook2018-05-21T15:46:54Zgeorgconfig option: Post delete hooke.g. to wipe the list dire.g. to wipe the list dirhttps://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.pazpazhttps://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/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/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/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/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/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/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/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/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/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).