schleuder issueshttps://0xacab.org/schleuder/schleuder/-/issues2021-05-03T08:06:17Zhttps://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/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/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/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/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/96Set expiration date for list keys2020-01-04T12:23:21ZpazSet expiration date for list keysI personally always set an expiration date for PGP-Keys to make sure that in case one looses access to modify the key, the problem will not stay for ever..
Schleuder3 currently creates list keys with no expiration date set.
How do ...I personally always set an expiration date for PGP-Keys to make sure that in case one looses access to modify the key, the problem will not stay for ever..
Schleuder3 currently creates list keys with no expiration date set.
How do you think about setting an expire date per default e.g. in 2 years after creation?
Futurehttps://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/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/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 Thinggeorggeorg