schleuder issueshttps://0xacab.org/schleuder/schleuder/-/issues2017-07-29T10:52:49Zhttps://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/169Fix X-FETCH-KEY to use keyserver from config.2017-05-16T06:29:25ZpazFix X-FETCH-KEY to use keyserver from config.This means to rewrite the method. The currently used class `Hkp` doesn't support tor-connections.This means to rewrite the method. The currently used class `Hkp` doesn't support tor-connections.3.0.3pazpazhttps://0xacab.org/schleuder/schleuder/-/issues/167Drop support for v3-keys2018-01-18T11:39:20ZpazDrop support for v3-keys* Those keys really should go away.
* gpg2.1 doesn't support them anymore.
* We can check fingerprints more accurately afterwards as we then know how long they must be.
Only concern: How to prevent gpg2.0 from importing them. (Or how to...* Those keys really should go away.
* gpg2.1 doesn't support them anymore.
* We can check fingerprints more accurately afterwards as we then know how long they must be.
Only concern: How to prevent gpg2.0 from importing them. (Or how to remove them instantly after importing them.) I would prefer to not allow these keys in the keyring and in the list of fingerprints, if we don't allow to use them for subscriptions. That could cause confusion.https://0xacab.org/schleuder/schleuder/-/issues/159avoid stripping top-level MIME-part2017-05-16T20:17:50Zdkgavoid stripping top-level MIME-partAlice and Bob each sent a PGP/MIME encrypted+signed message to a schleuder 3.0.0~beta17 list.
Both messages had text/plain and text/html parts. But Bob's message was reformatted by the schleuder list in a way that caused both the pla...Alice and Bob each sent a PGP/MIME encrypted+signed message to a schleuder 3.0.0~beta17 list.
Both messages had text/plain and text/html parts. But Bob's message was reformatted by the schleuder list in a way that caused both the plain and html parts to display to the recipient.
Both Alice and Bob were using some variant of icedove 45.6.0 on debian systems. Alice's version of enigmail is 1.9.6, Bob's was 1.8.2.
I'll show the structure of the clearted MIME parts inside the application/encrypted part (once it's been decrypted):
Here's how Alice's initial message was structured (note the weird extra multipart/mixed layer marked as "2" here):
1 gpg --decrypt < alice-orig.eml | printmimestructure
2 └┬╴multipart/mixed 1581 bytes
3 └┬╴multipart/alternative 1257 bytes
4 ├─╴text/plain 274 bytes
5 └─╴text/html 561 bytes
and here's how it came out once it was re-sent by schleuder (part "3" has been re-mapped to part "9", with the schleuder metadata inserted as part "8"):
6 gpg --decrypt < alice-resent.eml | printmimestructure
7 └┬╴multipart/mixed 2549 bytes
8 ├─╴text/plain 215 bytes
9 └┬╴multipart/alternative 1325 bytes
10 ├─╴text/plain 286 bytes
11 └─╴text/html 583 bytes
But Bob's original message was more traditionally structured:
12 gpg --decrypt < bob-orig.eml | printmimestructure
13 └┬╴multipart/alternative 3982 bytes
14 ├─╴text/plain 1205 bytes
15 └─╴text/html 2355 bytes
And as a result, it ends up with both parts displayed sequentially, rather than as alternatives once it's re-sent through schleuder (part "18" is the schleuder metadata part, which is then just displayed inline with parts "19" and "20" (which themselves originate from parts "14" and "15", above):
16 gpg --decrypt < bob-resent.eml | printmimestructure
17 └┬╴multipart/mixed 5300 bytes
18 ├─╴text/plain 220 bytes
19 ├─╴text/plain 1252 bytes
20 └─╴text/html 2425 bytes
So it looks to me like schleuder is stripping the top-layer multipart, and replacing it with its own multipart/mixed aggregator. It really shouldn't do that -- it should always take the top-level part of the incoming message, and place it as a peer of its metadata part.
That is, an incoming mesage like:
A └┬╴multipart/alternative
B ├─╴text/plain
C └─╴text/html
Should be mapped to:
D └┬╴multipart/mixed (schleuder wrapper)
E ├─╴text/plain (schleuder metadata)
F └┬╴multipart/alternative (comes from input part "A")
G ├─╴text/plain (comes from input part "B")
H └─╴text/html (comes from input part "C")
Let me know if any of this doesn't make sense.3.0.3pazpazhttps://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/149Keyword to receive log-file2017-04-26T20:56:52ZpazKeyword to receive log-filelist-admins should be able to read the list's log-file. It might help them to help themselves in case of problems.
A keyword that sends the whole (or the last X lines) shouldn't be so hard to implement.list-admins should be able to read the list's log-file. It might help them to help themselves in case of problems.
A keyword that sends the whole (or the last X lines) shouldn't be so hard to implement.pazpazhttps://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/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/56Option to fetch key for admin from keyserver when creating list2023-12-29T16:40:18ZpazOption to fetch key for admin from keyserver when creating listAlternatively to a file-path it should be possible to specify a fingerprint which is used to fetch the key from a keyserver.Alternatively to a file-path it should be possible to specify a fingerprint which is used to fetch the key from a keyserver.Futurehttps://0xacab.org/schleuder/schleuder/-/issues/74Implement memoryhole / protected headers2019-06-19T10:12:17ZpazImplement memoryhole / protected headershttps://modernpgp.org/memoryhole/https://modernpgp.org/memoryhole/Schleuder Futurepazpazhttps://0xacab.org/schleuder/schleuder/-/issues/90Optionally remove HTML from inline-pgp multipart-message2017-06-24T21:28:22ZpazOptionally remove HTML from inline-pgp multipart-messageWe should introduce an option to strip the HTML-part og multipart/alternative-messages (or -parts) in order to gain a verifyable message.
The HTML-part contains the same data, but wrapped in HTML, which I don't want to touch.We should introduce an option to strip the HTML-part og multipart/alternative-messages (or -parts) in order to gain a verifyable message.
The HTML-part contains the same data, but wrapped in HTML, which I don't want to touch.pazpazhttps://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/99Send list-key to all subscribers2017-05-05T13:03:44ZpazSend list-key to all subscribersList-admins should be able to send out the list-key unsolicitedly to all subscribers.
That is useful in case of new lists that are bulk-populated, or when replacing the list-key.
This should be an API-endpoint to enable Webschleude...List-admins should be able to send out the list-key unsolicitedly to all subscribers.
That is useful in case of new lists that are bulk-populated, or when replacing the list-key.
This should be an API-endpoint to enable Webschleuder and SchleuderConf to provide a trigger.https://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/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/444Previously expired key apparently not being updated during weekly refresh_key...2020-03-03T21:06:18ZfleishPreviously expired key apparently not being updated during weekly refresh_keys run, continues to be reported as expired by weekly check_keys runMostly SSIA. I have a list where the user's key has expired and the weekly cron runs for check_keys keeps reporting that they key is still expired based on the now passed date, despite there being an updated key available on the SKS netw...Mostly SSIA. I have a list where the user's key has expired and the weekly cron runs for check_keys keeps reporting that they key is still expired based on the now passed date, despite there being an updated key available on the SKS network with an extended expiration date set in the future.https://0xacab.org/schleuder/schleuder/-/issues/433signature-flooded keys: send mail to schleuder-announce@ to inform users abou...2019-07-17T20:11:46Zgeorgsignature-flooded keys: send mail to schleuder-announce@ to inform users about the current situation and outline possible mitigationAs discussed in !291, we'll send a mail to schleuder-announce@ to inform users about the current situation in regards to signature-flooded keys and outline possible mitigation.
This is a draft for such a mail:
> Subject: What's going o...As discussed in !291, we'll send a mail to schleuder-announce@ to inform users about the current situation in regards to signature-flooded keys and outline possible mitigation.
This is a draft for such a mail:
> Subject: What's going on? Attacks? Keyservers? Certificate flooding?
>
> Dear Schleuder users,
>
> A few days ago, it became known that some GPG keys had being targeted: many
> thousand fake signatures were added to these keys, and afterwards the keys were
> uploaded to the SKS keyserver network.
>
> These keyservers don't do any validation, which lead to the fact that, if
> fetching these keys, a local GPG installation might get "DDoSed". The sheer size
> of these keys will slow down GPG a lot, if not stop it altogether.
>
> Still, the SKS keyserver network serves a quite important role, due to it being
> one of the main methods to distribute updates to keys, like extended expiry
> dates, or to publish revocations in case a key got compromised, for example.
>
> Schleuder runs a weekly scheduled task to fetch updates of the various keyrings.
>
> If you want to read some more details about the current situation, see the
> links at the bottom of this mail.
>
> That's pretty bad.
>
> What to do, from a Schleuder perspective?
>
> - We're in the process of finalizing a bugfix release, 3.4.1., which will ship a
> mitigation against these flooded keys: All third-party signatures will be
> removed before a key is imported. These third-party signatures aren't really
> interesting in the context of Schleuder. We will get this released and shipped
> as soon as possible.
>
> The feature (import-filter) we're using to achieve this was introduced in GPG
> version 2.1.15. Please upgrade to a more recent GPG version in case yours is
> older. Just to give an idea: Both Debian stretch and buster are fine in this
> regard, as well as the CentOS packages that are being available.
>
> - Recently, a new, validating keyserver was launched: keys.openpgp.org. By
> definition, it doesn't carry, and therefore distribute, third-party
> signatures. Using this keyserver, replacing the default SKS keyserver network,
> mitigates the problems as described above.
>
> However, there are not only upsides, but also downsides, if using this server:
>
> - The keyserver does offer to validate the mail addresses of keys, which get
> uploaded, via sending a common verification email to the mail address in
> question.
>
> That's an opt-in process, so there are many keys currently distributed
> without any mail address attached. GPG isn't able to import such keys,
> telling "no user ID" and exiting.
>
> If used to fetch a key without an user ID, `x-fetch-key` breaks as well.
>
> It probably makes sense to spread the word asking people to upload their
> keys and to verify their mail addresses.
>
> - By definition, the server doesn't distribute revocations: "Unfortunately,
> there is currently no good way to distribute revocations that doesn't also
> reveal the revoked identity itself. We don't want to distribute revoked
> identities, so we can't distribute the identity at all."
>
> - In contrast to the SKS keyserver network, this new keyserver isn't
> federated. It's only a single instance, it might be a "single point of
> failure".
>
> - Solutions might be found to all of these problems at some point in time,
> but that probably will take a while.
>
> - You need to decide for yourself, if changing the keyserver makes sense, or
> the mitigation as shipped in the upcoming version 3.4.1 are "good enough".
>
> - We're discussing about using this new keyserver as the default in Schleuder
> version 4.
>
> In case you have any comments, question and/or feedback, please send us a mail
> or create a ticket in our issue tracker.
>
> Cheers,
> the schleuder dev team
>
>
>
>
> https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html
>
> https://dkg.fifthhorseman.net/blog/community-impact-openpgp-cert-flooding.html
>
> https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
>
> https://gist.github.com/rjhansen/f716c3ff4a7068b50f2d8896e54e4b7e
>
> https://admin.hostpoint.ch/pipermail/enigmail-users_enigmail.net/2019-July/005394.html
>
> https://blogs.gentoo.org/mgorny/2019/07/04/sks-poisoning-keys-openpgp-org-hagrid-and-other-non-solutions/3.4.1https://0xacab.org/schleuder/schleuder/-/issues/403Document API2019-02-02T17:07:35ZpazDocument APIPeople should be able to use the API for third party applications. We should document the development principles and technical details to support that:
* Semantic versioning (API will break only in major releases)
* Show happy paths for...People should be able to use the API for third party applications. We should document the development principles and technical details to support that:
* Semantic versioning (API will break only in major releases)
* Show happy paths for endpoints, authorization, etc.Next Big Thinghttps://0xacab.org/schleuder/schleuder/-/issues/377Feature request: select multiple keys per recipient2019-10-08T12:27:16ZUlf Buermeyerulf@freiheitsrechte.orgFeature request: select multiple keys per recipientHi, it is already possible to add as many keys as one likes to a Schleuder, but only one key can be active per recipient at any given time.
That is pretty inconvenient especially for less IT-savvy people who tend to create and use multi...Hi, it is already possible to add as many keys as one likes to a Schleuder, but only one key can be active per recipient at any given time.
That is pretty inconvenient especially for less IT-savvy people who tend to create and use multiple keys on different machines.
Therefore it would be very helpful if Schleuder could use more than one key per recipient when sending email. For example, in Schleuder-Web, we could use checkboxes in the list of available keys instead of a select-one combo box.https://0xacab.org/schleuder/schleuder/-/issues/370Issue with Receive signed only (Only accept validly signed messages) configur...2021-07-06T18:43:39ZfleishIssue with Receive signed only (Only accept validly signed messages) configuration optionI am seeing an issue in Schleuder 3.2.2-1~bpo9+1 (+ manual patches as noted in issue #331) when I set the configuration option "Receive signed only". Received messages from non-list members that are GPG signed are getting bounced with a ...I am seeing an issue in Schleuder 3.2.2-1~bpo9+1 (+ manual patches as noted in issue #331) when I set the configuration option "Receive signed only". Received messages from non-list members that are GPG signed are getting bounced with a message implying they are not signed.
Steps to reproduce:
- Create a list
- Enable "Receive signed only" configuration option (my list also has "Receive encrypted only" set, but that doesn't seem to come into play)
- Send a signed (and encrypted) message to the list by a non-member of the list
Expected behavior:
- GPG signature is validated by schleuder and message is re-sent to the list members
Actual behavior:
- Message is bounced back to sender and admins are notified
Bounce message sent to sender:
> Command died with status 1: "/usr/bin/schleuder".
>
> Command output: Error: Schleuder::Errors::MessageUnsigned Kind regards,
>
> Your Schleuder system.
Notice sent to admins:
> The attached message was bounced with the following notice:
>
> Schleuder::Errors::MessageUnsigned
>
> Kind regards,
>
> Your Schleuder system.
Debug log of one such message:
> D, [2018-09-08T00:44:39.897159 #10749] DEBUG -- : Setting GNUPGHOME to /var/lib/schleuder/lists/list.domain.com/testdl1
>
> I, [2018-09-08T00:44:39.897415 #10749] INFO -- : Parsing incoming email.
>
> D, [2018-09-08T00:44:40.089003 #10749] DEBUG -- : Calling filter forward_bounce_to_admins
>
> D, [2018-09-08T00:44:40.091492 #10749] DEBUG -- : Calling filter forward_all_incoming_to_admins
>
> D, [2018-09-08T00:44:40.091646 #10749] DEBUG -- : Calling filter send_key
>
> D, [2018-09-08T00:44:40.091754 #10749] DEBUG -- : Calling filter fix_exchange_messages!
>
> D, [2018-09-08T00:44:40.099622 #10749] DEBUG -- : Calling filter strip_html_from_alternative!
>
> D, [2018-09-08T00:44:40.211891 #10749] DEBUG -- : Calling filter request
>
> D, [2018-09-08T00:44:40.212113 #10749] DEBUG -- : Calling filter max_message_size
>
> D, [2018-09-08T00:44:40.212245 #10749] DEBUG -- : Calling filter forward_to_owner
>
> D, [2018-09-08T00:44:40.212324 #10749] DEBUG -- : Calling filter receive_admin_only
>
> D, [2018-09-08T00:44:40.212457 #10749] DEBUG -- : Calling filter receive_authenticated_only
>
> D, [2018-09-08T00:44:40.212555 #10749] DEBUG -- : Calling filter receive_signed_only
>
> I, [2018-09-08T00:44:40.212683 #10749] INFO -- : Rejecting mail as unsigned
>
> D, [2018-09-08T00:44:40.212929 #10749] DEBUG -- : Bouncing message>