schleuder issueshttps://0xacab.org/schleuder/schleuder/-/issues2024-01-12T11:13:36Zhttps://0xacab.org/schleuder/schleuder/-/issues/439Automatically fetch keys from validating sources2024-01-12T11:13:36ZpazAutomatically fetch keys from validating sourcesLet's make Schleuder:
1. automatically fetch keys for each recipient without key (regardless of subscription or third-party), but only from validating sources (WKD and validating keyservers).
2. update keys also only from validating sou...Let's make Schleuder:
1. automatically fetch keys for each recipient without key (regardless of subscription or third-party), but only from validating sources (WKD and validating keyservers).
2. update keys also only from validating sources,
3. drop `x-fetch-key`.
For most users this would make sending encrypted emails easier. And we would push the use of better key sources, driving people away from still using SKS keyservers, or sending plain text email.
Those users that require more manual control still can use `x-add-key` to get a manually downloaded key from a different source into the list's keyring.
The only downside I see is that Schleuder would repeatedly make network requests for email addresses that don't have a key published in any of the sources. I'd accept that as a small price.
Related to #435Futurepazpazhttps://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/473Give advice to people in case their key expired (or is about to expire)2020-06-14T12:20:23ZgeorgGive advice to people in case their key expired (or is about to expire)It would probably help people if Schleuder would not only tell them, "your key expired", but also, "what to do to resolve this".It would probably help people if Schleuder would not only tell them, "your key expired", but also, "what to do to resolve this".https://0xacab.org/schleuder/schleuder/-/issues/155schleuder-api-daemon: use unix-domain sockets instead of listening on the loo...2018-10-22T11:43:04Zdkgschleuder-api-daemon: use unix-domain sockets instead of listening on the loopback by defaulthttps://schleuder.nadir.org/docs/ says:
> By default schleuder-api-daemon listens only to localhost and does not authenticate requests.
[…]
> The Schleuder API uses API-keys to authenticate clients — if transport encryption is enabled (...https://schleuder.nadir.org/docs/ says:
> By default schleuder-api-daemon listens only to localhost and does not authenticate requests.
[…]
> The Schleuder API uses API-keys to authenticate clients — if transport encryption is enabled (and only if).
This means that anyone on the local machine can can manipulate schleuder however they like.
This is not a sensible default for a machine that might be shared.
The simplest default would be to listen only on a unix-domain socket (not on the loopback) and to control access to that socket with filesystem permissions. Maybe `/run/schleuder/api` is a good place. By default, i'd say make that socket only accessible to the `schleuder` user.
This lets `schleuder-cli` avoid api-keys entirely for the service on the local machine, and it would allow `schleuder-api-daemon` to use `SO_PEERCRED` as an authentication mechanism in the future if it wanted to grant different system users different authorization.https://0xacab.org/schleuder/schleuder/-/issues/151Implement subkey rollover2020-01-04T12:24:22ZgeorgImplement subkey rolloverTo not loose track of this, because I really like the idea, see [this](https://0xacab.org/schleuder/schleuder/issues/96#note_34766) comment by @dkg:
> I'd put aside the question of expiration dates for primary keys, and instead foc...To not loose track of this, because I really like the idea, see [this](https://0xacab.org/schleuder/schleuder/issues/96#note_34766) comment by @dkg:
> I'd put aside the question of expiration dates for primary keys, and instead focus on expiration dates for the encryption-capable subkeys.
schleuder can do automated subkey rollover, and can destroy the expired subkeys, which makes it so that a compromise of the schleuder instance at time T is only capable of decrypting copies of mails sent since the last rollover.
If schleuder always included its latest key in every e-mail, and had an automated/scheduled rollover practice, then things could work pretty much automatically, and you'd get this nice "forward-secrecy"ish property.Futurehttps://0xacab.org/schleuder/schleuder/-/issues/412Implement 2 factor authentication2020-01-04T12:25:52ZgagzImplement 2 factor authenticationAfter some discussion on how to strength login security of schleuder-web, here is a ticket!
Ideas:
- 2FA standard implementation
- Kinda 2FA where a token would be send (encrypted) to the email corresponding to the account after success...After some discussion on how to strength login security of schleuder-web, here is a ticket!
Ideas:
- 2FA standard implementation
- Kinda 2FA where a token would be send (encrypted) to the email corresponding to the account after successful login, and the user would have to enter this token to login
thanks!Futurehttps://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/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/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/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/97Enable replacing list-key2020-01-04T11:47:21ZpazEnable replacing list-keySchleuder should provide the possibility to replace the list-key, either by a newly generated one, or by a provided one.
The new key should optionally (true by default) be signed by the old key to make the transition easier for users....Schleuder should provide the possibility to replace the list-key, either by a newly generated one, or by a provided one.
The new key should optionally (true by default) be signed by the old key to make the transition easier for users.
The option should be provided by the API and be used by Webschleuder and SchleuderConf.
(This feature would also serve the feature request to be able to nuke list-keys in case of compromisation (which was never filed, only told).)Futurehttps://0xacab.org/schleuder/schleuder/-/issues/534Documentation should make it clear that x-add-key must be followed by a blank...2024-03-27T20:41:24ZAndrew GallagherDocumentation should make it clear that x-add-key must be followed by a blank lineWhen using `x-add-key:` to submit an armored key, it does not (always?) work unless you leave a blank line between `x-add-key:` and `-----BEGIN PGP PUBLIC KEY-----`.
Since MUAs tend to reflow paragraphs this is probably sensible, but th...When using `x-add-key:` to submit an armored key, it does not (always?) work unless you leave a blank line between `x-add-key:` and `-----BEGIN PGP PUBLIC KEY-----`.
Since MUAs tend to reflow paragraphs this is probably sensible, but the documentation should mention it. :-)https://0xacab.org/schleuder/schleuder/-/issues/522Add option to track when ($YEAR-$MONTH) a list was "last active"2022-11-13T19:23:33ZgeorgAdd option to track when ($YEAR-$MONTH) a list was "last active"People told, that they would like to see Schleuder being able to track, when, as in $YEAR-$MONTH, a list was "last active", that is, Schleuder handled a mail that was sent to the list by a human, that is, not "automated", either by a sub...People told, that they would like to see Schleuder being able to track, when, as in $YEAR-$MONTH, a list was "last active", that is, Schleuder handled a mail that was sent to the list by a human, that is, not "automated", either by a subscriber or someone outside. This could be achieved via a new boolean list-option, off by default, and a new `date` column `last_active` in the `lists` database table. If this option would be enabled, Schleuder would update the date, whenever a mail as described before is handled.
* `last_active` is probably not really descriptive, and too generic. Something more specific might make sense.
* The database `date` type handles formats such as `YYYY-MM-DD`. Tracking only `YYYY-MM` is probably enough, so `DD` could be hardcoded to `01`.
The use case would be the following: imagine a provider offering Schleuder list hosting. Lists are regularly created. The assumption is that at least some of them are not in use anymore after a certain amount of time. Some of the lists get abandoned, still, the provider holds PII and private keys. To cleanup such data, the database could then be regularly queried and relevant lists deleted.https://0xacab.org/schleuder/schleuder/-/issues/494Delete subscription & key together2021-07-07T11:42:38ZngDelete subscription & key togetherHave an option to delete a subscription together with the key. Atm it is a two step process to delete a subscription and than its key. Which is a bit tediousHave an option to delete a subscription together with the key. Atm it is a two step process to delete a subscription and than its key. Which is a bit tedioushttps://0xacab.org/schleuder/schleuder/-/issues/461Provide script to sanitize real world example mails2020-03-19T22:03:17ZgeorgProvide script to sanitize real world example mailsFeeding our issue tracker with real world example mails takes time due to doing "data hygiene". I plan to write a script, which, if given a mail file, writes out a sanitized copy. Obviously, before publishing, people should still check t...Feeding our issue tracker with real world example mails takes time due to doing "data hygiene". I plan to write a script, which, if given a mail file, writes out a sanitized copy. Obviously, before publishing, people should still check the result. Probably, this takes a bit of time to do some iterations, to make it better. Lets start?georggeorghttps://0xacab.org/schleuder/schleuder/-/issues/391Adapt keywords_admin_notify to activities/actions2019-04-09T11:01:41ZpazAdapt keywords_admin_notify to activities/actionsThe point is to notify admins about certain activities. It should be irrelevant if e.g. a key was added using a keyword or using an API-client. Thus the notifications should be supervised by the resource-controllers and should be renamed...The point is to notify admins about certain activities. It should be irrelevant if e.g. a key was added using a keyword or using an API-client. Thus the notifications should be supervised by the resource-controllers and should be renamed to reflect that.
How about `actions_admin_notify`?Next Big Thinghttps://0xacab.org/schleuder/schleuder/-/issues/376Harmonize output of keywords that deal with keys2020-01-04T12:51:37ZgeorgHarmonize output of keywords that deal with keysI've used `x-fetch-key` with a capitalized fingerprint argument, and got, in return a message containing the lowercased fingerprint. We should probably harmonize this, so the output matches the input.
Not sure, but maybe this applies to...I've used `x-fetch-key` with a capitalized fingerprint argument, and got, in return a message containing the lowercased fingerprint. We should probably harmonize this, so the output matches the input.
Not sure, but maybe this applies to spaces, too.
Any opinions?Futurehttps://0xacab.org/schleuder/schleuder/-/issues/375Handle space-separated fingerprints for all relevant keywords2020-01-04T12:51:15ZgeorgHandle space-separated fingerprints for all relevant keywordsIn version `3.2.0`, we introduced spaces-separated fingerprint support for `x-subscribe`.
We should probably revisit this for the other relevant keywords, too. I just did `x-fetch-key` with such a fingerprint, and got, in return, ten ti...In version `3.2.0`, we introduced spaces-separated fingerprint support for `x-subscribe`.
We should probably revisit this for the other relevant keywords, too. I just did `x-fetch-key` with such a fingerprint, and got, in return, ten times the message: `Invalid input. Allowed are: URLs, OpenPGP-fingerprints, or email-addresses.`. I'm not sure, and didn't checked, if this is an issue for other keywords too, but I guess so.
OTOH, as we spoke about "being implicit", I wonder if parsing fingerprints with spaces is maybe error prone?
Still, if we do, we should be consistent. Tagging this for `4.0` for now, and labeling as `bug`.
Any opinions?Futurehttps://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/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-01