Bug#1010050: bullseye-pu: package clementine/1.4.0~rc1+git347-gfc4cb6fc7+dfsg-1+deb11u1

2022-04-23 Thread Florian Ernst 
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Thomas Pierson 

[ Reason ]
Clementine fails to start if the package libqt5sql5-sqlite is not
installed, i.e. clementine is missing a Depends. This was reported in
#1008312, an identical fix has already been uploaded to Unstable.

[ Impact ]
Users need to realize that a Depends is missing that they need to
install manually. As it is, clementine might simply fail to start.
Clementine's error messages indicate that something is missing, but
finding the relevant missing package is hard for end users.

[ Tests ]
There are no code changes at all, clementine just gains an explicit
Depends on a package that most QT users will already have installed
anyways. I'm running the updated package on my local Bullseye just fine.

[ Risks ]
No code changes at all, a trivial fix, and the newly added Depends on
libqt5sql5-sqlite can be fulfilled on all release archs. There had been
a binNMU in Stable that had me worrying whether the versioning of the
proposed upload was correct, but according to apt/dpkg it all works as
intended, cf.
| ~/debian/temp/clementine $ apt policy clementine
| clementine:
|   Installed: 1.4.0~rc1+git347-gfc4cb6fc7+dfsg-1+deb11u1
|   Candidate: 1.4.0~rc1+git347-gfc4cb6fc7+dfsg-1+deb11u1
|   Version table:
|  1.4.0~rc1+git347-gfc4cb6fc7+dfsg-2.1 50
|  50 http://deb.debian.org/debian unstable/main amd64 Packages
|  1.4.0~rc1+git347-gfc4cb6fc7+dfsg-2 50
|  50 http://deb.debian.org/debian testing/main amd64 Packages
|  *** 1.4.0~rc1+git347-gfc4cb6fc7+dfsg-1+deb11u1 100
| 100 /var/lib/dpkg/status
|  1.4.0~rc1+git347-gfc4cb6fc7+dfsg-1+b1 990
| 990 http://deb.debian.org/debian bullseye/main amd64 Packages
|  1.3.1+git609-g623a53681+dfsg-1 990
| 990 http://deb.debian.org/debian buster/main amd64 Packages
| ~/debian/temp/clementine $ dpkg --compare-versions 
'1.4.0~rc1+git347-gfc4cb6fc7+dfsg-1+deb11u1' gt 
'1.4.0~rc1+git347-gfc4cb6fc7+dfsg-1+b1' && echo true
| true

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
Add explicit Depends on libqt5sql5-sqlite.

[ Other info ]
In the past other packages were impacted similarly and also fixed this
by adding an explicit Depends, e.g.
- kaffeine 1.0~pre3-1 (updated in kaffeine 2.0.3-1)
- kstars 4:16.08.3-2, #854516
- ktouch 4:19.08.3-2, LP#1790955

I'll upload once I receive your approval.

Cheers,
Flo
diff -Nru clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/changelog 
clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/changelog
--- clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/changelog
2020-10-27 11:30:27.0 +0100
+++ clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/changelog
2022-04-23 09:29:26.0 +0200
@@ -1,3 +1,10 @@
+clementine (1.4.0~rc1+git347-gfc4cb6fc7+dfsg-1+deb11u1) bullseye; 
urgency=medium
+
+  * Non-maintainer upload.
+  * Add explicit Depends on libqt5sql5-sqlite (Closes: #1008312)
+
+ -- Florian Ernst   Sat, 23 Apr 2022 09:29:26 +0200
+
 clementine (1.4.0~rc1+git347-gfc4cb6fc7+dfsg-1) unstable; urgency=medium
 
   * New upstream snapshot.
diff -Nru clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/control 
clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/control
--- clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/control  2020-10-27 
11:30:27.0 +0100
+++ clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/control  2022-04-23 
09:12:37.0 +0200
@@ -38,6 +38,7 @@
 Package: clementine
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends},
+ libqt5sql5-sqlite,
  gstreamer1.0-plugins-base,
  gstreamer1.0-plugins-good,
  gstreamer1.0-plugins-ugly


signature.asc
Description: PGP signature

Bug#1010050: bullseye-pu: package clementine/1.4.0~rc1+git347-gfc4cb6fc7+dfsg-1+deb11u1

2022-05-30 Thread Florian Ernst 
On Sat, May 28, 2022 at 08:17:47PM +0100, Adam D. Barratt wrote:
> On Sat, 2022-04-23 at 10:25 +0200, Florian Ernst wrote:
> > Clementine fails to start if the package libqt5sql5-sqlite is not
> > installed, i.e. clementine is missing a Depends. This was reported in
> > #1008312, an identical fix has already been uploaded to Unstable.
> > 
> > [ Impact ]
> > Users need to realize that a Depends is missing that they need to
> > install manually. As it is, clementine might simply fail to start.
> > Clementine's error messages indicate that something is missing, but
> > finding the relevant missing package is hard for end users.
> > 
> 
> Please go ahead.

Thanks, just uploaded.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1013670: transition: srt

2022-06-24 Thread Florian Ernst 
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear Release Team,

please grant a transition slot for the srt transition.

Upstream has changed the soname from 1.4 to 1.5, and the srt packaging
has been adjusted to reflect this. The following source package have
been build-depending on srt:

ffmpeg
gst-plugins-bad1.0
nageru
vlc

I have successfully rebuilt all of them on amd64 against srt as present
in experimental, where srt itself has successfully built on all release
architectures..

The information on
https://release.debian.org/transitions/html/auto-srt.html looks correct
to me.

Ben file:

title = "srt";
is_affected = .depends ~ "libsrt1.4-gnutls" | .depends ~ "libsrt1.4-openssl" | 
.depends ~ "libsrt1.5-gnutls" | .depends ~ "libsrt1.5-openssl";
is_good = .depends ~ "libsrt1.5-gnutls" | .depends ~ "libsrt1.5-openssl";
is_bad = .depends ~ "libsrt1.4-gnutls" | .depends ~ "libsrt1.4-openssl";

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1013670: transition: srt

2022-06-29 Thread Florian Ernst 
On Wed, Jun 29, 2022 at 10:37:12PM +0200, Sebastian Ramacher wrote:
> On 2022-06-25 13:46:45 +0200, Sebastian Ramacher wrote:
> > On 2022-06-24 17:32:43, Florian Ernst wrote:
> > > please grant a transition slot for the srt transition.
> > > [...]
> > 
> > Let's wait until ffmpeg migrated and then we should be good to go ahead
> > with this one.
> 
> Please go ahead

Thanks. I'm planning to add some finetuning to the current packaging and
then to upload on Saturday.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1013670: transition: srt

2022-07-02 Thread Florian Ernst 
On Thu, Jun 30, 2022 at 07:53:50AM +0200, Florian Ernst wrote:
> On Wed, Jun 29, 2022 at 10:37:12PM +0200, Sebastian Ramacher wrote:
> > On 2022-06-25 13:46:45 +0200, Sebastian Ramacher wrote:
> > > On 2022-06-24 17:32:43, Florian Ernst wrote:
> > > > please grant a transition slot for the srt transition.
> > > > [...]
> > > 
> > > Let's wait until ffmpeg migrated and then we should be good to go ahead
> > > with this one.
> > 
> > Please go ahead
> 
> Thanks. I'm planning to add some finetuning to the current packaging and
> then to upload on Saturday.

srt 1.5.0-2 has just been uploaded to unstable, thanks for taking care.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#592944: future unblock: libhtml-template-perl/2.9-2

2010-08-14 Thread Florian Ernst 
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception

Hello there,

I'm planning to upload libhtml-template-perl/2.9-2 with the attached
changes. There are no upstream code changes involved.
Diffstat as follows:
| Template.pm  |2 
| debian/changelog |   17 
| debian/control   |   11 +-
| debian/patches/manpage_back_doesnt_take_parameters.patch |   16 +++
| debian/patches/manpage_html_fix.patch|   19 
| debian/patches/manpage_spelling_fixes.patch  |   61 
+++
| debian/patches/series|3 
| debian/rules |2 
| debian/source/format |1 
| 9 files changed, 124 insertions(+), 8 deletions(-)
$ debdiff libhtml-template-perl_2.9-1_i386.changes 
libhtml-template-perl_2.9-2_amd64.changes
| File lists identical on package level (after any substitutions)
| 
| Control files: lines which differ (wdiff format)
| 
| Depends: perl [-(>= 5.6.0-16)-]
| Description: [-HTML::Template : A-] module for using HTML Templates with
| Perl
|  [-This module-]
|   {+HTML::Template+} attempts make using HTML templates simple and
|   natural.  It
|[-.-]
|Installed-Size: [-208-] {+204+}
|Version: [-2.9-1-] {+2.9-2+}

This is a late cleanup, actually planned to be done shortly before the
freeze, but it seems I had false assumptions and was thus now surprised.
Sorry for the additional work.

Would you still accept this for Squeeze?

unblock libhtml-template-perl/2.9-2

-- System Information:
Debian Release: squeeze/sid
  APT prefers oldstable
  APT policy: (990, 'oldstable'), (990, 'testing'), (990, 'stable'), (500, 
'oldstable-proposed-updates'), (50, 'testing-proposed-updates'), (50, 
'proposed-updates'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru libhtml-template-perl-2.9/debian/changelog 
libhtml-template-perl-2.9/debian/changelog
--- libhtml-template-perl-2.9/debian/changelog  2010-08-14 13:38:34.0 
+0200
+++ libhtml-template-perl-2.9/debian/changelog  2010-08-14 13:33:06.0 
+0200
@@ -1,3 +1,20 @@
+libhtml-template-perl (2.9-2) unstable; urgency=low
+
+  * Template.pm:
++ convert existing patch for fixing HTML to manpage_html_fix.patch
++ fix POD error "=back doesn't take any parameters" via
+  manpage_back_doesnt_take_parameters.patch
++ fix manpage spelling errors via manpage_spelling_fixes.patch
+  * debian/rules: DESTDIR instead of PREFIX (Debian Perl Policy section 4.3)
+  * debian/source/format: use "3.0 (quilt)"
+  * debian/control:
++ improve package description; make use of Homepage: field (Closes: 
#530737)
++ drop versioning from Build-Depends-Indep on perl as even oldstable
+  provides this
++ packaging now conforms with Standards-Version 3.9.1 
+
+ -- Florian Ernst   Sat, 14 Aug 2010 13:32:59 +0200
+
 libhtml-template-perl (2.9-1) unstable; urgency=low
 
   * New upstream release
diff -Nru libhtml-template-perl-2.9/debian/control 
libhtml-template-perl-2.9/debian/control
--- libhtml-template-perl-2.9/debian/control2010-08-14 13:38:34.0 
+0200
+++ libhtml-template-perl-2.9/debian/control2010-08-11 20:22:09.0 
+0200
@@ -3,15 +3,16 @@
 Priority: optional
 Maintainer: Florian Ernst 
 Build-Depends: debhelper (>= 5)
-Build-Depends-Indep: perl (>= 5.6.0-16), libipc-sharedcache-perl
-Standards-Version: 3.7.2
+Build-Depends-Indep: perl, libipc-sharedcache-perl
+Standards-Version: 3.9.1
+Homepage: http://search.cpan.org/~samtregar/HTML-Template/
 
 Package: libhtml-template-perl
 Architecture: all
 Suggests: libipc-sharedcache-perl
 Depends: ${perl:Depends}, ${misc:Depends}
-Description: HTML::Template : A module for using HTML Templates with Perl
- This module attempts make using HTML templates simple and natural.  It
+Description: module for using HTML Templates with Perl
+ HTML::Template attempts make using HTML templates simple and natural.  It
  extends standard HTML with a few new HTML-esque tags - ,
  , ,  and .  The file
  written with HTML and these new tags is called a template.  It is
@@ -24,5 +25,3 @@
  This module allows you to store its cache in shared memory using the
  IPC::SharedCache module, please install libipc-sharedcache-perl if you
  want to make use of this.
- .
-  Homepage: http://search.cpan.org/~samtregar/HTML-Template/
diff -Nru 
libhtml-template-perl-2.9/debian/patches/manpage_back_doesnt_take_parameters.patch
 
l

Bug#592944: future unblock: libhtml-template-perl/2.9-2

2010-08-14 Thread Florian Ernst 
On Sat, Aug 14, 2010 at 01:09:21PM +0100, Adam D. Barratt wrote:
> On Sat, 2010-08-14 at 13:49 +0200, Florian Ernst wrote:
> > I'm planning to upload libhtml-template-perl/2.9-2 with the attached
> > changes. There are no upstream code changes involved.
> 
> Please go ahead and let us know once the package has been accepted.

Uploaded, just accepted, thanks!

Cheers,
Flo


signature.asc
Description: Digital signature

one-liner for CVE-2007-1253 coupled with some late non-code fixes

2007-03-14 Thread Florian Ernst 
Dear RMs,

the upcoming 2.42a-6 of blender addresses CVE-2007-1253 (eval injection
vulnerability in the kmz_ImportWithMesh.py script) currently affecting
unstable/testing only.
Upstream's take on this issue was to simply remove the buggy script, and
we decided to follow suit, so this fix is basically a one-liner.

However, there are some late documentation fixes and an update to
debian/copyright we'd like to include as well, so I'm wondering whether
you might find the attached debdiff acceptable.

If not I will upload a new -6 containing just the changes you deem
acceptable and ask for propagation to testing once it will be built.

Cheers,
Flo
diff -u blender-2.42a/debian/changelog blender-2.42a/debian/changelog
--- blender-2.42a/debian/changelog
+++ blender-2.42a/debian/changelog
@@ -1,3 +1,14 @@
+blender (2.42a-6) unstable; urgency=high
+
+  * Security: No longer ship the kmz_ImportWithMesh.py script since it allows
+user-assisted remote attackers to execute arbitrary Python code by
+importing a crafted (1) KML or (2) KMZ file [CVE-2007-1253].
+  * Updated copyright to reflect the actual license (Closes: #407917).
+  * Added documentation (NEWS, README.Debian) about 64-bit related risks.
+  * Added myself to the Uploaders.
+
+ -- Cyril Brulebois <[EMAIL PROTECTED]>  Wed, 14 Mar 2007 11:06:13 +0100
+
 blender (2.42a-5) unstable; urgency=high
 
   * urgency=high due to RC bugfix targetted at testing
diff -u blender-2.42a/debian/control blender-2.42a/debian/control
--- blender-2.42a/debian/control
+++ blender-2.42a/debian/control
@@ -2,7 +2,7 @@
 Section: graphics
 Priority: optional
 Maintainer: Debian Blender Maintainers <[EMAIL PROTECTED]>
-Uploaders: Masayuki Hatta (mhatta) <[EMAIL PROTECTED]>, Florian Ernst <[EMAIL 
PROTECTED]>, Wouter van Heyst <[EMAIL PROTECTED]>
+Uploaders: Masayuki Hatta (mhatta) <[EMAIL PROTECTED]>, Florian Ernst <[EMAIL 
PROTECTED]>, Wouter van Heyst <[EMAIL PROTECTED]>, Cyril Brulebois <[EMAIL 
PROTECTED]>
 Build-Depends: debhelper (>= 5.0.37.2), dpatch, ftgl-dev (>= 2.0.9-1), gettext 
(>= 0.14.1), libgettextpo-dev, libglut-dev, libjpeg-dev, libpng-dev, 
libsdl-dev, libz-dev, python2.4-dev, python-central (>= 0.4.17), scons, 
libtiff4-dev, libopenexr-dev, libavformat-dev, libxi-dev, autotools-dev, 
pkg-config, g++-3.3 [mips mipsel]
 XS-Python-Version: 2.4
 Standards-Version: 3.7.2
diff -u blender-2.42a/debian/rules blender-2.42a/debian/rules
--- blender-2.42a/debian/rules
+++ blender-2.42a/debian/rules
@@ -120,6 +120,9 @@
cp $(CURDIR)/debian/blender.linda-overrides \
   $(CURDIR)/debian/blender/usr/share/linda/overrides/blender
 
+   # Needed removal, insecure script, see CVE-2007-1253
+   rm 
$(CURDIR)/debian/blender/usr/lib/blender/scripts/kmz_ImportWithMesh.py
+
 
 # Build architecture-independent files here.
 binary-indep: build install
diff -u blender-2.42a/debian/copyright blender-2.42a/debian/copyright
--- blender-2.42a/debian/copyright
+++ blender-2.42a/debian/copyright
@@ -9,7 +9,7 @@
 
 Basically, Blender is now GPL'd:
 
-  Copyright (C) 2002 Blender Foundation.
+  Copyright (C) 2002-2005 Blender Foundation.
   
   Blender is free software; you can redistribute it and/or modify it
   under the terms of the GNU General Public License as published by
@@ -24,53 +24,42 @@
-  On Debian GNU/Linux systems, the complete text of the GNU General
-  Public License can be found in /usr/share/common-licenses/GPL'.
+On Debian GNU/Linux systems, the complete text of the GNU General
+Public License can be found in /usr/share/common-licenses/GPL'.
 
-However, they offer the following license as an alternative, too:
 
-  Blender License 1.0 (the "BL", see http://www.blender.org/BL/ ).
+However, the following license is offered as an alternative:
 
-  Copyright (C) 2002 Blender Foundation. All Rights Reserved.
-
-  For teams that don't want to operate under the GPL, we're also offering
-  this "non-GPL" Blender License option. This means that you can download
-  the latest sources and tools via FTP or CVS from our site and sign an
-  additional agreement with the Blender Foundation, so you can keep your
-  source modifications confidential. Contact the Blender Foundation via
-  email at [EMAIL PROTECTED] so we can discuss how we handle the
-  practical matters.
-
-  A signed agreement allows you to do business with proprietary code, make
-  special derived versions, sell executables, projects or services,
-  provided that:
-
-  1. The BL-ed code remains copyrighted by the original owners, and cannot
-  be transferred to other parties
-
-  2. The BL-ed code cannot be published or re-distributed in any way, and
-  only be available for the internal staff that works directly on the
-  software itself. Employees of partners with which you co-develop on the
-  projects that include BL-ed code are considered 'internal staff'

Re: [Secure-testing-team] CVE-2007-1253: blender: eval injection vulnerability in kmz_ImportWithMesh.py

2007-03-28 Thread Florian Ernst 
On Tue, Mar 27, 2007 at 09:50:16PM +0200, Moritz Muehlenhoff wrote:
> Florian Ernst wrote:
> 
> > > Can you make an etch upload with only the removal of the buggy script?
> >   
> > Just for clarity's sake, you mean uploading to testing-proposed-updates?
> 
> Yes.
> 
> > And it will get accepted?
> 
> The change in question would warrant a DSA, so I'm quite sure it will
> get accepted if it only contains the change below. It's easily reviewable
> and fixes a genuine security problem.

Very well, so here we go. :)

RMs, please accept blender_2.42a-5etch1. Debdiffs attached.

> > Sorry for being dense, I hope you can clarify,
> > Cheers,
> > Flo
> 
> I hope that helped.

Yes, thanks Moritz!

Cheers,
Flo
diff -u blender-2.42a/debian/changelog blender-2.42a/debian/changelog
--- blender-2.42a/debian/changelog
+++ blender-2.42a/debian/changelog
@@ -1,3 +1,12 @@
+blender (2.42a-5etch1) testing-proposed-updates; urgency=high
+
+  * Upload to t-p-u after talking to the security team
+  * Security: No longer ship the kmz_ImportWithMesh.py script since it allows
+user-assisted remote attackers to execute arbitrary Python code by
+importing a crafted (1) KML or (2) KMZ file [CVE-2007-1253].
+
+ -- Florian Ernst <[EMAIL PROTECTED]>  Wed, 28 Mar 2007 00:45:05 +0200
+
 blender (2.42a-5) unstable; urgency=high
 
   * urgency=high due to RC bugfix targetted at testing
diff -u blender-2.42a/debian/rules blender-2.42a/debian/rules
--- blender-2.42a/debian/rules
+++ blender-2.42a/debian/rules
@@ -120,6 +120,9 @@
cp $(CURDIR)/debian/blender.linda-overrides \
   $(CURDIR)/debian/blender/usr/share/linda/overrides/blender
 
+   # Needed removal, insecure script, see CVE-2007-1253
+   rm 
$(CURDIR)/debian/blender/usr/lib/blender/scripts/kmz_ImportWithMesh.py
+
 
 # Build architecture-independent files here.
 binary-indep: build install
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files only in first set of .debs, found in package blender
--
-rw-r--r--  root/root   /usr/lib/blender/scripts/kmz_ImportWithMesh.py


Control files: lines which differ (wdiff format)

Version: [-2.42a-5-] {+2.42a-5etch1+}
Depends: liba52-0.7.4, libavcodec0d (>= 0.cvs20060823), libavformat0d (>= 
0.cvs20060823), libc6 (>= 2.3.6-6), libdc1394-13, libfreetype6 (>= 2.2), 
libgcc1 (>= 1:4.1.1-12), libgettextpo0, libgl1-mesa-glx | libgl1, libglu1-mesa 
| libglu1, libgsm1 (>= 1.0.10), libjpeg62, libogg0 (>= 1.1.3), libopenexr2c2a 
(>= 1.2.2), libpng12-0 (>= [-1.2.8rel),-] {+1.2.13-4),+} libraw1394-8, 
libsdl1.2debian (>= 1.2.10-1), libstdc++6 (>= 4.1.1-12), libvorbis0a (>= 
1.1.2), libvorbisenc2 (>= 1.1.2), libx11-6, libxi6, python2.4 (>= 2.3.90), 
zlib1g (>= 1:1.2.1), python-central (>= 0.5.8)
Installed-Size: [-16144-] {+16112+}


signature.asc
Description: Digital signature

Re: Accepted blender 2.42a-5etch1 (source i386)

2007-03-28 Thread Florian Ernst 
On Wed, Mar 28, 2007 at 04:03:09AM -0700, Steve Langasek wrote:
> On Wed, Mar 28, 2007 at 10:47:04AM +0000, Florian Ernst wrote:
> >  blender (2.42a-5etch1) testing-proposed-updates; urgency=high
> >  .
> >* Upload to t-p-u after talking to the security team
> >* Security: No longer ship the kmz_ImportWithMesh.py script since it 
> > allows
> >  user-assisted remote attackers to execute arbitrary Python code by
> >  importing a crafted (1) KML or (2) KMZ file [CVE-2007-1253].
> 
> Uhm?  I just saw Moritz quoted as saying:
> 
> > The change in question would warrant a DSA, so I'm quite sure it will
> > get accepted if it only contains the change below. It's easily reviewable
> > and fixes a genuine security problem.

Right. And a few lines above this:

| On Tue, Mar 27, 2007 at 09:50:16PM +0200, Moritz Muehlenhoff wrote:
| > Florian Ernst wrote:
| >
| > > > Can you make an etch upload with only the removal of the buggy script?
| > >   
| > > Just for clarity's sake, you mean uploading to testing-proposed-updates?
| >
| > Yes.

> If it warrants a DSA, why was this not uploaded to testing-security instead
> of testing-proposed-updates?

Moritz, did you actually mean testing-security instead of t-p-u? If so I
probably didn't express myself clearly enough ... :/

Well, my aim as a maintainer is to get this fix into Etch. When
approaching d-release about this I was referred to security, while
security asked me to upload to t-p-u, or at least so I understood and
tried to clarify.
Please, how to best proceed from here?

Cheers,
Flo


PS: I'm subscribed to d-release.


signature.asc
Description: Digital signature

Re: Accepted blender 2.42a-5etch1 (source i386)

2007-03-31 Thread Florian Ernst 
Hi there,

JFYI, just to let you know ...

On Wed, Mar 28, 2007 at 09:42:13PM -0700, Steve Langasek wrote:
> [...]  But, having been uploaded to
> t-p-u, we'll go with it, it just may take longer this way to be built on all
> architectures.

Oh, indeed: unfortunately, the build failed on arm, mips and sparc.

However, as the build toolchain was about 12, 17 and 10 months old,
respectively, I strongly suspect this to be the cause for the failed
build, given that the other architectures managed to build the package
just fine (except for m68k due to a timeout) and that -6 has been build
successfully in unstable by *all* architectures.

Mail has been sent to [EMAIL PROTECTED] about this. Thanks again
to Cyril for taking initiative.

Cheers,
Flo


signature.asc
Description: Digital signature

Re: [Secure-testing-team] CVE-2007-1253: blender: eval injection vulnerability in kmz_ImportWithMesh.py

2007-04-04 Thread Florian Ernst 
On Wed, Apr 04, 2007 at 07:37:05PM +0200, Luk Claes wrote:
> Florian Ernst wrote:
> > RMs, please accept blender_2.42a-5etch1. Debdiffs attached.
> 
> It will be approved if the mips and sparc builds get built and uploaded in 
> time...

Of course, it needs to be autobuilt on all archs. However, is there
anything I can do to ensure this will happen other than pinging the
buildd maintainers?

Cheers,
Flo


PS: No need to CC, I'm subscribed.


signature.asc
Description: Digital signature

Re: [Secure-testing-team] CVE-2007-1253: blender: eval injection vulnerability in kmz_ImportWithMesh.py

2007-04-04 Thread Florian Ernst 
On Wed, Apr 04, 2007 at 10:40:04PM +0200, Luk Claes wrote:
> Florian Ernst wrote:
> > On Wed, Apr 04, 2007 at 07:37:05PM +0200, Luk Claes wrote:
> >> Florian Ernst wrote:
> >>> RMs, please accept blender_2.42a-5etch1. Debdiffs attached.
> >> It will be approved if the mips and sparc builds get built and uploaded in 
> >> time...
> > 
> > Of course, it needs to be autobuilt on all archs. However, is there
> > anything I can do to ensure this will happen other than pinging the
> > buildd maintainers?
> 
> Apparantly blender FTBFS on these archs, so finding out why it fails (and
> maybe fixing it) might help.

I haven't seen blender FTBFS on a *current* testing (or unstable, fwiw)
for quite some time for all release archs. So far I'm not convinced the
blender package needs any further changes in order to get built
reliably.
I'd very much like to see a build log from an *updated* testing system
on sparc and mips. If it still FTBFS I'll start to investigate asap.

Cheers,
Flo


signature.asc
Description: Digital signature

Re: [Secure-testing-team] CVE-2007-1253: blender: eval injection vulnerability in kmz_ImportWithMesh.py

2007-04-04 Thread Florian Ernst 
On Wed, Apr 04, 2007 at 11:12:50PM +0200, Luk Claes wrote:
> Florian Ernst wrote:
> > I'd very much like to see a build log from an *updated* testing system
> > on sparc and mips. If it still FTBFS I'll start to investigate asap.
> 
> So you did try to build it on mips and sparc on testing and the builds 
> succeeded?

No builds of blender_2.42a-5etch1 on mips and sparc on testing have been
attempted so far, unless you count those listing
| Toolchain package versions: libc6-dev_2.3.5-8 
linux-kernel-headers_2.6.13+0rc3-2 gcc-4.1_4.1.1-13 binutils_2.17-2 
libstdc++6_4.1.1-13
and
| Toolchain package versions: libc6-dev_2.3.6-15 
linux-kernel-headers_2.6.13+0rc3-2 gcc-4.1_4.1.1-21 binutils_2.17-1 
libstdc++6_4.1.1-21
i.e. listing some somewhat outdated packages within the build
environment.
When looking at the full build logs I find lines like
| In file included from 
/usr/lib/gcc/mips-linux-gnu/4.0.3/../../../../include/c++/4.0.3/mips-linux-gnu/bits/os_defines.h:39,
^   
  ^
and
| In file included from 
/usr/lib/gcc/sparc-linux-gnu/4.0.4/../../../../include/c++/4.0.4/sparc-linux-gnu/bits/os_defines.h:39,
 ^  
   ^
which I understand to indicate something's broken on the hosts.

On the other hand, the toolchain is frozen for quite some time and
identical both in testing and unstable, and blender_2.42a-6 which is
identical code-wise to -5etch1 has built on all archs, including mips
and sparc, without any problems.
Incidentally, -5etch1 previously FTBFS on arm as well with the same
symptoms and error, but since then the build environment has been
(sufficiently) fixed and blender has been requeued and built just fine.

So, up to now, I assume the blender package to be innocent until proven
guilty. Furthermore, I believe simply updating the testing environments
on mips and sparc will allow the package to build just fine.

As I don't have access to any updated Etch environment on mips or sparc
with all B-Ds installed I didn't try manually building the package, but
even if I did and it succeeded I'd still prefer seeing the package built
reliably on the autobuilders.
In my view, it simply hasn't been tried to build blender_2.42a-5etch1 in
an Etch environment on mips and sparc, that's why I'd very much like to
see a build log from an *updated* system.

Cheers,
Flo


signature.asc
Description: Digital signature

Re: [Secure-testing-team] CVE-2007-1253: blender: eval injection vulnerability in kmz_ImportWithMesh.py

2007-04-04 Thread Florian Ernst 
On Wed, Apr 04, 2007 at 03:42:13PM -0700, Steve Langasek wrote:
> On Thu, Apr 05, 2007 at 12:21:52AM +0200, Florian Ernst wrote:
> > On the other hand, the toolchain is frozen for quite some time and
> > identical both in testing and unstable, and blender_2.42a-6 which is
> > identical code-wise to -5etch1 has built on all archs, including mips
> > and sparc, without any problems.
> 
> Please refresh my memory, is there some reason we don't want to accept -6
> from unstable into etch?

<http://lists.debian.org/debian-release/2007/03/msg00677.html> lists
your reasons. So far I assumed they still apply.

In the light of the recent issues, would you prefer a -7 upload
reverting everything from -6 except for the one-liner to fix
CVE-2007-1253 (thus being identical to -5etch1)?

Cheers,
Flo


signature.asc
Description: Digital signature

RFFE for ht_0.8.0-2

2005-05-11 Thread Florian Ernst 
Dear RMs,

please grant a freeze exception for the ht package replacing the
current ht_0.8.0-1 with 0.8.0-2, of course pending the (so far)
missing powerpc and m68k builds and the usual grace period.

Bug#308587 (grave, security) has been fixed in ht_0.8.0-2, the changelog
reads as follows:

+ht (0.8.0-2) unstable; urgency=high
+
+  * Urgency high due to security fix
+  * Security fix pulled from upstream CVS (Closes: #308587)
++ fix an integer overflow in the ELF segment parsing
+  (cplus-dem.c, htanaly.cc, htcoff.cc, htelf.cc, htpef.cc, htpeimp.cc)
++ fix some buffer overflows in the PE parser
+  (htperes.cc)
++ this is also Gentoo GLSA 200505-08
+Thanks a lot to Moritz Muehlenhoff for the report!
+  * debian/control: added upstream homepage to long description
+
+ -- Florian Ernst <[EMAIL PROTECTED]>  Wed, 11 May 2005 20:02:24 +0200

No further changes have been applied, the package is lintian / linda /
debdiff clean and seems to compile (pbuilder) and run (chroot) just
fine. omg, I feel like being back at d-mentors again... :)

Additionally I've just contacted the security team wrt the possible
impact on Woody.

Thanks for all your hard work,
cheers,
Flo


signature.asc
Description: Digital signature

Bug#1036456: unblock: libfastjson/1.2304.0-1

2023-05-21 Thread Florian Ernst 
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: libfastj...@packages.debian.org, bi...@debian.org
Control: affects -1 + libfastjson

Please unblock package libfastjson

A new upstream version of libfastjson fixes a security bug
(CVE-2020-12762, #1035302). They also changed the release numbering,
hence the seemingly huge jump, but the actual diff is quite small.

[ Reason ]
"Prevent signed integer overflows with large buffers", as upstream
states inline, cf.
.
.

[ Impact ]
Without this change the above vulnerability remains. However, according
to upstream rsyslog - the main and almost sole user of this library -
was not affected anyways due to size limits.

[ Tests ]
There is some coverage via upstream's tests/test_printbuf.c that is run
during build time. The code in question is also tested in json-c, cf.
.

[ Risks ]
Via rsyslog this library is a key package. However, the new code merely
adds some straightforward checks against signed integer overflows, which
are already part of json-c in buster, bullseye, bookworm, and sid, cf.
.
The new libfastjson release has entered unstable 18 days ago, and so far
no bugs seem to have surfaced due to this change.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them (disclaimer below)
  [x] attach debdiff against the package in testing

I am not the package maintainer but merely the bug submitter. However,
Michael expressed he wouldn't object if I want to pursue this, cf.
.

unblock libfastjson/1.2304.0-1
diff -Nru libfastjson-0.99.9/ChangeLog libfastjson-1.2304.0/ChangeLog
--- libfastjson-0.99.9/ChangeLog2021-01-25 13:52:55.0 +0100
+++ libfastjson-1.2304.0/ChangeLog  2023-04-17 15:51:20.0 +0200
@@ -1,3 +1,8 @@
+1.2304.0, 2023-04-18
+- change of release number scheme, now like rsyslog
+- fix Fix CVE-2020-12762
+  Note: the CVE did not affect rsyslog use due to size limits
+  Thanks to Wang Haitao for the patch.
 0.99.9 2021-01-26
 - add API fjson_object_get_uint()
   Thanks to Janmejay Singh for contributing the patch.
diff -Nru libfastjson-0.99.9/configure libfastjson-1.2304.0/configure
--- libfastjson-0.99.9/configure2021-01-25 13:53:09.0 +0100
+++ libfastjson-1.2304.0/configure  2023-04-17 15:54:00.0 +0200
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for libfastjson 0.99.9.
+# Generated by GNU Autoconf 2.69 for libfastjson 1.2304.0.
 #
 # Report bugs to .
 #
@@ -590,8 +590,8 @@
 # Identity of this package.
 PACKAGE_NAME='libfastjson'
 PACKAGE_TARNAME='libfastjson'
-PACKAGE_VERSION='0.99.9'
-PACKAGE_STRING='libfastjson 0.99.9'
+PACKAGE_VERSION='1.2304.0'
+PACKAGE_STRING='libfastjson 1.2304.0'
 PACKAGE_BUGREPORT='rsys...@lists.adiscon.com'
 PACKAGE_URL=''
 
@@ -1336,7 +1336,7 @@
   # Omit some internal or obsolete options to make the list less imposing.
   # This message is too long to be a string in the A/UX 3.1 sh.
   cat <<_ACEOF
-\`configure' configures libfastjson 0.99.9 to adapt to many kinds of systems.
+\`configure' configures libfastjson 1.2304.0 to adapt to many kinds of systems.
 
 Usage: $0 [OPTION]... [VAR=VALUE]...
 
@@ -1407,7 +1407,7 @@
 
 if test -n "$ac_init_help"; then
   case $ac_init_help in
- short | recursive ) echo "Configuration of libfastjson 0.99.9:";;
+ short | recursive ) echo "Configuration of libfastjson 1.2304.0:";;
esac
   cat <<\_ACEOF
 
@@ -1525,7 +1525,7 @@
 test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
-libfastjson configure 0.99.9
+libfastjson configure 1.2304.0
 generated by GNU Autoconf 2.69
 
 Copyright (C) 2012 Free Software Foundation, Inc.
@@ -1948,7 +1948,7 @@
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
-It was created by libfastjson $as_me 0.99.9, which was
+It was created by libfastjson $as_me 1.2304.0, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   $ $0 $@
@@ -2838,7 +2838,7 @@
 
 # Define the identity of the package.
  PACKAGE='libfastjson'
- VERSION='0.99.9'
+ VERSION='1.2304.0'
 
 
 cat >>confdefs.h <<_ACEOF
@@ -15280,7 +15280,7 @@
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by libfastjson $as_me 0.99.9, which was
+This file was extended by libfastjson $as_me 1.2304.0, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   CONFIG_FILES= $CONFIG_FILES
@@ -15346,7 +153

Re: ktorrent 2.0.3+dfsg1-2 propagation into testing

2006-11-16 Thread Florian Ernst 
On Thu, Nov 16, 2006 at 10:59:00AM -0800, Joel Johnson wrote:
> I'm requesting that ktorrent 2.0.3+dfsg1-2 be considered for propagation to 
> Etch. The initial 2.0.3 release fixed several performance and locking issues, 
> and the -2 corrected a FTBFS in build configs.

2.0.3+dfsg1-2 is still missing a build on one release architecture
(sparc). The first build attempt failed due to uninstallable
dependencies of kdelibs4-dev on auric, but for some reason the package
is still listed as "building"... As I have another package similarily
stuck at spontini I'm wondering whether there is something strange
going on on sparc at the moment...
CC to the sparc builld maintainers added so they can possibly comment
and - hopefully - requeue the package.

> Rationale: The impact of the propagation is extremely low, and the newer 
> version contains some useful improvements for users.

Agreed.

Cheers,
Flo


signature.asc
Description: Digital signature

Bug#1085204: transition: libzip

2024-10-16 Thread Florian Ernst 
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: lib...@packages.debian.org, Ondřej Surý 
Control: affects -1 + src:libzip

Dear Release Team,

please grant a transition slot for the libzip transition.

Upstream has changed the soname from 4 to 5 quite a while ago, but until
now that had been reverted in the Debian packaging, cf.
https://sources.debian.org/src/libzip/1.7.3-1.1/debian/patches/0001-Reintroduce-dummy-zip_archive_set_tempdir-function-t.patch/
https://tracker.debian.org/news/1023453/accepted-libzip-151-2-source-into-experimental/
https://tracker.debian.org/news/1122959/accepted-libzip-161-3-source-into-unstable/

However, the libzip packaging has now been adjusted to reflect this.
For reference, according to upstream the dropped symbol was never fully
implemented or documented, and they are not aware of any software ever
using it. (They had private software where they thought it might be
useful, but then never needed it.)
In Debian, that symbol is only referenced in code copies of libzip, cf.
https://codesearch.debian.net/search?q=zip_archive_set_tempdir&literal=1

libzip itself has successfully built on all release architectures in
experimental, and I have successfully tested a rebuild of all
build-rdeps on amd64 against that version. Well, except for two which
currently FTBFS anyway and are not in testing: mysql-workbench #1074563
and xtrkcad #1074722. (Well, and qgis, but that was due to my build
environment having too limited resources.) So on that side things are
looking safe.

The information on
https://release.debian.org/transitions/html/auto-libzip.html looks correct
to me.

Ben file:

title = "libzip";
is_affected = .depends ~ "libzip4t64" | .depends ~ "libzip5";
is_good = .depends ~ "libzip5";
is_bad = .depends ~ "libzip4t64";

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1085204: transition: libzip

2024-10-24 Thread Florian Ernst 
On Wed, Oct 23, 2024 at 03:18:29PM +0200, Florian Ernst wrote:
> On Wed, Oct 23, 2024 at 01:54:01PM +0200, Emilio Pozuelo Monfort wrote:
> > On 16/10/2024 11:49, Florian Ernst wrote:
> > > [...]
> > > The information on
> > > https://release.debian.org/transitions/html/auto-libzip.html looks correct
> > > to me.
> > 
> > Go ahead.
> 
> Thanks, just uploaded.

FWIW, the package has been autobuilt and uploaded on all architectures
except for hurd-amd64, and its autopkgtest has also succeeded on all
architectures it was executed on.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1085204: transition: libzip

2024-10-23 Thread Florian Ernst 
On Wed, Oct 23, 2024 at 01:54:01PM +0200, Emilio Pozuelo Monfort wrote:
> On 16/10/2024 11:49, Florian Ernst wrote:
> > [...]
> > The information on
> > https://release.debian.org/transitions/html/auto-libzip.html looks correct
> > to me.
> 
> Go ahead.

Thanks, just uploaded.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1087067: bookworm-pu: package srt/1.5.1-1+deb12u1

2024-11-08 Thread Florian Ernst 
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: s...@packages.debian.org
Control: affects -1 + src:srt

Dear Release Team,

I'd like to update the package srt in bookworm after the corresponding
change has found its way into unstable and testing.

[ Reason ]
Bug#1086751: srt's dev packages had too weak dependencies, they only had
a Suggest on libraries in its Requires.private. This goes back to times
way before I took over this package, at the very least back to bullseye.

[ Impact ]
Users might run into compilation errors when they rely just on srt's dev
packages to pull in all required dependencies. However, projects
(including reverse-deps in Debian) generally directly depend on these
dependencies anyways, so the actual impact is presumably small.

[ Tests ]
There are autopkgtest testing both the GnuTLS and the OpenSSL variant
and which still succeeded, both locally and on Salsa, cf.
<https://salsa.debian.org/debian/libsrt/-/jobs/6556259>.

[ Risks ]
The actual packaging change is rather trivial, and the impact (see
above) is presumably small, so I'd assume the risk is pretty low.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
This just cherry-picks the commit fixing the issue in unstable, cf.
<https://salsa.debian.org/debian/libsrt/-/commit/2af4f41e79aab59fc10ff98a54279e61334a62e2>.
A full debdiff is attached: the Suggests on some dev packages are
promoted to Depends and one more Depends is added (and some reformatting
takes place).

[ Other info ]
Yes, I am late for 12.8, but I think there is no need to rush this one.

Cheers,
Flo
diff -Nru srt-1.5.1/debian/changelog srt-1.5.1/debian/changelog
--- srt-1.5.1/debian/changelog  2022-09-28 16:46:38.0 +0200
+++ srt-1.5.1/debian/changelog  2024-11-08 15:09:06.0 +0100
@@ -1,3 +1,10 @@
+srt (1.5.1-1+deb12u1) bookworm; urgency=medium
+
+  * [1e9db13] d/control: correct hard dependencies for dev packages.
+Thanks to Laurent Bigonville  (Closes: #1086751)
+
+ -- Florian Ernst   Fri, 08 Nov 2024 15:09:06 +0100
+
 srt (1.5.1-1) unstable; urgency=medium
 
   * [cd32285] New upstream version 1.5.1
diff -Nru srt-1.5.1/debian/control srt-1.5.1/debian/control
--- srt-1.5.1/debian/control2022-07-02 11:23:38.0 +0200
+++ srt-1.5.1/debian/control2024-11-08 15:06:07.0 +0100
@@ -49,8 +49,10 @@
 Architecture: any
 Multi-Arch: same
 Conflicts: libsrt-gnutls-dev, libsrt-dev
-Depends: libsrt1.5-openssl (= ${binary:Version}), ${misc:Depends}
-Suggests: libsrt-doc (= ${source:Version}), libssl-dev (>= 1.1)
+Depends: libsrt1.5-openssl (= ${binary:Version}),
+ libssl-dev (>= 1.1),
+ ${misc:Depends},
+Suggests: libsrt-doc (= ${source:Version}),
 Description: Secure Reliable Transport UDP streaming library (OpenSSL flavour 
development)
  SRT is a latency-aware UDP transport mechanism optimized for video streams.
  It detects and compensates for jitter and bandwidth fluctuations due to
@@ -66,8 +68,11 @@
 Architecture: any
 Multi-Arch: same
 Conflicts: libsrt-openssl-dev, libsrt-dev
-Depends: libsrt1.5-gnutls (= ${binary:Version}), ${misc:Depends}
-Suggests: libsrt-doc (= ${source:Version}), libgnutls28-dev
+Depends: libgnutls28-dev,
+ libsrt1.5-gnutls (= ${binary:Version}),
+ nettle-dev,
+ ${misc:Depends},
+Suggests: libsrt-doc (= ${source:Version}),
 Description: Secure Reliable Transport UDP streaming library (GnuTLS flavour 
development)
  SRT is a latency-aware UDP transport mechanism optimized for video streams.
  It detects and compensates for jitter and bandwidth fluctuations due to


signature.asc
Description: PGP signature

Bug#1087067: bookworm-pu: package srt/1.5.1-1+deb12u1

2024-11-15 Thread Florian Ernst 
On Fri, Nov 15, 2024 at 04:11:57PM +, Jonathan Wiltshire wrote:
> Please go ahead.

Thanks, just uploaded.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1089984: bookworm-pu: package librabbitmq/0.11.0-1+deb12u1

2024-12-14 Thread Florian Ernst 
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: librabbi...@packages.debian.org
Control: affects -1 + src:librabbitmq

[ Reason ]
https://security-tracker.debian.org/tracker/CVE-2023-35789
Until RabbitMQ 0.13.0 users had no other choice to provide credentials
to certain tools than exposing them on the command line, making them
visible to local attackers by listing a process and its arguments.

[ Impact ]
This update allows users to provide credentials via an authfile. Without
this update users will remain stuck in the previous situation, but with
it they have a *chance* to address the vulnerability with minimal
changes on their side.

[ Tests ]
There are no specific tests which cover the affected code. However, this
patch has been available upstream since June 2023 and released since
2024-03-18 and available in Debian ever since 0.14.0 had been uploaded
2024-07-29. The same patch has also already been released in RHEL9 in
RHSA-2023:6482 from 2023-11-07.


[ Risks ]
The added code is rather trivial and part of upstream (and other
distributions) for quite a while, see above.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037322#45 mentions
some considerations for alternative solutions. But the greater risk lies
with hiding the actual vulnerability by providing a package update for
it, as I will further elaborate on below under "Other info".

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
The upstream patch providing an option to read credentials from an
authfile is added, and I adjusted Maintainer/Uploaders to match the
current situation.

[ Other info ]
This update only addresses the vulnerability insofar as it gives users a
*chance* to fix it with minimal changes on their side. But if users just
apply the update without starting to make use of the authfile, they will
remain in fact vulnerable.
For that reason I have so far refrained from making this update
available in Bookworm, in order to point users to the real problem once
they in turn got pointed to it by the usual suspects of (more or less
dumb) vulnerability reporters, and to avoid having them apply an update
and feeling safe when the actual vulnerability has not been addressed at
all. But a recent enquiry in #1037322 made me rethink the situation, and
I now wish to give users the *chance* to fix the vulnerability in place
without having to resort to the more cumbersome alternatives. If they
are affected at all, that is, and I presume many / most users are not
even affected as they don't use the affected CLI tools, but they just
got scared by automatic vulnerability reports.

Cheers,
Flo
diff -Nru librabbitmq-0.11.0/debian/changelog 
librabbitmq-0.11.0/debian/changelog
--- librabbitmq-0.11.0/debian/changelog 2022-02-21 23:42:45.0 +0100
+++ librabbitmq-0.11.0/debian/changelog 2024-12-15 07:32:03.0 +0100
@@ -1,3 +1,12 @@
+librabbitmq (0.11.0-1+deb12u1) bookworm; urgency=medium
+
+  * [4e71ff7] d/patches/CVE-2023-35789.patch: added for addressing
+CVE-2023-35789 (Closes: #1037322)
+  * [c4d0d0b] d/control: adjust Maintainer/Uploaders to match current
+situation
+
+ -- Florian Ernst   Sun, 15 Dec 2024 07:32:03 +0100
+
 librabbitmq (0.11.0-1) unstable; urgency=low
 
   * New upstream release (Closes: #1004590, #1006244).
diff -Nru librabbitmq-0.11.0/debian/control librabbitmq-0.11.0/debian/control
--- librabbitmq-0.11.0/debian/control   2022-02-21 23:42:45.0 +0100
+++ librabbitmq-0.11.0/debian/control   2024-12-15 07:29:31.0 +0100
@@ -1,9 +1,7 @@
 Source: librabbitmq
 Priority: optional
 Section: libs
-Maintainer: Michael Fladischer 
-Uploaders:
- Brian May ,
+Maintainer: Florian Ernst 
 Build-Depends:
  cmake,
  debhelper-compat (= 13),
diff -Nru librabbitmq-0.11.0/debian/patches/CVE-2023-35789.patch 
librabbitmq-0.11.0/debian/patches/CVE-2023-35789.patch
--- librabbitmq-0.11.0/debian/patches/CVE-2023-35789.patch  1970-01-01 
01:00:00.0 +0100
+++ librabbitmq-0.11.0/debian/patches/CVE-2023-35789.patch  2024-12-15 
07:29:25.0 +0100
@@ -0,0 +1,125 @@
+Applied-Upstream: 463054383fbeef889b409a7f843df5365288e2a0
+Author: Christian Kastner 
+Date: Tue Jun 13 14:21:52 2023 +0200
+Description: Add option to read username/password from file (#781), 
CVE-2023-35789
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037322
+Forwarded: https://github.com/alanxz/rabbitmq-c/issues/575
+Origin: https://github.com/alanxz/rabbitmq-c/pull/781
+
+Index: git/tools/common.c
+===
+--- git.orig/tools/common.c
 git/tools/common.c
+@@ -54,6 +54,11 @@
+ #include "compat.h"
+ #endif
+ 
++/* For when reading auth data from a file */
++#d

Bug#1089984: bookworm-pu: package librabbitmq/0.11.0-1+deb12u1

2025-01-17 Thread Florian Ernst 
On Fri, Jan 17, 2025 at 04:58:37PM +, Jonathan Wiltshire wrote:
> Please go ahead.

Thanks, just uploaded.

Cheers,
Flo


signature.asc
Description: PGP signature