Bug#944348: buster-pu: package schleuder/3.4.0-2+deb10u1

2020-01-14 Thread Adam D. Barratt
On Tue, 2020-01-14 at 19:16 +, Georg Faerber wrote:
> Hi Adam,
> 
> Thanks for your fast response.
> 
> On 20-01-14 18:34:40, Adam D. Barratt wrote:
> > > Reading debian-release@l.d.o [1] it seems that the date for 10.3
> > > is
> > > not yet settled.
> > 
> > You're behind on your reading I'm afraid - 
> > https://lists.debian.org/debian-release/2020/01/msg00238.html
> 
> Thanks for the hint, I missed this.
> 
> > > Therefore: Would it be possible to still extend the already
> > > accepted proposed-update, at this point in time?
> > > 
> > > We just did a sprint upstream and fixed several annoying bugs:
> > 
> > If these are new changes, rather than updates to the fixes in the
> > package you already uploaded, then please open a new pu bug to
> > cover
> > those.
> 
> Will do -- I just wanted to check on the feasibility to get these
> into
> 10.3 still, that is, if I should extend the already accepted update
> (schleuder/3.4.0-2+deb10u1 merging in these new changes) or rather
> should prepare a new version, schleuder/3.4.0-2+deb10u2), on top of
> the already proposed one.

There should still be plenty of time. In any case, it would be +deb10u2
with the new changes (assuming that we agree them in the to-be-opened
bug), as the existing package has already been published to mirrors,
snapshot.d.o, etc.

Any changes that are included would also need to be applied (where
relevant) to unstable first, via whatever approach works best there.

Regards,

Adam



Bug#944348: buster-pu: package schleuder/3.4.0-2+deb10u1

2020-01-14 Thread Georg Faerber
Hi Adam,

Thanks for your fast response.

On 20-01-14 18:34:40, Adam D. Barratt wrote:
> > Reading debian-release@l.d.o [1] it seems that the date for 10.3 is
> > not yet settled.
> 
> You're behind on your reading I'm afraid - 
> https://lists.debian.org/debian-release/2020/01/msg00238.html

Thanks for the hint, I missed this.

> > Therefore: Would it be possible to still extend the already
> > accepted proposed-update, at this point in time?
> > 
> > We just did a sprint upstream and fixed several annoying bugs:
> 
> If these are new changes, rather than updates to the fixes in the
> package you already uploaded, then please open a new pu bug to cover
> those.

Will do -- I just wanted to check on the feasibility to get these into
10.3 still, that is, if I should extend the already accepted update
(schleuder/3.4.0-2+deb10u1 merging in these new changes) or rather
should prepare a new version, schleuder/3.4.0-2+deb10u2), on top of the
already proposed one.

> > The problems in question were reported upstream, not (yet) in the
> > Debian BTS. The proposed code changes are minimal, targeted, guarded
> > by tests and validated in production.
> 
> Are the fixes included in the package currently in unstable?

Not yet -- depending on the above, I could shortly (tomorrow, the
latest) prepare and upload 3.4.1-2 pulling in these changes, or the next
upstream release, 3.5.0-1 soonish, after the upstream release, in case
it's too late for 10.3.

Thanks again,
Georg



Bug#944348: buster-pu: package schleuder/3.4.0-2+deb10u1

2020-01-14 Thread Adam D. Barratt
On Tue, 2020-01-14 at 18:07 +, Georg Faerber wrote:
> Dear SRMs,
> 
> On 19-11-23 18:20:08, Julien Cristau wrote:
> > That looks fine to me.  Go ahead.
> 
> Reading debian-release@l.d.o [1] it seems that the date for 10.3 is
> not yet settled.

You're behind on your reading I'm afraid - 
https://lists.debian.org/debian-release/2020/01/msg00238.html

> Therefore: Would it be possible to still extend the already
> accepted proposed-update, at this point in time?
> 
> We just did a sprint upstream and fixed several annoying bugs:

If these are new changes, rather than updates to the fixes in the
package you already uploaded, then please open a new pu bug to cover
those.

[...]
> The problems in question were reported upstream, not (yet) in the
> Debian BTS. The proposed code changes are minimal, targeted, guarded
> by tests and validated in production.

Are the fixes included in the package currently in unstable?

Regards,

Adam



Bug#944348: buster-pu: package schleuder/3.4.0-2+deb10u1

2020-01-14 Thread Georg Faerber
Dear SRMs,

On 19-11-23 18:20:08, Julien Cristau wrote:
> That looks fine to me.  Go ahead.

Reading debian-release@l.d.o [1] it seems that the date for 10.3 is not yet
settled. Therefore: Would it be possible to still extend the already
accepted proposed-update, at this point in time?

We just did a sprint upstream and fixed several annoying bugs:

  - Add missing List-Id header to notification mails sent to admins:
This should help with filtering such messages, which is currently
not easy to do in a reliable way. [2]

  - Default to ASCII-8BIT encoding for external data:
This should ensure we are able to handle incoming mails in different
character sets. Currently, depending on the environment, which
differs for example between Postfix and Exim, Schleuder may run into
a fatal error due to "invalid byte sequence in US-ASCII". [3]

  - Handle various exceptions due to decryption problems gracefully:
Handle incoming mails encrypted to an absent key, using symmetric
encryption or containing PGP-garbage in a more graceful manner:
Don't throw an exception, don't notify (and annoy) the admins,
instead inform the sender of the mail how to do better. [4]

The problems in question were reported upstream, not (yet) in the Debian
BTS. The proposed code changes are minimal, targeted, guarded by tests
and validated in production.

I did not prepare an updated package yet, but could do so at short
notice, providing a proper diff as well.

Thanks for your work,
cheers,
Georg


[1] https://lists.debian.org/debian-release/2020/01/msg00062.html
[2] 
https://0xacab.org/schleuder/schleuder/commit/ee41fd4215bba6bea5aba12806089e9d415c1bd1
[3] 
https://0xacab.org/schleuder/schleuder/commit/92c7ead414eba3b3787c597b95ff983e32142b56
[4] 
https://0xacab.org/schleuder/schleuder/commit/e9475b7ffd9e640addbb111ae140c6bab0c66eb7



Bug#944348: buster-pu: package schleuder/3.4.0-2+deb10u1

2019-11-24 Thread Georg Faerber
On 19-11-23 18:20:08, Julien Cristau wrote:
> That looks fine to me.  Go ahead.

Thanks -- uploaded accordingly: I've only fixed a typo in the proposed
changelog note, additionally.

Cheers,
Georg



Bug#944348: buster-pu: package schleuder/3.4.0-2+deb10u1

2019-11-23 Thread Julien Cristau
Control: tag -1 confirmed

On Fri, Nov 08, 2019 at 10:57:51AM +, Georg Faerber wrote:
> Schleuder in buster is affected by various problems, which I would like to fix
> with this proposed update:
> 
>   - Schleuder fails to recognize keywords in mails with "protected headers" 
> and
> empty subject. 
> (Ref: #940524)
> 
>   - Schleuder is vulnerable to signature-flooded keys. GPG does not cope well
> with these keys. It will either refuse to import them, or during and after
> the import become so slow to be effectively unusable (while hogging CPUs).
> By default keys are regularly updated from the keyservers (in order to
> receive extended expiry dates, or key revocations). Any list with an
> attacked key in its keyring will become practically unusable and strain 
> the
> server. This is a rather severe problem.
> (Ref: #940526)
> 
>   - Schleuder doesn't report an error, if the argument provided to
> `refresh_keys` is not an existing list, as if the job ran successfully.
> (Ref: #940527)
> 
> All of them are already fixed in unstable. The proposed version is in
> use and was tested in production for the last two weeks.
> 
That looks fine to me.  Go ahead.

Cheers,
Julien



Bug#944348: buster-pu: package schleuder/3.4.0-2+deb10u1

2019-11-08 Thread Georg Faerber
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Dear SRMs,

Schleuder in buster is affected by various problems, which I would like to fix
with this proposed update:

  - Schleuder fails to recognize keywords in mails with "protected headers" and
empty subject. 
(Ref: #940524)

  - Schleuder is vulnerable to signature-flooded keys. GPG does not cope well
with these keys. It will either refuse to import them, or during and after
the import become so slow to be effectively unusable (while hogging CPUs).
By default keys are regularly updated from the keyservers (in order to
receive extended expiry dates, or key revocations). Any list with an
attacked key in its keyring will become practically unusable and strain the
server. This is a rather severe problem.
(Ref: #940526)

  - Schleuder doesn't report an error, if the argument provided to
`refresh_keys` is not an existing list, as if the job ran successfully.
(Ref: #940527)

All of them are already fixed in unstable. The proposed version is in
use and was tested in production for the last two weeks.

I admit that this comes quite late for the upcoming point release 10.2 freeze,
and the diff is rather large, however, most changes are related to test
files. I would be very happy if this still could find its way into
10.2, but I haven't uploaded yet, awaiting your ACK. The full debdiff is
attached.

Thanks in any case for your work -- as always, highly appreciated!

Cheers,
Georg
diff -Nru schleuder-3.4.0/debian/changelog schleuder-3.4.0/debian/changelog
--- schleuder-3.4.0/debian/changelog	2019-06-21 19:05:42.0 +
+++ schleuder-3.4.0/debian/changelog	2019-11-08 10:45:22.0 +
@@ -1,3 +1,23 @@
+schleuder (3.4.0-2+deb10u1) buster; urgency=medium
+
+  * debian/patches:
+- Extend existing patch which fixes problems related to the use of
+  "protected headers": Fix recognizing keywords in mails with protected
+  headers and empty subject. Previously, if the subject was unset,
+  keywords were not recognized and the original "protected headers" could
+  leak.
+  This approach, extending the existing patch, instead of adding a new
+  one, reduces noise and keeps the diff small, as the same part of the
+  code is targeted.
+  (Closes: #940524)
+- Add patch to strip non-self-signatures when refreshing or fetching keys.
+  (Closes: #940526)
+- Add patch to error out if the argument provided to `refresh_keys` is not
+  an existing list.
+  (Closes: #940527)
+
+ -- Georg Faerber   Fri, 08 Nov 2019 10:45:22 +
+
 schleuder (3.4.0-2) unstable; urgency=medium
 
   * debian/patches:
diff -Nru schleuder-3.4.0/debian/patches/0017-mutt-protected-headers.patch schleuder-3.4.0/debian/patches/0017-mutt-protected-headers.patch
--- schleuder-3.4.0/debian/patches/0017-mutt-protected-headers.patch	2019-06-21 19:05:42.0 +
+++ schleuder-3.4.0/debian/patches/0017-mutt-protected-headers.patch	2019-11-08 10:45:22.0 +
@@ -1,31 +1,45 @@
-Description: Handle protected headers produced by Mutt 1.12.0
+Description: Fix various problems related to protected headers
   Mutt 1.12.0, which was recently released, introduced protected headers. These
   headers are just contained within the plain body of a mail produced by Mutt,
   they are not further wrapped into a specifically marked MIME-part. Schleuder
   fails to handle such messages, accordingly, this patch fixes this behaviour.
+
+  Further, this patch fixes recognizing keywords in mails with protected
+  headers and empty subject: Previously, if the subject was unset, keywords
+  were not recognized and the original "protected headers" could leak.
+  (Closes: #940524)
 Origin: upstream
 Forwarded: not-needed
-Applied-Upstream: 0651daf54a520906583aa6de4bb3854575fcb963
-Last-Update: 2019-06-20
+Applied-Upstream: 0651daf54a520906583aa6de4bb3854575fcb963 395a789a18e7e7e6b57af663ed70a51d6c7d1ba2
+Last-Update: 2019-11-08
 ---
 This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
 Index: schleuder/lib/schleuder/mail/message.rb
 ===
 schleuder.orig/lib/schleuder/mail/message.rb
-+++ schleuder/lib/schleuder/mail/message.rb
-@@ -55,7 +55,7 @@ module Mail
+--- schleuder.orig/lib/schleuder/mail/message.rb	2019-11-08 09:29:36.739321755 +
 schleuder/lib/schleuder/mail/message.rb	2019-11-08 09:29:36.735321752 +
+@@ -53,13 +53,12 @@
+   # headers, which reveals protected subjects.
+   if self.subject != new.subject
  new.protected_headers_subject = self.subject.dup
-
- # Delete the protected headers which might leak information.
+-
+-# Delete the protected headers which might leak information.
 -if new.parts.first.content_type == "text/rfc822-headers; protected-headers=v1"
-+if new.parts.first && new.parts.fir