schleuder issueshttps://0xacab.org/schleuder/schleuder/-/issues2021-07-14T14:11:05Zhttps://0xacab.org/schleuder/schleuder/-/issues/504Decide how to handle keys with one or more blanks within the mail addr part o...2021-07-14T14:11:05ZgeorgDecide how to handle keys with one or more blanks within the mail addr part of a uidSchleuder is currently not capable to find the correct key, if the lookup searches for a mail addr, e.g. if resending messages, if the key in question contains one or more blanks within the mail addr part of a uid.
The spec defines ...Schleuder is currently not capable to find the correct key, if the lookup searches for a mail addr, e.g. if resending messages, if the key in question contains one or more blanks within the mail addr part of a uid.
The spec defines this part as an UTF-8 string, which, it seems, leaves room for interpretation.
Different implementations handle this differently: some do accept this, others do not. I just learnt that it's possible to create such keys via Thunderbird, while it's not via `gpg`.
We could either disallow such keys to be added to the keyring, although that might seem drastic, and would do 'harm' if people use such keys only for subscribers, e.g. resending is not of a concern.
Personally, I would like to get both (subscription vs. resending) 'in sync': Allowing such keys in general, or disallowing them; I'm leaning towards the later. If so, this might be a breaking change.
Any opinions wrt this topic?https://0xacab.org/schleuder/schleuder/-/issues/492Running db:init on schleuder install might not be suitable for external DB ad...2021-11-07T20:01:07ZngRunning db:init on schleuder install might not be suitable for external DB adapters with less privileged usersIf you have your schleuder DB in a DBMS (e.g. postgresql) you likely have a user that is not privileged to create the database.
However, on `schleuder install` we blindly do `db:create` which fails.
Related code snippets:
* https://0x...If you have your schleuder DB in a DBMS (e.g. postgresql) you likely have a user that is not privileged to create the database.
However, on `schleuder install` we blindly do `db:create` which fails.
Related code snippets:
* https://0xacab.org/schleuder/schleuder/-/blob/18c1e07a5c414e3ac7d42a495b95603f1a5da837/lib/schleuder/cli.rb#L116
* https://0xacab.org/schleuder/schleuder/-/commit/2ee7f06015a82d5a88e98e8859e15efcb98a7a78
Not sure if we should point it out , be more clever or just document it. Or everybody (except me) runs out of sqlite.https://0xacab.org/schleuder/schleuder/-/issues/475Tell users that mails needs to be validly signed to use keywords2020-06-17T13:35:56ZgeorgTell users that mails needs to be validly signed to use keywordsWe could think about if it would make sense, in terms of UX, to provide a helpful error message in case a mail wasn't signed, but it contained keywords.
Currently, that's not easy to do, because we only look for keywords if the mail was...We could think about if it would make sense, in terms of UX, to provide a helpful error message in case a mail wasn't signed, but it contained keywords.
Currently, that's not easy to do, because we only look for keywords if the mail was signed. I'm not sure how to tackle this, maybe via a "best effort" approach, via a superficial scan of the mail?
Any opinion?https://0xacab.org/schleuder/schleuder/-/issues/474Inform user if unknown keyword was encountered and keyword-processing aborted2020-06-17T11:46:38ZgeorgInform user if unknown keyword was encountered and keyword-processing abortedThe current code correctly checks for unknown keywords and prepares an error message. However, this error message isn't passed back to the user.The current code correctly checks for unknown keywords and prepares an error message. However, this error message isn't passed back to the user.Next Big Thinghttps://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/421schleuder fails to warn about expiring member subkeys2020-06-26T13:41:58Zo-schleuder fails to warn about expiring member subkeysThe periodic key expiry reminders from schleuder do not consider expiring subkeys.
What I would expect is that schleuder
* if the master key has no `[E]` capability, warns if all encryption subkeys expire (because then it can't send mai...The periodic key expiry reminders from schleuder do not consider expiring subkeys.
What I would expect is that schleuder
* if the master key has no `[E]` capability, warns if all encryption subkeys expire (because then it can't send mails to me anymore)
* if the master key has no `[S]` capability, warn if all sign subkey expire (because then I can't send authenticated mails to schleuder anymore).
What actually happens is, without warning the key becomes non-functional and cannot be updated by the user anymore.
As an example consider 0x8F4E6C91F62F3B4E (on sks keyservers). On this key the master key never expires, but the sign and encryption subkeys do.
```
pub rsa4096/0x8F4E6C91F62F3B4E 2016-09-02 [C]
...
sub rsa4096/0xBFDB552FFC4A9191 2019-02-23 [S] [expires: 2020-02-23]
sub rsa4096/0x2E851CD5B07AF0D4 2019-02-23 [E] [expires: 2020-02-23]
```
To create such a key for testing:
1. create a key without expiry and edit:
2. remove subkey with `key 1\n delkey`
3. remove S capability with `change-usage`
4. add expiring E subkey with `addkey` (6)
5. add expiring S subkey with `addkey` (4)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/394Automated messags are still forwarded to the list admin although list bounce/...2020-01-02T21:05:55ZngAutomated messags are still forwarded to the list admin although list bounce/drop notification disabledSchleuder 3.3.0
You can disable notifications to list admins on bounces/drops:
https://0xacab.org/schleuder/schleuder/blob/master/etc/list-defaults.yml#L91
`# Send a notice to the list-admins whenever an email is bounced or dropped?`
...Schleuder 3.3.0
You can disable notifications to list admins on bounces/drops:
https://0xacab.org/schleuder/schleuder/blob/master/etc/list-defaults.yml#L91
`# Send a notice to the list-admins whenever an email is bounced or dropped?`
But this only has an effect within the filter runner itself, but is not respected when receiving automated messages:
https://0xacab.org/schleuder/schleuder/blob/master/lib/schleuder/filters/pre_decryption/10_forward_bounce_to_admins.rb
=> Either we should also check there whether bounce notification is enabled and respect it or if the option seems not appropriate, we should add another setting, as list admins can easily be spammed through lots of automated messages.https://0xacab.org/schleuder/schleuder/-/issues/384Improve key-related keyword vocabulary2021-06-09T14:29:49ZpazImprove key-related keyword vocabularySome key-related keywords are ambigiously named:
* `x-send-key` sends a key from schleuder to the sender.
* `x-get-key` also sends a key from schleuder to the sender.
* `x-fetch-key` makes schleuder get a key from the internet, though.
...Some key-related keywords are ambigiously named:
* `x-send-key` sends a key from schleuder to the sender.
* `x-get-key` also sends a key from schleuder to the sender.
* `x-fetch-key` makes schleuder get a key from the internet, though.
Without studying documentation the difference between these is not comprehensible. Unfortunately I don't have a good proposal for this problem.
Other keywords are clearer named regarding their action (`x-list-keys`, `x-delete-key`), but they suffer from singularized/pluralized mismatches. It *is* possible to list only one key (`x-list-key`?), and it is also possible to delete multiple keys (`x-delete-keys`?). We should harmonize that, or introduce the respective pluralized and singularized aliases.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/364Admin will self-unsubscribe with accidental line-break in x-unsubscribe:-command2020-01-02T22:30:45Zinit voidAdmin will self-unsubscribe with accidental line-break in x-unsubscribe:-commandOne of our list-**admins** send the following request:
```
x-list-name: some-list@listserver.net
x-unsubscribe:
mail@example.net
```
I don't know, why he added a line break? Users to these things.
**Admin** was removed. List stoped wor...One of our list-**admins** send the following request:
```
x-list-name: some-list@listserver.net
x-unsubscribe:
mail@example.net
```
I don't know, why he added a line break? Users to these things.
**Admin** was removed. List stoped working immediately, due to missing admin. Admin had to be restored by schleuder-cli.
## Expected Behavior
The command should complain that the subscription-e-mail is missing.
or
The admin should get a warning, that he is about to unsubscribe himself and some confirmation like `force` is required.
## Actual Behavior
Since the command does not get an e-mail-address on the same line, it assumes that the sender wants to unsubscribe himself.
## Steps to Reproduce the Problem
1. Be Admin
2. Try to unsubscribe a list member
3. Add a line-break between x-unsubscribe: and the e-mail-address.
## Specifications
- Version: 3.2.2-1~bpo9+1
- Installation method: deb
- Mail client version: any
## Other information
I see, why the current behavior is useful. A person that want's to get off the list just sends `x-unsubscribe:` . Done.
But I'm filing this issue anyway because we had the problem with an actual admin. The list shutting down because of the unsubscribed admin caused some stress for the group using the list.
So, the command behaves as intended.
But this intended behavior bares some danger for clumsy admins.
Maybe you cannot prevent clumsy ppl from shooting themselves in the foot sometimes. It's not too hard to write a command and an e-mail-address on one line. I just wanted to let you know, that one of our list-admins managed to pull that of.Next Big Thinghttps://0xacab.org/schleuder/schleuder/-/issues/345Cc: headers not copied when resending a mix of encrypted and unencrypted emails2020-01-06T16:08:11ZsajolidaCc: headers not copied when resending a mix of encrypted and unencrypted emails## Expected Behavior
When sending emails with multiple `x-resend-cc:` commands, each receiver should receive an email with `Cc:` headers corresponding to all the receivers put in `x-resend-cc:`, independently of whether the email they r...## Expected Behavior
When sending emails with multiple `x-resend-cc:` commands, each receiver should receive an email with `Cc:` headers corresponding to all the receivers put in `x-resend-cc:`, independently of whether the email they receive is encrypted or not.
## Actual Behavior
When using two `x-resend-cc:` commands, one to address A that gets resent encrypted and another to address B that gets resent unencrypted, then neither A nor B get the other address in the `Cc:` headers of the email they receive.
## Steps to Reproduce the Problem
1. Send an email with two `x-resend-cc:` commands: one to address A for which there is a public key in the keyring of the mailing list and another to address B for which there is no public key in the keyring of the mailing list.
2. Check the `Cc:` headers of the emails received by address A and B.
## Specifications
- Version: 3
- Installation method (package, gem...): I would have to ask my sysadmins
- Mail client version: Thunderbird 52.7.0Next Big Thinghttps://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/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/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/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/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