schleuder issueshttps://0xacab.org/schleuder/schleuder/-/issues2022-04-13T10:59:12Zhttps://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/514CI: extend to catch specs which rely on hardcoded key expiry dates2022-04-12T19:37:10ZgeorgCI: extend to catch specs which rely on hardcoded key expiry datesHardcoded key expiry dates makes the Schleuder build fail during reproducible builds. Instead of fixing such code after it has been introduced, it might be more clever to catch it upfront.
Ref #268
Ref #513Hardcoded key expiry dates makes the Schleuder build fail during reproducible builds. Instead of fixing such code after it has been introduced, it might be more clever to catch it upfront.
Ref #268
Ref #5134.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/508bounces_drop_all=true does not bounce but circumvents all filters2022-04-12T18:50:28Zabc defbounces_drop_all=true does not bounce but circumvents all filters## Expected Behavior
`bounces_drop_all=true` should result in all bounces being dropped and not interfere with other filters
(e.g. in case `receive_encrypted_only=true` and someone sends in non-encrypted message, there should be no bounc...## Expected Behavior
`bounces_drop_all=true` should result in all bounces being dropped and not interfere with other filters
(e.g. in case `receive_encrypted_only=true` and someone sends in non-encrypted message, there should be no bounce message to that person notifying them that they have to encrypt the message AND the message should *not* be sent to the list)
## Actual Behavior
There is no bounce, which is okay. But the unencrypted message will then be distributed to the list even with `receive_encrypted_only=true`, which is not okay.
## Steps to Reproduce the Problem
1. Set `receive_encrypted_only=true`. Test that this results in a bounce if someone sends an unencrypted message. The message is correctly *not* distributed to the list.
2. Set `bounces_drop_all=true` additionally. Test again with same unencrypted message. No bounce which is okay, but the unencrypted message will be processed and distributed to the list, which should not be the case.
## Specifications
- Version: 4.0.2 (and also reproducable in 3.5.3)
- Installation method (package, gem...): package/gem
- Mail client version: all
## Other information
I quickly debugged it and I think, maybe it is because of `bounces_drop_all=true` causes:
https://0xacab.org/schleuder/schleuder/-/blob/main/lib/schleuder/filters_runner.rb#L39 to return false
This causes run() to return nil:
https://0xacab.org/schleuder/schleuder/-/blob/main/lib/schleuder/filters_runner.rb#L19
Which causes this to return nil:
https://0xacab.org/schleuder/schleuder/-/blob/main/lib/schleuder/runner.rb#L89
I think this then causes this no error return:
https://0xacab.org/schleuder/schleuder/-/blob/main/lib/schleuder/runner.rb#L34
```
error = run_filters('post')
return error if error
```
Which means, as the run() does not return early, the message is still being sent to everyone.
Is it possible for you to reproduce? Does my debugging makes sense?
I can work on a fix if you can reproduce it and think this is not intended.4.0.3abc defabc defhttps://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.3georggeorg