schleuder issueshttps://0xacab.org/schleuder/schleuder/-/issues2023-11-08T22:31:39Zhttps://0xacab.org/schleuder/schleuder/-/issues/449Add error_codes to API errors2023-11-08T22:31:39ZngAdd error_codes to API errorsAPI errors should not only have an `error:` but also a machine readable `error_code`.
See https://0xacab.org/schleuder/schleuder/merge_requests/308#note_296360 for backgroundAPI errors should not only have an `error:` but also a machine readable `error_code`.
See https://0xacab.org/schleuder/schleuder/merge_requests/308#note_296360 for backgroundNext Big ThingNinaNinahttps://0xacab.org/schleuder/schleuder/-/issues/448password prompt when running tests locally2020-01-24T10:04:01Zngpassword prompt when running tests locallySince !310 we have an example of a symmetric encrypted email.
When running the tests locally I now get a prompt to enter a password when schleuder tries to decrypt that email. For me this is an indication that the tests are not correctl...Since !310 we have an example of a symmetric encrypted email.
When running the tests locally I now get a prompt to enter a password when schleuder tries to decrypt that email. For me this is an indication that the tests are not correctly isolated from the running (gnupg) environment and thus might even be further affected by it.
We should make sure that the tests are properly isolated.3.5.0pazpazhttps://0xacab.org/schleuder/schleuder/-/issues/441Examples of mails which are detected as automated messages2021-02-03T12:26:14ZngExamples of mails which are detected as automated messagesEmails containing ccc vouchers are detected as an automated message:
Headers of such a mail
```
Date: Tue, 29 Oct 2019 15:55:00 +0000
From: 36th Chaos Communication Congress <36c3-tickets@cccv.de>
To: foo@bar.com
Message-ID: <xy@ticket...Emails containing ccc vouchers are detected as an automated message:
Headers of such a mail
```
Date: Tue, 29 Oct 2019 15:55:00 +0000
From: 36th Chaos Communication Congress <36c3-tickets@cccv.de>
To: foo@bar.com
Message-ID: <xy@tickets-backend.events.ccc.de>
Subject: [36C3] You received a voucher
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="===============5623735347053802827=="
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: amavisd-new at
X-Auto-Response-Suppress: OOF, NRN, AutoReply, RN
Auto-Submitted: auto-generated
```3.6.0https://0xacab.org/schleuder/schleuder/-/issues/435Provide list-option to auto-import keys from Autocrypt-headers and attachments2023-12-08T13:18:02ZgeorgProvide list-option to auto-import keys from Autocrypt-headers and attachmentsI spoke with people about Schleuder version 4, and stuff they would find helpful. Something people mentioned several times was better Autocrypt support, especially if Schleuder is used in a "frontdesk setup", with lots of different peopl...I spoke with people about Schleuder version 4, and stuff they would find helpful. Something people mentioned several times was better Autocrypt support, especially if Schleuder is used in a "frontdesk setup", with lots of different people sending mail to Schleuder, etc. To make this more easy, and to give people an option to get rid of boring, manual and repeated work, this is a proposal:
- Introduce a new per-list option to parse incoming Autocrypt header.
- If enabled, handle the `keydata` field, check the data in there, and if all good, import the key into the final keyring.
- Probably, checking the data in the field means importing the data into a temporary keyring, and checking the result.
- Add a new pseudo-header, `sender key status`, with the result of the check and/or import as per above:
* `Not present - Key imported` (if there was not key yet for this email addr, TOFU)
* `Already present - Key unchanged` (if the key is already part of the keyring)
* `Already present - Conflicting Key - not imported` (if a different key for this mail addr is already part of the keyring)
- Pending questions:
* Use a dedicated per-list keyring for these keys, similar to what MUAs are doing?
* Still, prefer the manual keyring, and only if no key is found there, fallback to the Autocrypt-keyring?
* Should a disctinction be made regarding sending to subscribers, vs. resending? That is: Should the manual keyring be the single source of truth to handle key lookups of subscriptions?
* As per the Autocrypt spec, AFAIK, MUAs do replace keys, if a key is already present on the local system and there is a new one received via mail. Do we want this? Or do we let people handle this situation on their own, as per above?
* Wording: Not really sure if I'm happy with `sender key status`, maybe just `Autocrypt`? OTOH, not sure if that's "too technical".
That's a first draft, happy to take any input, and to get this into something worth implementing.5.0.0pazpazhttps://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/432signature-flooded keys: introduce import-filter (gpg >= 2.1.15) or ask for gp...2019-09-03T21:07:55Zgeorgsignature-flooded keys: introduce import-filter (gpg >= 2.1.15) or ask for gpg upgrade (gpg < 2.1.15)We had a discussion in !291 about possible mitigations given the current situation in regard to the signature-flooded keys.
> [paz wrote](https://0xacab.org/schleuder/schleuder/merge_requests/291#note_169079):
> So the biggest problem ...We had a discussion in !291 about possible mitigations given the current situation in regard to the signature-flooded keys.
> [paz wrote](https://0xacab.org/schleuder/schleuder/merge_requests/291#note_169079):
> So the biggest problem with both import-options is that they apparently were released with gpg v2.1.4. Schleuder v3.4 supports gpg >= 2.0. To use those options would be a breaking change.
> Besides they don't help that well: importing C4BC2DDB38CCE96485EBE9C2F20691179038E5C6 (dkg's flooded key) into an old-style keyring with either of those options takes >11 minutes on my laptop, most of that time eating a whole CPU core. Also after the import encrypting to that key takes \~33 seconds. Those numbers do not indicate a good solution, I think.
> What works better is using an import-filter that drops all non-self-signatures: `--import-filter drop-sig="sig_created_d > 0000-00-00"`. Importing the key with this option takes 50-55 seconds, encrypting to it takes 0.035-0.045 seconds. That is tolerable, I'd say. (Losing access to new non-self-signatures is not a big problem for Schleuder, I'd say. We use `always-trust` anyway.)
> Problem is: that options was only added in gpg v2.1.15. We can't introduce that feature mandatorily in Schleuder v3.4, either.
> What we *could do* it use that filter if the gpg version is recent enough, and put (or send) out big warnings in case it is older. In my eyes that might be the best technical option.
> [...]
I guess if we all agree that this is a good plan, let's do this. I've set the milestone to %3.4.1.3.4.1https://0xacab.org/schleuder/schleuder/-/issues/431mails with empty subject and containing keywords not recognized if protected ...2019-09-13T13:24:42Zgeorgmails with empty subject and containing keywords not recognized if protected headers are usedI was told by a user, and did reproduce this now myself, that mails containing keywords are not recognized if protected headers are used.I was told by a user, and did reproduce this now myself, that mails containing keywords are not recognized if protected headers are used.3.4.1georggeorghttps://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.1https://0xacab.org/schleuder/schleuder/-/issues/429Resending: Inform if key exists, but isn't usable due to expiration2020-02-09T14:22:41ZcasperResending: Inform if key exists, but isn't usable due to expirationIssue #428 was wrongly created by me due to missing feedback from Schleuder.
It would be great if Schleuder had told me, that the key I'm trying to use with `X-RESEND-ENCRYPTED-ONLY` had actually expired. Instead, it just told me `Resen...Issue #428 was wrongly created by me due to missing feedback from Schleuder.
It would be great if Schleuder had told me, that the key I'm trying to use with `X-RESEND-ENCRYPTED-ONLY` had actually expired. Instead, it just told me `Resending to <user@example.org> failed (0 keys found and unencrypted sending disallowed)`3.5.0ngnghttps://0xacab.org/schleuder/schleuder/-/issues/424Details of control over resend-keywords in `subscriber_permissions`2019-12-08T16:24:22ZpazDetails of control over resend-keywords in `subscriber_permissions`The `subscriber_permissions` replace `keywords_admin_only`, so that both, API and keywords handlers, show the same authorization behaviour.
I'm currently wondering:
1. should I introduce a subscriber-permission for each single resend-k...The `subscriber_permissions` replace `keywords_admin_only`, so that both, API and keywords handlers, show the same authorization behaviour.
I'm currently wondering:
1. should I introduce a subscriber-permission for each single resend-keyword Schleuder knows; so that list-admins can configure in all detail which resend-variant is allowed to subscribers, and which isn't.
2. Or would it suffice to introduce only one or two subscriber-permissions; so that list-admins can allow or disallow resending in general, and maybe to allow or disallow resending unencryptedly.
I tend to favour the second variant, with two subscriber-permissions. But I'd like feedback from the world, please.
Does anyone have an opinion on this?Next Big Thingpazpazhttps://0xacab.org/schleuder/schleuder/-/issues/422Provide systemd timers as alternative to cronjobs2021-03-04T11:26:57ZgeorgProvide systemd timers as alternative to cronjobsWe're currently providing cronjob files. We should provide systemd timers, too.We're currently providing cronjob files. We should provide systemd timers, too.Next Big Thinggeorggeorghttps://0xacab.org/schleuder/schleuder/-/issues/417Delete keys only by fingerprint?2019-03-31T09:45:11ZpazDelete keys only by fingerprint?Currently `X-DELETE-KEY` uses whatever comes as argument to find the key that shall be deleted. Through the API we only accept fingerprints as identifiers for keys, and for other keywords too.
I think it would make sense to only accept ...Currently `X-DELETE-KEY` uses whatever comes as argument to find the key that shall be deleted. Through the API we only accept fingerprints as identifiers for keys, and for other keywords too.
I think it would make sense to only accept fingerprints for this keyword, too.
Does anyone think differently?Next Big Thingpazpazhttps://0xacab.org/schleuder/schleuder/-/issues/411Remove `pin_keys`?2021-03-04T11:26:57ZpazRemove `pin_keys`?I stumbled upon the code that looks for subscriptions without an associated key, and tries to find a distinctly matching key. Originally we implemented that to help with a shortcoming of previously published list-migration code.
I suppo...I stumbled upon the code that looks for subscriptions without an associated key, and tries to find a distinctly matching key. Originally we implemented that to help with a shortcoming of previously published list-migration code.
I suppose we don't need this key-pinning code anymore and would like to delete it. Does anyone know any reason not to do that?Next Big Thinggeorggeorghttps://0xacab.org/schleuder/schleuder/-/issues/409Research flaky UTF-8 vs. ASCII problem2020-03-22T21:48:08ZpazResearch flaky UTF-8 vs. ASCII problemUnder unknown circumstances, this error happens:
```
1) user sends a plain text message from thunderbird being signed-inline
Failure/Error: expect(error).to be_empty
expected `"Error: A serious, unhandleable error happened. ...Under unknown circumstances, this error happens:
```
1) user sends a plain text message from thunderbird being signed-inline
Failure/Error: expect(error).to be_empty
expected `"Error: A serious, unhandleable error happened. Please contact the administrators of this system or service and provide them with the following information:\n\ninvalid byte sequence in US-ASCII\n".empty?` to return true, got false
# ./spec/schleuder/integration/send_plain_spec.rb:18:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:47:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:46:in `block (2 levels) in <top (required)>'
```
So far we have seen it in the CI at 0xacab.org and debian.org, not locally.
The messages in question appear to be:
* `spec/fixtures/mails/signed-mime/thunderbird.eml`
* `spec/fixtures/mails/signed-inline/thunderbird.eml`
Actually ruby reports (on my machine) for the relevant mime-part of those messages a `charset` of `utf-8`, but a string encoding of `#<Encoding:ASCII-8BIT>`. Maybe one could find the problem if digging deeper here. (Maybe it's even a thunderbird issue, not actually ours?)3.5.0https://0xacab.org/schleuder/schleuder/-/issues/407CI: rake task to set up the database fails2019-02-09T01:41:06ZgeorgCI: rake task to set up the database fails```
SCHLEUDER_ENV=test SCHLEUDER_CONFIG=spec/schleuder.yml eatmydata bundle exec rake db:init
rake aborted!
Gem::LoadError: Specified 'sqlite3' for database adapter, but the gem is not loaded. Add `gem 'sqlite3'` to your Gemfile (and ens...```
SCHLEUDER_ENV=test SCHLEUDER_CONFIG=spec/schleuder.yml eatmydata bundle exec rake db:init
rake aborted!
Gem::LoadError: Specified 'sqlite3' for database adapter, but the gem is not loaded. Add `gem 'sqlite3'` to your Gemfile (and ensure its version is at the minimum required by ActiveRecord).
/builds/schleuder/schleuder/vendor/ruby/2.5.0/gems/activerecord-4.2.11/lib/active_record/connection_adapters/connection_specification.rb:177:in `rescue in spec'
/builds/schleuder/schleuder/vendor/ruby/2.5.0/gems/activerecord-4.2.11/lib/active_record/connection_adapters/connection_specification.rb:174:in `spec'
/builds/schleuder/schleuder/vendor/ruby/2.5.0/gems/activerecord-4.2.11/lib/active_record/connection_handling.rb:50:in `establish_connection'
/builds/schleuder/schleuder/lib/schleuder.rb:69:in `<top (required)>'
/builds/schleuder/schleuder/Rakefile:2:in `require_relative'
/builds/schleuder/schleuder/Rakefile:2:in `<top (required)>'
/builds/schleuder/schleuder/vendor/ruby/2.5.0/gems/rake-12.3.2/exe/rake:27:in `<top (required)>'
/usr/local/bundle/gems/bundler-2.0.1/lib/bundler/cli/exec.rb:74:in `load'
/usr/local/bundle/gems/bundler-2.0.1/lib/bundler/cli/exec.rb:74:in `kernel_load'
/usr/local/bundle/gems/bundler-2.0.1/lib/bundler/cli/exec.rb:28:in `run'
/usr/local/bundle/gems/bundler-2.0.1/lib/bundler/cli.rb:463:in `exec'
/usr/local/bundle/gems/bundler-2.0.1/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/usr/local/bundle/gems/bundler-2.0.1/lib/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command'
/usr/local/bundle/gems/bundler-2.0.1/lib/bundler/vendor/thor/lib/thor.rb:387:in `dispatch'
/usr/local/bundle/gems/bundler-2.0.1/lib/bundler/cli.rb:27:in `dispatch'
/usr/local/bundle/gems/bundler-2.0.1/lib/bundler/vendor/thor/lib/thor/base.rb:466:in `start'
/usr/local/bundle/gems/bundler-2.0.1/lib/bundler/cli.rb:18:in `start'
/usr/local/bundle/gems/bundler-2.0.1/exe/bundle:30:in `block in <top (required)>'
/usr/local/bundle/gems/bundler-2.0.1/lib/bundler/friendly_errors.rb:124:in `with_friendly_errors'
/usr/local/bundle/gems/bundler-2.0.1/exe/bundle:22:in `<top (required)>'
/usr/local/bundle/bin/bundle:23:in `load'
/usr/local/bundle/bin/bundle:23:in `<main>'
Caused by:
Gem::LoadError: can't activate sqlite3 (~> 1.3.6), already activated sqlite3-1.4.0. Make sure all dependencies are added to Gemfile.
/usr/local/bundle/gems/bundler-2.0.1/lib/bundler/rubygems_integration.rb:408:in `block (2 levels) in replace_gem'
/builds/schleuder/schleuder/vendor/ruby/2.5.0/gems/activerecord-4.2.11/lib/active_record/connection_adapters/sqlite3_adapter.rb:5:in `<top (required)>'
/builds/schleuder/schleuder/vendor/ruby/2.5.0/gems/activesupport-4.2.11/lib/active_support/dependencies.rb:274:in `require'
/builds/schleuder/schleuder/vendor/ruby/2.5.0/gems/activesupport-4.2.11/lib/active_support/dependencies.rb:274:in `block in require'
/builds/schleuder/schleuder/vendor/ruby/2.5.0/gems/activesupport-4.2.11/lib/active_support/dependencies.rb:240:in `load_dependency'
/builds/schleuder/schleuder/vendor/ruby/2.5.0/gems/activesupport-4.2.11/lib/active_support/dependencies.rb:274:in `require'
/builds/schleuder/schleuder/vendor/ruby/2.5.0/gems/activerecord-4.2.11/lib/active_record/connection_adapters/connection_specification.rb:175:in `spec'
/builds/schleuder/schleuder/vendor/ruby/2.5.0/gems/activerecord-4.2.11/lib/active_record/connection_handling.rb:50:in `establish_connection'
/builds/schleuder/schleuder/lib/schleuder.rb:69:in `<top (required)>'
/builds/schleuder/schleuder/Rakefile:2:in `require_relative'
/builds/schleuder/schleuder/Rakefile:2:in `<top (required)>'
/builds/schleuder/schleuder/vendor/ruby/2.5.0/gems/rake-12.3.2/exe/rake:27:in `<top (required)>'
/usr/local/bundle/gems/bundler-2.0.1/lib/bundler/cli/exec.rb:74:in `load'
/usr/local/bundle/gems/bundler-2.0.1/lib/bundler/cli/exec.rb:74:in `kernel_load'
/usr/local/bundle/gems/bundler-2.0.1/lib/bundler/cli/exec.rb:28:in `run'
/usr/local/bundle/gems/bundler-2.0.1/lib/bundler/cli.rb:463:in `exec'
/usr/local/bundle/gems/bundler-2.0.1/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/usr/local/bundle/gems/bundler-2.0.1/lib/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command'
/usr/local/bundle/gems/bundler-2.0.1/lib/bundler/vendor/thor/lib/thor.rb:387:in `dispatch'
/usr/local/bundle/gems/bundler-2.0.1/lib/bundler/cli.rb:27:in `dispatch'
/usr/local/bundle/gems/bundler-2.0.1/lib/bundler/vendor/thor/lib/thor/base.rb:466:in `start'
/usr/local/bundle/gems/bundler-2.0.1/lib/bundler/cli.rb:18:in `start'
/usr/local/bundle/gems/bundler-2.0.1/exe/bundle:30:in `block in <top (required)>'
/usr/local/bundle/gems/bundler-2.0.1/lib/bundler/friendly_errors.rb:124:in `with_friendly_errors'
/usr/local/bundle/gems/bundler-2.0.1/exe/bundle:22:in `<top (required)>'
/usr/local/bundle/bin/bundle:23:in `load'
/usr/local/bundle/bin/bundle:23:in `<main>'
(See full trace by running task with --trace)
```
See [this job](https://0xacab.org/schleuder/schleuder/-/jobs/87143) for example.3.4https://0xacab.org/schleuder/schleuder/-/issues/404CI: changelog job shouldn't hardcode the master branch2019-02-03T15:54:35ZgeorgCI: changelog job shouldn't hardcode the master branchThe current state makes it problematic if not developing against master, as in this case the job is always successful.The current state makes it problematic if not developing against master, as in this case the job is always successful.3.4https://0xacab.org/schleuder/schleuder/-/issues/402Cherry pick/adapt HTML mail leakage fix for release 4.02019-02-03T15:15:41ZNinaCherry pick/adapt HTML mail leakage fix for release 4.0#399 needs to be adapted for release 4.0#399 needs to be adapted for release 4.0Next Big Thingpazpazhttps://0xacab.org/schleuder/schleuder/-/issues/401Cherry-pick upgrade of activerecord into master2019-02-11T00:05:04ZpazCherry-pick upgrade of activerecord into masterRequired to fix dependencies of next debian stable
Commit fa2c4a3Required to fix dependencies of next debian stable
Commit fa2c4a33.4NinaNinahttps://0xacab.org/schleuder/schleuder/-/issues/400Fix issue with factory bots new build strategy2019-02-11T00:05:50ZNinaFix issue with factory bots new build strategyWith the release of factory bot 5.0 the use_parent_strategy has changed. This breaks a few tests on the subscription model.
> Changed: use_parent_strategy now defaults to true, so by default the build strategy will build, rather than cr...With the release of factory bot 5.0 the use_parent_strategy has changed. This breaks a few tests on the subscription model.
> Changed: use_parent_strategy now defaults to true, so by default the build strategy will build, rather than create associations
https://github.com/thoughtbot/factory_bot/releases3.4pazpazhttps://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.4pazpaz