schleuder issueshttps://0xacab.org/schleuder/schleuder/-/issues2024-02-14T11:27:26Zhttps://0xacab.org/schleuder/schleuder/-/issues/530Insufficient sanitation of emailed requests2024-02-14T11:27:26ZAndrew GallagherInsufficient sanitation of emailed requestsI use Apple Mail, which has the unfortunate habit of expanding "user@example.com" to "user@example.com &lt;user@example.com&gt;", even in "plain text" mode. This means that when trying to subscribe a non-admin user to a list via the -req...I use Apple Mail, which has the unfortunate habit of expanding "user@example.com" to "user@example.com <user@example.com>", even in "plain text" mode. This means that when trying to subscribe a non-admin user to a list via the -request interface, the body gets mangled to:
```
x-subscribe: user@example.com <user@example.com> DEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEF
```
This is apparently being parsed as:
```
x-subscribe: user@example.com NULL TRUE
```
because it subscribes the user without a fingerprint and sets them to an admin:
```
user@example.com has been subscribed with these attributes:
Fingerprint:
Admin? true
Email-delivery enabled? true
```
This is dangerous behaviour. Unexpected input should always throw an error, especially where admin permissions are being assigned.5.0.0pazpazhttps://0xacab.org/schleuder/schleuder/-/issues/526Schleuder throws a traceback if told to import a key, but a key can't be found2024-01-09T08:56:04ZgeorgSchleuder throws a traceback if told to import a key, but a key can't be foundSuper admins receive the following error via mail if a user tries to import a key via a request mail with `x-add-key`, but no key:
```
undefined method `compact' for "Your message did not contain any attachments nor text content. Theref...Super admins receive the following error via mail if a user tries to import a key via a request mail with `x-add-key`, but no key:
```
undefined method `compact' for "Your message did not contain any attachments nor text content. Therefore no key could be imported.":String
import_stati = results.compact.collect(&:imports).flatten
^^^^^^^^
/usr/lib/ruby/vendor_ruby/schleuder/keyword_handlers/key_management.rb:21:in `add_key'
/usr/lib/ruby/vendor_ruby/schleuder/keyword_handlers_runner.rb:67:in `run_handler'
/usr/lib/ruby/vendor_ruby/schleuder/keyword_handlers_runner.rb:34:in `block in run'
/usr/lib/ruby/vendor_ruby/schleuder/keyword_handlers_runner.rb:32:in `map'
/usr/lib/ruby/vendor_ruby/schleuder/keyword_handlers_runner.rb:32:in `run'
/usr/lib/ruby/vendor_ruby/schleuder/filters/post_decryption/10_request.rb:16:in `request'
/usr/lib/ruby/vendor_ruby/schleuder/filters_runner.rb:14:in `block in run'
/usr/lib/ruby/vendor_ruby/schleuder/filters_runner.rb:12:in `map'
/usr/lib/ruby/vendor_ruby/schleuder/filters_runner.rb:12:in `run'
/usr/lib/ruby/vendor_ruby/schleuder/runner.rb:127:in `run_filters'
/usr/lib/ruby/vendor_ruby/schleuder/runner.rb:56:in `run'
/usr/lib/ruby/vendor_ruby/schleuder/cli.rb:38:in `work'
/usr/share/rubygems-integration/all/gems/thor-1.2.1/lib/thor/command.rb:27:in `run'
/usr/share/rubygems-integration/all/gems/thor-1.2.1/lib/thor/invocation.rb:127:in `invoke_command'
/usr/share/rubygems-integration/all/gems/thor-1.2.1/lib/thor.rb:392:in `dispatch'
/usr/share/rubygems-integration/all/gems/thor-1.2.1/lib/thor/base.rb:485:in `start'
/usr/bin/schleuder:13:in `<main>'
```
Schleuder version: `4.0.3`5.0.0pazpazhttps://0xacab.org/schleuder/schleuder/-/issues/525Fix importing keys from encoded attachments2023-11-14T08:54:32ZpazFix importing keys from encoded attachmentsCurrently importing keys from some forms of encoded attachments (e.g. sent by Thunderbird) fails.
This is due to the change from 7ff1160a4cd090e38ffd6d49ee27531132cc52f4.
Interestingly, the test-case newly added by that commit, also is...Currently importing keys from some forms of encoded attachments (e.g. sent by Thunderbird) fails.
This is due to the change from 7ff1160a4cd090e38ffd6d49ee27531132cc52f4.
Interestingly, the test-case newly added by that commit, also is green without the change to `key_management.rb`.
@georg Do you have any memory why you changed `key_management.rb` the way you did?5.0.0pazpazhttps://0xacab.org/schleuder/schleuder/-/issues/450Fix flaky test in release-4 branch2023-11-08T22:31:39ZNinaFix flaky test in release-4 branchThis test seems to be flaky spec/schleuder-api-daemon/requests/list_spec.rb:107
Example:
https://0xacab.org/schleuder/schleuder/-/jobs/127406This test seems to be flaky spec/schleuder-api-daemon/requests/list_spec.rb:107
Example:
https://0xacab.org/schleuder/schleuder/-/jobs/127406NinaNinahttps://0xacab.org/schleuder/schleuder/-/issues/495x-add-key fails for binary attachments2023-10-28T10:15:11Zgeorgx-add-key fails for binary attachmentsx-add-key fails for binary attachments, Schleuder tells 'no keys could be found'.x-add-key fails for binary attachments, Schleuder tells 'no keys could be found'.4.0.1georggeorghttps://0xacab.org/schleuder/schleuder/-/issues/523HTML mail leakage when the `text/html` part is not a direct child of the `mul...2023-10-23T21:36:38ZsnipHTML mail leakage when the `text/html` part is not a direct child of the `multipart/alternative`Hello!
I think I've encountered a problem in Schleuder 3.4.0 (which is probably still present in the later versions as well), in which the HTML part of an email containing keywords will not be removed if the `text/html` part is not a di...Hello!
I think I've encountered a problem in Schleuder 3.4.0 (which is probably still present in the later versions as well), in which the HTML part of an email containing keywords will not be removed if the `text/html` part is not a direct child of the main `multipart/alternative` container.
## Steps to Reproduce the Problem
1. Compose a new email (I used Thunderbird 102, but other email clients might work as well).
2. Add Schleuder keywords (such as an `x-resend` keyword).
3. In the body of the email, insert an image.
4. Send the encrypted, signed email to the Schleuder address.
Note: Since the HTML part should be stripped anyway, I agree that there is not much point including an image in the email in the first place. However, I think there are real-life situations where this could happen: for instance, when quoting / replying to an email which already has embedded images, the email client will automatically include these images in the new message, and the user may just leave them as is. (Actually, this is how I've stumbled upon this problem.)
## Expected Behavior
One would expect the HTML part to be stripped from the email resent by Schleuder, since #399 was fixed thanks to !255.
## Actual Behavior
The HTML part will be left untouched by Schleuder and resent as is. In particular, it will leak the keywords.
## Specifications
- Version: 3.4.0 (it seems to me that the problem is present in the 4.* branch as well, but I wasn't able to test)
- Installation method (package, gem...): unknown
- Mail client version: Thunderbird 102.3.0
## Other information
It seems to me that this is due to the fact that Schleuder will only remove the `text/html` part if it is directly contained in the top-level `multipart/alternative` container, according to the [`strip_html_from_alternative_if_keywords_present` filter](http://wmj5kiic7b6kjplpbvwadnht2nh2qnkbnqtcv3dyvpqtz7ssbssftxid.onion/schleuder/schleuder/-/blob/schleuder-3.4.0/lib/schleuder/filters/post_decryption/90_strip_html_from_alternative_if_keywords_present.rb#L11-13). For instance, the filter will work as expected if the email has the following structure:
```
multipart/alternative
|- text/plain
'- text/html
```
However, if there is an image embedded with the HTML part, then Thunderbird (and probably other email clients) will first bundle the HTML part and the image together in a `multipart/related` part, then add this part to the `multipart/alternative`:
```
multipart/alternative
|- text/plain
'- multipart/related
|- text/html
'- image/jpeg
```
From what I could understand from the code of the `strip_html_from_alternative_if_keywords_present` filter, it seems to me that Schleuder will not find and remove the `text/html` part because it is not in the `mail.parts` array.
Maybe a possible fix would be to recurse down the tree of parts instead of just looking at the direct children of the root `multipart/alternative` container? Unfortunately, I'm not fluent enough in Ruby to be able to investigate this issue further.
In any case, I hope that this report will help!
Thank you very much for all the work on this great tool! :)
Cheers!\
snip5.0.0https://0xacab.org/schleuder/schleuder/-/issues/399HTML mails might leak keywords to third parties2023-01-18T23:42:21ZgeorgHTML mails might leak keywords to third partiesSchleuder leaves an encrypted HTML part of a mail untouched, it doesn't fiddle with the content. This might lead to keyword leaks to third parties, for example if `x-resend` is used.
Ideas so far how to deal with this:
- Drop the HTML p...Schleuder leaves an encrypted HTML part of a mail untouched, it doesn't fiddle with the content. This might lead to keyword leaks to third parties, for example if `x-resend` is used.
Ideas so far how to deal with this:
- Drop the HTML part completely (which would possibly annoy users)
- Parse the HTML, drop possibly sensitive content
- Use a regex, fed with the keywords which were found in the plaintext, on the "stringified" HTML3.4pazpazhttps://0xacab.org/schleuder/schleuder/-/issues/502signature validation fails2022-09-27T21:18:41Zpony hütchensignature validation failsI'm having trouble with signature validation.
## Expected Behavior
When I send an validly signed and encrypted openpgp/mime message to a lists request address, it should process the request. When I send such a message to a lists normal...I'm having trouble with signature validation.
## Expected Behavior
When I send an validly signed and encrypted openpgp/mime message to a lists request address, it should process the request. When I send such a message to a lists normal address, it should put the pseudo-header 'Sig: Good signature [...]'.
## Actual Behavior
It outputs "Messages to this address must be encrypted and signed by the key associated with a subscribed address [...]". It replies with a email with the same text. It says "Bad signature" in the pseudo header.
## Steps to Reproduce the Problem
1. set up list with one subscriber who is admin of that list.
2. pipe a signed and encrypted message from the subscriber to the list into schleuder
## Specifications
- Version: schleuder 4.0.1
- Installation method (package, gem...): gem
- Mail client version: I used KMail to create the messages.
## Other information
This is the test message I send to the list:
```
From admin@a Wed Jun 09 16:14:08 2021
From: admin@a
To: list@a
Subject: test
Date: Wed, 09 Jun 2021 18:14:08 +0200
Message-ID: <6066403.5e4LmiuuCV@deepthought>
MIME-Version: 1.0
Content-Type: multipart/encrypted; boundary="nextPart2013499.KfxGTPaf5f"; protocol="application/pgp-encrypted"
--nextPart2013499.KfxGTPaf5f
Content-Type: application/pgp-encrypted
Content-Disposition: attachment
Content-Transfer-Encoding: 7Bit
Version: 1
--nextPart2013499.KfxGTPaf5f
Content-Type: application/octet-stream
Content-Disposition: inline; filename="msg.asc"
Content-Transfer-Encoding: 7Bit
-----BEGIN PGP MESSAGE-----
hQIMAx0nShUMaPCRAQ//f0l0D6hTAYsNxuD5dOCSdio6pniKNXWu+bJnZQG1eGEs
4tG2NreH7VpX9qCDd9ZXb4Dh2tFyhVS0NO/nza/bOjqwI7luLlr7QbaxSemyY06+
d7GVITKVbo/d/iO5UyK8MyOESyLe/u3LydsDKm9aJP/sYjtjatuW9iQyEy9KLkTi
8v2IjAMlK28lcuX0PiXOelU+V6jg5humUT11GWmC3iP7IjUxaPMbdbUNdqnZ2CI3
ZW2N50/AF6CS4laRG1xawNy5c3TyoBR/Owd5tHvjGN7PMTSPE99K6VETMV+RfK3n
ouPYm952mSybmIkZE/uU9SvfPS0vYxAgo+BcnfzpHEKAm5UpEBK3LZ7AJizaCOXK
LAYkK6dR2/38jCLjGm187p2IiJGy57AT2e4rsSXTqW9ywz0ukTC3xzGKuq9NPAu4
LH6dXvEutmFBo1SWObEksYSOmPzCOdcknWl5xhlgPBMzG1mOXaWgkogITl2F/Cta
vuWGSuOZLo+3WEmpSYGKddrrQM0AiWMlPN/Xjh6icIyxNzjFTYP5iRdDCqlGQEPV
s9AAhYDB0sPYDyd03JSAdZrrZOCKu8ezW8KAsiYLoypfTGSbqvLeWPXyAAZcoFTX
dhdZoSPiKsdb9MQ1saAgPS+Gt6RKu/i2tV2ZRhlgUi7VQWeiSPawS8poyNurY3GE
jAMCZeuxTV+KPgEEAIlDW20JIWC/3DQ6j2GJfzosfpYb2FBycohIpJawmvf5b5hH
hTWGwrYlSBrA3xIiC3EFc9EgCJ8vhicDe+xD5dmKywGS7xRqU2a+hNp8k/CA6FLZ
FO4rGtwBGRNor/DN20nwx6PEC9baD0W0SPwqt2CHi6XRomyyMfCarQ7XiA4Y0ukB
rPf+FIIuhYLFRZs1Od6s4uatPZxAjh8yZQ6GAiJ7H2BaT5vERBIXvWDqrGQmA44Q
t35Ey2MFIIx1KQyaeHthlE++loPSEtzSerV+4pAqEz+NiCv4BOxybNHk9S9evOZo
k6fuiLBCw6ezDzSgvQbxVrO3q0wNx2KAe0WWunaVaebQ2iTsOiVKhsL1XANmdta6
rA4avZHHsf+OAFbSyWG9k0tb5PBeQJZCqctKbVgyL2psWDpgHLYkYbMPH58RV1W8
8nM83o1ecSDqswVrUYWVNiTYXKeZf/FUbJJUd996EL7NTm3Y610EtaAXOmmGnjKc
rRnCILQiRHc83/tPMw57qMN7Zf2cwZUU8iPuxnJxlOzapppPrOHA9vllGYj73uxu
MKYJvNpar+pQ/HeyWaz0xlwGLn4qpTUkCVtul0YhsIaErrZi1hNIGlxueYeOtCdr
Z5VOvxvEgLxUnUQwdH5re65xM0cLQaMIDYbOkyAtILUoHEaO0hal76XaI7Ene3wL
iPP7RLIasdj6PgeupuX8pzsGbFnlZatC4jrtoO807k0AYDNpd6RmRzwCONbm3fkH
Hg/ethyjqxwsJjcF65ckW+ofTWgtuFsheujqNQuJ97NAFZPssxPcPLjP94vt9R+J
uXF7bdBqn03qCcMJNJE8p7SPJzhbbkcm2BumTcZec5dMWY4x/IBfJS2vtzJ8RKAw
hZ4EWKsg7t8uXqKyPWuOy+5dOZbm4AyP7TB9jaLN82Jtn+MAy4VDskR+vIa7Gn4Y
ZOHRVMe9lpyLZ1R7yXmO+v/nBAoStBt2jZ2VvLH5SQEIaBmfqxAtZksONhs8nKNo
83SPmpzacXmdbQELy+bRqrgxWTuapmmCI7cMArdXyGxXOzIoYCiV
=Q/1n
-----END PGP MESSAGE-----
--nextPart2013499.KfxGTPaf5f--
```
This is the decrypted message:
```
Content-Type: multipart/signed; boundary="nextPart2918540.ARZk9SpqV6"; micalg="pgp-sha256"; protocol="application/pgp-signature"
--nextPart2918540.ARZk9SpqV6
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"; protected-headers="v1"
From: admin@a
To: list@a
Subject: test
Date: Wed, 09 Jun 2021 18:14:07 +0200
Message-ID: <6066403.5e4LmiuuCV@deepthought>
x-list-name: list@a
x-list-keys
--nextPart2918540.ARZk9SpqV6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit
-----BEGIN PGP SIGNATURE-----
iLMEAAEIAB0WIQSfKcpM8aR1YUksBzfHpUV6NcUAggUCYMDozwAKCRDHpUV6NcUA
go21A/0aprlyFNaG5R82y3eUw24brBzWRSaokE1oTqGO48sjernuCUsInRMobEXi
GRdwZ/oYwzWCtIXtYmxXREsnvtVl1OrNLKxxNJfsuicdvCqZhGQPH5llVb27sueX
90sIJ+vxg1/WtG7zlx/3lZiWw9SggbXgVoDjkJVzllms2fNE5w==
=u5Tv
-----END PGP SIGNATURE-----
--nextPart2918540.ARZk9SpqV6--
```
Here is information about the test list
```
me@server:~ $ schleuder-cli keys list list@a
9F29CA4CF1A47561492C0737C7A5457A35C50082 admin@a
7EDF3336CB8BC6D15D461DB5FFF7A04251E7D112 list@a
me@server:~ $ schleuder-cli subscriptions list list@a
admin@a 9F29CA4CF1A47561492C0737C7A5457A35C50082 admin
```
This is how I put the message into schleuder:
```
me@server:~ $ cat mailtolist.mbox | sudo -u schleuder schleuder work list-request@a
Error: Messages to this address must be encrypted and signed by the key associated with a subscribed address.
Kind regards,
Your Schleuder system.
```
This is from /var/log/mail.log
```
Jun 9 19:00:46 server Schleuder[17753]: Loading list 'list-request@a'
Jun 9 19:00:46 server Schleuder[17753]: (9.5ms) SELECT sqlite_version(*)
Jun 9 19:00:46 server Schleuder[17753]: Schleuder::List Load (2.6ms) SELECT "lists".* FROM "lists" WHERE "lists"."email" = ? ORDER BY "lists"."email" ASC LIMIT ? [["email", "list@a"], ["LIMIT", 1]]
Jun 9 19:00:47 server Schleuder[17753]: Schleuder::Subscription Load (1.9ms) SELECT "subscriptions".* FROM "subscriptions" WHERE "subscriptions"."list_id" = ? AND "subscriptions"."admin" = ? ORDER BY "subscriptions"."email" ASC [["list_id", 12], ["admin", 1]]
Jun 9 19:00:47 server Schleuder[17753]: Schleuder::Subscription Load (1.0ms) SELECT "subscriptions".* FROM "subscriptions" WHERE "subscriptions"."list_id" = ? AND "subscriptions"."admin" = ? ORDER BY "subscriptions"."email" ASC [["list_id", 12], ["admin", 1]]
Jun 9 19:00:50 server Schleuder[17753]: Schleuder::Subscription Load (3.1ms) SELECT "subscriptions".* FROM "subscriptions" WHERE "subscriptions"."list_id" = ? AND "subscriptions"."fingerprint" = ? ORDER BY "subscriptions"."email" ASC LIMIT ? [["list_id", 12], ["fingerprint", "9F29CA4CF1A47561492C0737C7A5457A35C50082"], ["LIMIT", 1]]
```
This is the lists log:
```
D, [2021-06-09T18:46:02.136140 #16993] DEBUG -- : Setting GNUPGHOME to /var/lib/schleuder/lists/a/list
I, [2021-06-09T18:46:02.136829 #16993] INFO -- : Parsing incoming email.
D, [2021-06-09T18:46:04.245871 #16993] DEBUG -- : Loading pre_decryption filters
D, [2021-06-09T18:46:04.259098 #16993] DEBUG -- : Calling filter forward_bounce_to_admins
D, [2021-06-09T18:46:04.356335 #16993] DEBUG -- : Calling filter forward_all_incoming_to_admins
D, [2021-06-09T18:46:04.357047 #16993] DEBUG -- : Calling filter send_key
D, [2021-06-09T18:46:04.357378 #16993] DEBUG -- : Calling filter fix_exchange_messages
D, [2021-06-09T18:46:04.357698 #16993] DEBUG -- : Calling filter strip_html_from_alternative
D, [2021-06-09T18:46:05.138321 #16993] DEBUG -- : Loading post_decryption filters
D, [2021-06-09T18:46:05.165974 #16993] DEBUG -- : Calling filter request
D, [2021-06-09T18:46:05.166580 #16993] DEBUG -- : Request-message
D, [2021-06-09T18:46:05.167848 #16993] DEBUG -- : Error: Message was not encrypted and validly signed
D, [2021-06-09T18:46:05.170170 #16993] DEBUG -- : Bouncing message
```
It started this strange behaviour about a month ago, but I didn't immediately noticed. I don't know what caused it to stop working properly. Could be that it came with an system update. I also tried to resend and old E-Mail to an existing mailing list that I had sent earlier which haven't caused any problems, but it produces this error now.[adminata-private-nopass.asc](/uploads/ded08598eae3d6b6f849e7d9dda6ed18/adminata-private-nopass.asc)
**update:**
The password of the subscribers private key is 'pass'https://0xacab.org/schleuder/schleuder/-/issues/519`list.send_list_key_to_subscriptions` fails if `deliver_selfsent` is set to f...2022-09-13T14:49:52Zfleish`list.send_list_key_to_subscriptions` fails if `deliver_selfsent` is set to falseI recently changed my list defaults to set deliver_selfsent to false to avoid having messages reflected back to senders who are also subscribers. The next time I tried to create a list using schleuder-cli, I was unable to use the send-li...I recently changed my list defaults to set deliver_selfsent to false to avoid having messages reflected back to senders who are also subscribers. The next time I tried to create a list using schleuder-cli, I was unable to use the send-list-key-to-subscriptions command to send myself the list's key. Temporarily setting deliver_selfsent to true resolved this issue. Debug logs attached for attempting to call send-list-key-to-subscriptions both times. Somewhat ironically, the 2 errors generated were successfully sent to me as the list admin (and only subscriber) via signed+encrypted mail to the same address.
[list.log.send-list-key-to-subscriptions_selfsent.false.txt](/uploads/f1c51b2f18213f4b36f7cb290b3e0468/list.log.send-list-key-to-subscriptions_selfsent.false.txt)
[list.log.send-list-key-to-subscriptions_selfsent.true.txt](/uploads/1fbf4e90ba20d02f65600fb206831b1f/list.log.send-list-key-to-subscriptions_selfsent.true.txt)5.0.0pazpazhttps://0xacab.org/schleuder/schleuder/-/issues/476receive_from_subscribed_emailaddresses_only: make From: check case-insensitive2022-09-13T14:48:53Zcosmo222receive_from_subscribed_emailaddresses_only: make From: check case-insensitiveHello,
I have a few list using schleuder and in lists where i'm not using pgp to verify if someone is on list i use
`Receive from subscribed emailaddresses only?` and there is a problem because this check is case-sensitive i know that...Hello,
I have a few list using schleuder and in lists where i'm not using pgp to verify if someone is on list i use
`Receive from subscribed emailaddresses only?` and there is a problem because this check is case-sensitive i know that this is weak check because You can change From header and send emails to list but this is only what i have.
I cannot use verify using pgp sign because peoples don't know how to use it.
Do You planing to change it or if it fixed tell me in witch version?
I'm using schleuder version 3.4.0-2 installed from repo on debian10.
Best regards
Matthew5.0.0pazpazhttps://0xacab.org/schleuder/schleuder/-/issues/515specs: unit: keyword_handlers/key_management: expected, hardcoded key creatio...2022-04-16T20:27:39Zgeorgspecs: unit: keyword_handlers/key_management: expected, hardcoded key creation dates makes Schleuder build unreproducibleSource: https://tests.reproducible-builds.org/debian/logs/unstable/amd64/schleuder_4.0.3-1.build2.log.gz
```
Failures:
1) Schleuder::KeywordHandlers::KeyManagement.delete_key deletes multiple keys that each distinctly match one argum...Source: https://tests.reproducible-builds.org/debian/logs/unstable/amd64/schleuder_4.0.3-1.build2.log.gz
```
Failures:
1) Schleuder::KeywordHandlers::KeyManagement.delete_key deletes multiple keys that each distinctly match one argument
Failure/Error: expect(output).to match(/This key was deleted:\n0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-12\n\n\nThis key was deleted:\n0x98769E8A1091F36BD88403ECF71A3F8412D83889 bla@foo 2010-08-13 \[expired: 2017-01-\d{2}\]\n/)
expected "This key was deleted:\n0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-13\...was deleted:\n0x98769E8A1091F36BD88403ECF71A3F8412D83889 bla@foo 2010-08-14 [expired: 2017-01-21]\n" to match /This key was deleted:\n0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-12\n\n\nThis key was deleted:\n0x98769E8A1091F36BD88403ECF71A3F8412D83889 bla@foo 2010-08-13 \[expired: 2017-01-\d{2}\]\n/
Diff:
@@ -1,6 +1,11 @@
-/This key was deleted:\n0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-12\n\n\nThis key was deleted:\n0x98769E8A1091F36BD88403ECF71A3F8412D83889 bla@foo 2010-08-13 \[expired: 2017-01-\d{2}\]\n/
+This key was deleted:
+0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-13
+
+
+This key was deleted:
+0x98769E8A1091F36BD88403ECF71A3F8412D83889 bla@foo 2010-08-14 [expired: 2017-01-21]
# ./spec/schleuder/unit/keyword_handlers/key_management_spec.rb:173:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:61:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:60:in `block (2 levels) in <top (required)>'
2) Schleuder::KeywordHandlers::KeyManagement.delete_key deletes a key that distinctly matches the argument
Failure/Error: expect(output).to eql("This key was deleted:\n0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-12\n")
expected: "This key was deleted:\n0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-12\n"
got: "This key was deleted:\n0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-13\n"
(compared using eql?)
Diff:
@@ -1,3 +1,3 @@
This key was deleted:
-0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-12
+0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-13
# ./spec/schleuder/unit/keyword_handlers/key_management_spec.rb:158:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:61:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:60:in `block (2 levels) in <top (required)>'
3) Schleuder::KeywordHandlers::KeyManagement.add_key imports a key from attached acsii-armored material
Failure/Error: expect(output).to eql("This key was newly added:\n0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-12\n")
expected: "This key was newly added:\n0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-12\n"
got: "This key was newly added:\n0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-13\n"
(compared using eql?)
Diff:
@@ -1,3 +1,3 @@
This key was newly added:
-0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-12
+0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-13
# ./spec/schleuder/unit/keyword_handlers/key_management_spec.rb:52:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:61:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:60:in `block (2 levels) in <top (required)>'
4) Schleuder::KeywordHandlers::KeyManagement.add_key updates a key
Failure/Error: expect(output).to match(/This key was updated:\n0x98769E8A1091F36BD88403ECF71A3F8412D83889 bla@foo 2010-08-13 \[expired: 2017-01-\d{2}\]\n/)
expected "This key was updated:\n0x98769E8A1091F36BD88403ECF71A3F8412D83889 bla@foo 2010-08-14 [expired: 2017-01-21]\n" to match /This key was updated:\n0x98769E8A1091F36BD88403ECF71A3F8412D83889 bla@foo 2010-08-13 \[expired: 2017-01-\d{2}\]\n/
Diff:
@@ -1,2 +1,3 @@
-/This key was updated:\n0x98769E8A1091F36BD88403ECF71A3F8412D83889 bla@foo 2010-08-13 \[expired: 2017-01-\d{2}\]\n/
+This key was updated:
+0x98769E8A1091F36BD88403ECF71A3F8412D83889 bla@foo 2010-08-14 [expired: 2017-01-21]
# ./spec/schleuder/unit/keyword_handlers/key_management_spec.rb:129:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:61:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:60:in `block (2 levels) in <top (required)>'
5) Schleuder::KeywordHandlers::KeyManagement.add_key imports a key from attached quoted-printable binary material
Failure/Error: expect(output).to eql("This key was newly added:\n0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-12\n")
expected: "This key was newly added:\n0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-12\n"
got: "This key was newly added:\n0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-13\n"
(compared using eql?)
Diff:
@@ -1,3 +1,3 @@
This key was newly added:
-0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-12
+0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-13
# ./spec/schleuder/unit/keyword_handlers/key_management_spec.rb:69:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:61:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:60:in `block (2 levels) in <top (required)>'
6) Schleuder::KeywordHandlers::KeyManagement.add_key ignores body if an ascii-armored attachment is present
Failure/Error: expect(output).to eql("This key was newly added:\n0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-12\n")
expected: "This key was newly added:\n0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-12\n"
got: "This key was newly added:\n0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-13\n"
(compared using eql?)
Diff:
@@ -1,3 +1,3 @@
This key was newly added:
-0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-12
+0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-13
# ./spec/schleuder/unit/keyword_handlers/key_management_spec.rb:100:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:61:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:60:in `block (2 levels) in <top (required)>'
7) Schleuder::KeywordHandlers::KeyManagement.add_key imports a key from inline ascii-armored material
Failure/Error: expect(output).to eql("This key was newly added:\n0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-12\n")
expected: "This key was newly added:\n0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-12\n"
got: "This key was newly added:\n0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-13\n"
(compared using eql?)
Diff:
@@ -1,3 +1,3 @@
This key was newly added:
-0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-12
+0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-13
# ./spec/schleuder/unit/keyword_handlers/key_management_spec.rb:24:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:61:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:60:in `block (2 levels) in <top (required)>'
```
This is similar to #513, but this time it's not about expiration dates, but about creation dates. Unfortunately, this wasn't reported in the earlier test during Debians reproducible builds, which is why I've missed this.
For the Debian context, I've uploaded `4.0.3-2` shipping a patch which addresses these issues, to check and test if this patch makes Schleuder finally build reproducible again.
Given this, the new CI job to check for such errors via !400 is too limited, I've submitted !401 as a draft for now to widen the scope of this job, to have it check any kind of dates.
Ref #268georggeorghttps://0xacab.org/schleuder/schleuder/-/issues/268specs: Drop (or relax) GPG dates in expected output2022-04-13T10:59:13Zgeorgspecs: Drop (or relax) GPG dates in expected outputI'm trying hard currently to make schleuder build reproducible. The current use of GPG dates in the output of some specs is non deterministic, therefore I would like to get rid of them. See [this](https://0xacab.org/schleuder/schleuder/b...I'm trying hard currently to make schleuder build reproducible. The current use of GPG dates in the output of some specs is non deterministic, therefore I would like to get rid of them. See [this](https://0xacab.org/schleuder/schleuder/blob/master/spec/schleuder/integration/keywords_spec.rb#L1621) for an example. We're checking the fingerprint anyway, so comparing the date does't add any benefits, IMHO.
A failing reproducible builds test looks like the following:
```
-pub 4096R/59C71FB38AEE22E091C78259D06350440F759BD3 2016-12-06
+Date: Tue, 03 Oct 2017 07:36:13 +1400
+From: list108@example.org
+Sender: list108-bounce@example.org
+To: schleuder@example.org
+Message-ID: <59d2790d822c8_9d4c2aab236e70dc68397@i-capture-the-hostname.mail>
+In-Reply-To: <59d279099483e_9d4c2aab236e70dc6786f@i-capture-the-hostname.mail>
+References: <59d279099483e_9d4c2aab236e70dc6786f@i-capture-the-hostname.mail>
+Mime-Version: 1.0
+Content-Type: multipart/mixed;
+ boundary="--==_mimepart_59d2790d3595b_9d4c2aab236e70dc681c4";
+ charset=UTF-8
+Content-Transfer-Encoding: 7bit
+
+
+----==_mimepart_59d2790d3595b_9d4c2aab236e70dc681c4
+Content-Type: text/plain;
+ charset=UTF-8
+Content-Transfer-Encoding: 7bit
+
+All keys from the list's keyring matching '0x59c71fb38aee22e091c78259d06350440f759bd3' are attached to this message.
+----==_mimepart_59d2790d3595b_9d4c2aab236e70dc681c4
+Content-Type: application/pgp-keys
+Content-Transfer-Encoding: 7bit
+Content-Disposition: attachment;
+ filename=59C71FB38AEE22E091C78259D06350440F759BD3.asc
+
+pub 4096R/59C71FB38AEE22E091C78259D06350440F759BD3 2016-12-07
[...]
```
(Note `2016-12-06` vs. `2016-12-07`).
Question: Should we drop the dates completely or use something like `match` with a `regex` instead of `eq`? The second approach seems good for parts like:
```
expect(key.oneline).to eql("0x421FBF7190640136788593CD9EE9BE5929CACC20 expiringkey@example.org 2017-08-03 [expires: 2037-07-29]")
```3.2georggeorghttps://0xacab.org/schleuder/schleuder/-/issues/513specs: unit: keyword_handlers/key_management: expected, hardcoded key expiry ...2022-04-13T10:59:12Zgeorgspecs: unit: keyword_handlers/key_management: expected, hardcoded key expiry dates makes Schleuder build unreproducibleSource: https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/schleuder_4.0.2-1.rbuild.log.gz
```
Failures:
1) Schleuder::KeywordHandlers::KeyManagement.delete_key deletes multiple keys that each distinctly match one arg...Source: https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/schleuder_4.0.2-1.rbuild.log.gz
```
Failures:
1) Schleuder::KeywordHandlers::KeyManagement.delete_key deletes multiple keys that each distinctly match one argument
Failure/Error: expect(output).to eql("This key was deleted:\n0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-12\n\n\nThis key was deleted:\n0x98769E8A1091F36BD88403ECF71A3F8412D83889 bla@foo 2010-08-13 [expired: 2017-01-20]\n")
expected: "This key was deleted:\n0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-12\...was deleted:\n0x98769E8A1091F36BD88403ECF71A3F8412D83889 bla@foo 2010-08-13 [expired: 2017-01-20]\n"
got: "This key was deleted:\n0xC4D60F8833789C7CAA44496FD3FFA6613AB10ECE schleuder2@example.org 2016-12-12\...was deleted:\n0x98769E8A1091F36BD88403ECF71A3F8412D83889 bla@foo 2010-08-13 [expired: 2017-01-19]\n"
(compared using eql?)
Diff:
@@ -3,5 +3,5 @@
This key was deleted:
-0x98769E8A1091F36BD88403ECF71A3F8412D83889 bla@foo 2010-08-13 [expired: 2017-01-20]
+0x98769E8A1091F36BD88403ECF71A3F8412D83889 bla@foo 2010-08-13 [expired: 2017-01-19]
# ./spec/schleuder/unit/keyword_handlers/key_management_spec.rb:173:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:48:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:47:in `block (2 levels) in <top (required)>'
2) Schleuder::KeywordHandlers::KeyManagement.add_key updates a key
Failure/Error: expect(output).to eql("This key was updated:\n0x98769E8A1091F36BD88403ECF71A3F8412D83889 bla@foo 2010-08-13 [expired: 2017-01-20]\n")
expected: "This key was updated:\n0x98769E8A1091F36BD88403ECF71A3F8412D83889 bla@foo 2010-08-13 [expired: 2017-01-20]\n"
got: "This key was updated:\n0x98769E8A1091F36BD88403ECF71A3F8412D83889 bla@foo 2010-08-13 [expired: 2017-01-19]\n"
(compared using eql?)
Diff:
@@ -1,3 +1,3 @@
This key was updated:
-0x98769E8A1091F36BD88403ECF71A3F8412D83889 bla@foo 2010-08-13 [expired: 2017-01-20]
+0x98769E8A1091F36BD88403ECF71A3F8412D83889 bla@foo 2010-08-13 [expired: 2017-01-19]
# ./spec/schleuder/unit/keyword_handlers/key_management_spec.rb:129:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:48:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:47:in `block (2 levels) in <top (required)>'
```
Ref #268
Ref !1184.0.3georggeorghttps://0xacab.org/schleuder/schleuder/-/issues/478CI: specs fail randomly2022-04-12T18:51:16ZgeorgCI: specs fail randomlySee for example these jobs:
- https://0xacab.org/schleuder/schleuder/-/jobs/152036
- https://0xacab.org/schleuder/schleuder/-/jobs/151050See for example these jobs:
- https://0xacab.org/schleuder/schleuder/-/jobs/152036
- https://0xacab.org/schleuder/schleuder/-/jobs/1510504.0.3pazpazhttps://0xacab.org/schleuder/schleuder/-/issues/509spec: cli #refresh_keys updates keys from the keyserver: Failed to open TCP c...2022-04-12T18:51:03Zgeorgspec: cli #refresh_keys updates keys from the keyserver: Failed to open TCP connection to localhost:9999 (Cannot assign requested address - connect(2) for "localhost" port 9999)This test did fail in https://0xacab.org/schleuder/schleuder/-/jobs/257991 via:
```
Failures:
1) cli #refresh_keys updates keys from the keyserver
Failure/Error: Net::HTTP.get(uri)
Errno::EADDRNOTAVAIL:
Failed to open...This test did fail in https://0xacab.org/schleuder/schleuder/-/jobs/257991 via:
```
Failures:
1) cli #refresh_keys updates keys from the keyserver
Failure/Error: Net::HTTP.get(uri)
Errno::EADDRNOTAVAIL:
Failed to open TCP connection to localhost:9999 (Cannot assign requested address - connect(2) for "localhost" port 9999)
# ./spec/spec_helper.rb:99:in `with_sks_mock'
# ./spec/schleuder/integration/cli_spec.rb:11:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:49:in `block (3 levels) in <top (required)>'
# /usr/local/bundle/gems/database_cleaner-core-2.0.1/lib/database_cleaner/strategy.rb:30:in `cleaning'
# /usr/local/bundle/gems/database_cleaner-core-2.0.1/lib/database_cleaner/cleaners.rb:34:in `block (2 levels) in cleaning'
# /usr/local/bundle/gems/database_cleaner-core-2.0.1/lib/database_cleaner/cleaners.rb:35:in `cleaning'
# ./spec/spec_helper.rb:48:in `block (2 levels) in <top (required)>'
# ------------------
# --- Caused by: ---
# Errno::EADDRNOTAVAIL:
# Cannot assign requested address - connect(2) for "localhost" port 9999
# ./spec/spec_helper.rb:99:in `with_sks_mock'
```4.0.3pazpazhttps://0xacab.org/schleuder/schleuder/-/issues/491schleuder install has no output on DB authentication failure2022-04-11T21:46:09Zngschleuder install has no output on DB authentication failureI had a wrong password in schleuder.yml and tried to run `schleuder install` but it had no output and just an exit code of 1.
We should be more verbose otherwise debugging becomes really hard.I had a wrong password in schleuder.yml and tried to run `schleuder install` but it had no output and just an exit code of 1.
We should be more verbose otherwise debugging becomes really hard.https://0xacab.org/schleuder/schleuder/-/issues/512CI: changelog job: fails on non-fast-forward changes of the target branch2022-04-04T09:16:36ZgeorgCI: changelog job: fails on non-fast-forward changes of the target branchExample of a problematic job: https://0xacab.org/schleuder/schleuder/-/jobs/262083
```
$ git fetch --depth=1 https://0xacab.org/schleuder/schleuder.git/ $CI_MERGE_REQUEST_TARGET_BRANCH_NAME:$CI_MERGE_REQUEST_TARGET_BRANCH_NAME
From http...Example of a problematic job: https://0xacab.org/schleuder/schleuder/-/jobs/262083
```
$ git fetch --depth=1 https://0xacab.org/schleuder/schleuder.git/ $CI_MERGE_REQUEST_TARGET_BRANCH_NAME:$CI_MERGE_REQUEST_TARGET_BRANCH_NAME
From https://0xacab.org/schleuder/schleuder
! [rejected] main -> main (non-fast-forward)
```4.0.3georggeorghttps://0xacab.org/schleuder/schleuder/-/issues/505ActiveRecord SQLite3 >= 6.0 represents boolean values as integers by default,...2022-03-17T20:43:57ZPhilipActiveRecord SQLite3 >= 6.0 represents boolean values as integers by default, leads to errors after upgrade## Expected Behavior
Mail should be delivered.
## Actual Behavior
I recently updated our schleuder instance from 3.4 to 3.6. After that mail delivery to schleuder fails with the following error message:
```
List has no admins configured...## Expected Behavior
Mail should be delivered.
## Actual Behavior
I recently updated our schleuder instance from 3.4 to 3.6. After that mail delivery to schleuder fails with the following error message:
```
List has no admins configured, cannot run! (In `/var/lib/schleuder/lists/foo/bar`.)
```
Every list has one or more configured admin addresses.
## Steps to Reproduce the Problem
1. Upgrade Debian version from Buster to Bullseye
2. Send a mail to an already exisiting and working mailing list
3. With for an error mail
## Specifications
- Version: 3.6
- Installation method: Debian Bullseye package
## Other information
Manual re-enabling every admin address works:
```
schleuder-cli subscriptions set foo@bar.org admin false
schleuder-cli subscriptions set foo@bar.org admin true
```4.0.3georggeorghttps://0xacab.org/schleuder/schleuder/-/issues/458undefined method `has_content_type?' for nil:NilClass2021-05-26T21:56:48Zgeorgundefined method `has_content_type?' for nil:NilClassVersion `3.4.0-2+deb10u2`, with these patches:
```
0001-lib-fix-paths.patch
0002-etc-fix-paths.patch
0004-use-default-debian-keyserver.patch
0005-man-fix-log-path.patch
0007-specs-remove-install-test.patch
0008-dirmngr-no-tor-standard-re...Version `3.4.0-2+deb10u2`, with these patches:
```
0001-lib-fix-paths.patch
0002-etc-fix-paths.patch
0004-use-default-debian-keyserver.patch
0005-man-fix-log-path.patch
0007-specs-remove-install-test.patch
0008-dirmngr-no-tor-standard-resolver.patch
0011-fix-for-activerecord-5.2.patch
0016-gemspec-update-sinatra.patch
0017-mutt-protected-headers.patch
0018-refresh_keys-no-list.patch
0019-refresh-fetch-strip-non-self-sigs.patch
0020-admin-notifications-list-id-header.patch
0021-handle-decryption-errors-gracefully.patch
0022-ASCII-8BIT-encoding.patch
```
Traceback:
```
undefined method `has_content_type?' for nil:NilClass
/usr/lib/ruby/vendor_ruby/mail/gpg/sign_part.rb:22:in `verify_signature'
/usr/lib/ruby/vendor_ruby/mail/gpg/mime_signed_message.rb:9:in `setup'
/usr/lib/ruby/vendor_ruby/mail/gpg.rb:141:in `verify'
/usr/lib/ruby/vendor_ruby/mail/gpg/message_patch.rb:91:in `verify'
/usr/lib/ruby/vendor_ruby/schleuder/mail/message.rb:33:in `setup'
/usr/lib/ruby/vendor_ruby/schleuder/runner.rb:15:in `run'
/usr/lib/ruby/vendor_ruby/schleuder/cli.rb:35:in `work'
/usr/lib/ruby/vendor_ruby/thor/command.rb:27:in `run'
/usr/lib/ruby/vendor_ruby/thor/invocation.rb:126:in `invoke_command'
/usr/lib/ruby/vendor_ruby/thor.rb:369:in `dispatch'
/usr/lib/ruby/vendor_ruby/thor/base.rb:444:in `start'
/usr/bin/schleuder:13:in `<main>'
```
Original mail, slightly modified:
```
Return-Path: <example@example.org>
Delivered-To: input@example.org
Received: from mx-a.example.org (mx-a.example.org [10.11.12.13])
by mx-b.example.org (Postfix) with ESMTPS id B783D9
for <support@example.org>; Wed, 06 Mar 2020 16:11:03 +0000 (UTC)
MIME-Version: 1.0
Date: Wed, 06 Mar 2020 16:11:03 +0000
From: example@example.org
To: input@example.org
Subject: foobar
Message-ID: <foobar@example.org>
Content-Type: multipart/signed;
protocol="application/pgp-signature";
boundary="=_3af29082653c11eaa9c874e5f9e4031";
micalg=pgp-sha256
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--=_3af29082653c11eaa9c874e5f9e4031
Content-Type: multipart/mixed;
boundary="=_7A9795606B8711EAA9CA74E5F9E4031"
--=_7A9795606B8711EAA9CA74E5F9E4031
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8;
format=flowed
Hi,
Wie geht es dir?
Danke und liebe Grüße!
Input von example.org
--=_7A9795606B8711EAA9CA74E5F9E4031
Content-Transfer-Encoding: 7bit
Content-Type: application/pgp-keys;
name=0x4DCFFC92.asc
Content-Disposition: attachment;
filename=0x4DCFFC92.asc;
size=3813
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQGNBF5rnBMBDACz3tx4e5AAiZUnPvMxMgfVQGzy15DFTXmGJP8jshpXwgrHd/Dj
I7npRP6qfPx1xLuPEl0Et14yskr/QiEw2wjeccrzNU4s4W+CI/uCUYy5H3e89caT
aGFdEAnIRITRWHh1EUEXeaS8hl/zpLrQC/OoVVqckOQ3W37Braxqdfe8SVvuGaTs
kc1QAHAxeEwV3r4+nMXT2Wi3CacylFLlAUMj9srKuixvp3lAE43QFORO8fMRWPqC
PImvGRD9FyHenB2ZN03MKh+br1X+G2KTXBsrjVhNR8gxbMIoeRlnIdhN+kf9d4Pv
M9aKoZCJBcXd53/IDMrkocLh96rh3p1FNSt2MmDsQv+KNE7EtebpgTDHQxZoTNw/
YeKyGuOCb21/fUSvgGTOgBgNFwwGm87pQRtZRtMDv3yh4Pb24eEeWPxzFeNvAbx+
GZtxqM/6u2CV9/9uu1QZ+PDnoRqnc77WcIXaqwos72eHsdCjKBgcXZ8xtG26zkMq
vdM8myEsKaq4gIkAEQEAAbQRaW5wdXRAZXhhbXBsZS5vcmeJAdQEEwEKAD4WIQS6
0ZwPI/0jQmBKLlGwCAFFCzorpAUCXmucEwIbAwUJA8JnAAULCQgHAwUVCgkICwUW
AgMBAAIeAQIXgAAKCRCwCAFFCzorpB19C/oC5uQMFIMx+xrBEjs3Q8sGbzmV/SXf
vAgOQIOMJ+VhLTgnbRb51eduWJtyhyjiCREXfV9Yjs+iqyW+FFzoHU87DBsLD9ja
9iseNWu7Mz0ZXSZbiMhjYC1CAKyMWTxLclU6uWF5zOWdRjNT42Z5/o98usgwfJrz
B0Iq5/zsH4zW73B7es4ZA9Su1O3LuLRd4BJdw/NwlkUAkPM48dTBxh+z/5TRDvHM
31Z9at2O7jVXXkctIMKmyeapzmZU7Mo0X/gNDbmsw8U0j0IsIvaJH2sH7RWRXMaT
epUXcFEH+ISmqHj8tHWZff8apCQTUsHGDwnUZqZBgH5VbK8nIlCb/9OAiHYLNYc1
X6YyvFm8TSUQzLZKlv7457u+MTk57xvPg04yRPjqgyMP/VhW8QWN/26meZ8ew8ou
7VnK9BX474/5c5hZ7OoO18te+U/5s8TKvAsZ8kzpmGLRuB8dCDMKAcftwCp73L8w
PUJt+6z/BKkfeSk56A2Lojq4v2xTjGQhebC5AY0EXmucEwEMAJgZGIXzhUwk0LGZ
llTwlIe7X5tEZvJS32trMVsofC+fOyISqBMFXY4jbCkkaFU//4eYLaUfcgs/eG+a
f83k0hoAQgeMysZqH2+OJL2jNjC1TDmK1W3sBzj4OLVPXc+cvJgPLBxM6rD5njtP
iWplVveHfNxVCtjpelfsynhO3kBj8o6ZLuBMb8Drmt2XOxeZzEtmsYla98xU59iy
GY4Dhwvmma5ZxHiMKazYzGQlxagm7xmoUv7MGqkt8PPj4UufWiV4C4dqZN6bVvZ5
hme2DBnJdY82kAmYDas4mKzCOnrRV82Hdriwb07zSABppC885p+VPOaWybLuOlMw
KcfR7F0NxCQ59kp5GapsRwUIIryM21HwrtL8liIJ3uwq4aSyg8cYp6OlS+GWlzC+
GV+dPuOhmVLPPbq9/8BsW/TsKTLn/FoXZD07WjXCZr7oGemT0PrN+z8igc4SBFDr
OOIbx1Y0IvzjMAF/rQJEEiJC8iyYLgd9/zxhn1IYv1KQuwdtwwARAQABiQG2BBgB
CgAgFiEEutGcDyP9I0JgSi5RsAgBRQs6K6QFAl5rnBMCGwwACgkQsAgBRQs6K6TD
4gwArwBazFAqlVYNMCc1ztrjZ1j5YiziYgU0lzlkF+vZQOWvv/LF/o9hSIauhQuG
7+TEFcRxTlbPHlBpmJqQqYnU+edHMGWO90v+Owhuvi9Bmi7nZ+XvFUmeRWqSrJrt
kMARzby9FbjQguT1++bf3hUNW72f8x2sGT9KE1ieyPCysmGjM+mIvA74ht+6yQyS
LYzFtoUexibrjvNJ7wmZ8wmeXVjKuP7jc+jzchb4L2YqQg7NCBPpuozBLll5lv8A
q/4w+MTl852A8OYo/xOa+W8141DT8dRjmmtnR4RadeVWN07GG95xz43pqfxjlZ2I
8yeqE90KkXEnLDBadSYfej+/FFNKMkAUUjmLd+i3P8RqWAEREt8XwU444j4/KkS3
y141aRSdBUfJuSDURL+xx/i3UZmJFLvajRJXadMD3kxx+kd8HJvVV9D9EBah3XAY
+dkUoY/gLzhaMR8MQXyp1U0m4WVGbC7CKqPSmvwZIrjqO/aplle73O91VS/6ijbe
LBrw
=8kNQ
-----END PGP PUBLIC KEY BLOCK-----
--=_7A9795606B8711EAA9CA74E5F9E4031
--=_3af29082653c11eaa9c874e5f9e4031
Content-Type: application/pgp-signature;
name=signature.asc
Content-Disposition: attachment;
filename=signature.asc;
size=833
Content-Description: OpenPGP digital signature
-----BEGIN PGP SIGNATURE-----
iQGzBAABCgAdFiEEutGcDyP9I0JgSi5RsAgBRQs6K6QFAl5rnV0ACgkQsAgBRQs6
K6Rwawv9H1cIwmmwmJJq4xSXNHBcx1uoE38+0UNb4QrwvDZ4qTPxljrtzHecp0Jh
ZGB1NrEyDA0ZX298eXQwyHbiGZ8BJAxG1akLmLKGpQ2CRsuy96G4Ot3nfdsVCwPD
YHyxEH8YGk85BSpjl+RZpI7EUTLF3k9NB8szKEhqY8ZgdC4H2n4mCeXNLATO/6GP
qFevJtFK8LAUy1S0lQQ/Y5zWpdT/GJs6MLURhtGGEiv4TLyzcRXpu04h2TBeDlT6
Tn5YfYn1sz55rbLtQo5jmD8PwNwcsElbNQiXPdL22JyinxRz6hBAVgPVMm/bWze6
K3RvzpQ0UoZrdhCgR3PZfe8cyJPvHMyy5g2IkvlN2BbdrqknCMkSyUlo/nmpMf3Z
78RP2TLOeG+JNaEmmF5LuhVRp86A3ItaMjUy1RRdqjRxoXdbqUjjcMiBMPg317Oj
9v/CJytsOXo0LHRQXdNkxPOzosUVDTPuafaqNwT1IwBpc5nKLTV2K3PS55tQ6566
EdSR1zEh
=/aB0
-----END PGP SIGNATURE-----
--=_3af29082653c11eaa9c874e5f9e4031--
```3.5.0ngnghttps://0xacab.org/schleuder/schleuder/-/issues/430crash with Mutt Protected Headers2021-03-17T13:04:54Zalexcrash with Mutt Protected Headers[Mutt 1.12.0](http://mutt.org/relnotes/1.12/) introduced [Protected Headers](https://github.com/autocrypt/memoryhole) via `set crypt_protected_headers_write`. This causes schleuder to fail, works without.
Error on 3.3.0-4~bpo9+2:
> Com...[Mutt 1.12.0](http://mutt.org/relnotes/1.12/) introduced [Protected Headers](https://github.com/autocrypt/memoryhole) via `set crypt_protected_headers_write`. This causes schleuder to fail, works without.
Error on 3.3.0-4~bpo9+2:
> Command died with status 1: "/usr/bin/schleuder". Command output: A fatal error happened. Administrators have been notified. Please try again later.
Error on 3.4.0:
> A fatal error happened. Administrators have been notified. Please try again later. I'm not going to try again; this message has been in the queue too long.
A schleuder dev said: "I can reproduce this, please open a bug report. Thanks!3.4.1