schleuder issueshttps://0xacab.org/schleuder/schleuder/-/issues2018-05-21T15:46:54Zhttps://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/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/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/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/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/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/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/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/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/161Prevent same-list replays2017-08-01T00:39:27ZdkgPrevent same-list replaysover on #158, we discussed cross-list replay attacks, which are resolved by requiring `x-listname:` headers.
however, `x-listname:` doesn't mitigate same-list replay attacks for control messages.
There are several possible mitigati...over on #158, we discussed cross-list replay attacks, which are resolved by requiring `x-listname:` headers.
however, `x-listname:` doesn't mitigate same-list replay attacks for control messages.
There are several possible mitigations, most of them having to do with some sort of stored state anti-replay protections, which may or may not introduce more problems than they solve ;)
Here are three suggestions, along with some caveats:
Last Received
-------------------
* for each admin for a given list, keep track of the OpenPGP timestamp of the signature of the last-received message from that admin as `last_received`.
* when a new message comes in for that list from that admin, verify that the signature is later than the associated `last_received`.
This has a few potential traps lurking in it:
* what if the admin is on a machine with a shifting clock? can they lock out their future messages if they accidentally send one message from the year 3000?
* what if messages get delayed and re-ordered in transit?
All Received
----------------
* for each admin for a given list, keep track of all signatures ever seen by that admin as a list `known_signatures` (you can get a `SIG_ID` from the GnuPG status lines which should be globally unique)
* when a new signed, verified message comes in from that admin for that list, compare the signature with the `known_signatures`. If it's already been seen, reject the message.
caveats:
* this appears to grow without bound, which is problematic in (at least) two ways:
* a malicious list admin could stuff the server full of records to cause it to overflow
* it creates a log of who interacts with the server and when, which is a chunk of metadata that the list operators might not want to be liable for.
Recently Received
-------------------------
We can synthesize the two above with a bit more complexity, and with some baseline assumptions/requirements about system clocks. Pick two time allowances, `F` ("forward skew") and `B` ("backward skew"). (consider `F=B=1 week` for now)
* When a message comes in at server time `T` for a given admin on a given list, and that message signature has time `S`, reject the message if `S < T-B` or `S > T+F`
* if the message is not rejected due to time, compare it's signature ID with `known_signatures` for that admin for that list.
* if it is already present, reject the message
* if it is not present, store `<SIG_ID,S>` in `known_signatures` and process the message
* during regular maintenance at server time `X` (cronjob? scheduled timer?), delete all entries in `known_signatures` where `S < X-B`
caveats:
* this is more complex to implement than the other proposals, and has more types of errors/message rejections
* you have to choose `F` and `B` -- more knobs to twiddle, yuck. Probably `B` should be greater than the maximum expected SMTP delay time (4 days), but not too much longer (to minimize data retention). `F` needs to be set to accomodate clock skew seen in the wild, which i don't have data on.
* what happens if the clock on the server itself is wacky? Does schleuder need to depend on having a mostly-correct system clock?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/146User IDs should be simple e-mail addresses2019-02-02T10:42:24ZdkgUser IDs should be simple e-mail addressesSchleuder appears to generate OpenPGP certificates with User IDs like:
test@foo.example.biz <test@foo.example.biz>
This is unnecessary. If you're just going to have an e-mail address,
Schleuder should just create a simple user...Schleuder appears to generate OpenPGP certificates with User IDs like:
test@foo.example.biz <test@foo.example.biz>
This is unnecessary. If you're just going to have an e-mail address,
Schleuder should just create a simple user ID with only that e-mail
address in it:
test@foo.example.bizhttps://0xacab.org/schleuder/schleuder/-/issues/144Allow list-configuration via keyword2020-01-02T23:59:26ZpazAllow list-configuration via keywordSome people would like to configure lists via keywords. We should consider how that might work.Some people would like to configure lists via keywords. We should consider how that might work.https://0xacab.org/schleuder/schleuder/-/issues/143Check keys before importing2020-01-05T01:47:45ZpazCheck keys before importingWe could import keys into a temporary keyring in order to inspect them first. That way we could e.g. restrict list-users to add new keys only if they carry their user-ID (and their user-ID only), or if restrict to updating their key by c...We could import keys into a temporary keyring in order to inspect them first. That way we could e.g. restrict list-users to add new keys only if they carry their user-ID (and their user-ID only), or if restrict to updating their key by checking the assigned fingerprint.ehttps://0xacab.org/schleuder/schleuder/-/issues/7Research snailgun/snailgun-rr2020-01-05T13:17:12ZpazResearch snailgun/snailgun-rrSnailgun is meant to speed up starting heavy ruby-environments by preforking them. That should greatly improve schleuder-"responsiveness", which is slower than before due to the database abstraction layer.
It would be nice to optional...Snailgun is meant to speed up starting heavy ruby-environments by preforking them. That should greatly improve schleuder-"responsiveness", which is slower than before due to the database abstraction layer.
It would be nice to optionally make use of snailgun, if that is possible. Schleuder shouldn't actually depend on it, though.
https://github.com/candlerb/snailgunhttps://0xacab.org/schleuder/schleuder/-/issues/23Allow to specify parameters for new keys2020-01-04T12:24:57ZpazAllow to specify parameters for new keysschleuder-admins should be able to configure the size, type, etc. for keys that are to be generated by schleuder.schleuder-admins should be able to configure the size, type, etc. for keys that are to be generated by schleuder.Futurehttps://0xacab.org/schleuder/schleuder/-/issues/33Language for subscriptions2018-10-28T11:48:49ZpazLanguage for subscriptionsEach subscription should have its own language-setting to enable people with different language-capabilities use a list together.Each subscription should have its own language-setting to enable people with different language-capabilities use a list together.Futurehttps://0xacab.org/schleuder/schleuder/-/issues/48If resending fails don't send message over list.2020-05-14T12:54:28ZpazIf resending fails don't send message over list.In case the resending failed (e.g. encrypted_only and no key), don't send the message to subscribers but reply to the sender to spare everyone a useless message.
If there are multiple resend-requests we should only abort if the first ...In case the resending failed (e.g. encrypted_only and no key), don't send the message to subscribers but reply to the sender to spare everyone a useless message.
If there are multiple resend-requests we should only abort if the first one fails. After sending out the message to the first resend-recipient it is "out there" and we should send the message also over the list.Futurehttps://0xacab.org/schleuder/schleuder/-/issues/49Optionally attach incoming message?2020-01-05T13:19:36ZpazOptionally attach incoming message?Have the originally incoming message attached to the message sent to subscribers (if configured).
Pro:
+ Subscribers would be able to verify some signatures by themselves.
Contra:
- Headers would leak to other subscribers
- Enc...Have the originally incoming message attached to the message sent to subscribers (if configured).
Pro:
+ Subscribers would be able to verify some signatures by themselves.
Contra:
- Headers would leak to other subscribers
- Encrypted messages can't be decrypted by the subscriber, encrypted+signed neither.
My conclusion right now: it's not worth the effort, because only originally unencrypted messages can be verified at all.