schleuder issueshttps://0xacab.org/schleuder/schleuder/-/issues2018-05-03T22:35:21Zhttps://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/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/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/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/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.pazpazhttps://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/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/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/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/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.Future