Bug#940964: ITP: honggfuzz -- security oriented fuzzer with powerful analysis options

[Alessandro Ghedini]

Package: wnpp
Severity: wishlist
Owner: Alessandro Ghedini 

* Package name: honggfuzz
  Version : 1.9
  Upstream Author : Robert Swiecki 
* URL : https://github.com/google/honggfuzz
* License : Apache 2.0
  Programming Lang: C
  Description : security oriented fuzzer with powerful analysis options

honggfuzz is a security oriented, feedback-driven, evolutionary, easy-to-use
fuzzer with interesting analysis options.


signature.asc
Description: PGP signature

Bug#931990: ITS: kcov

[Alessandro Ghedini]

Package: kcov
Severity: important

Hello,

The kcov package appears to not be maintained anymore (several RC bugs, very old
upstream version, ...) so I intend to take over its maintainance as per the
package salvaging procedure outlined in the Developer's Reference [0].

Please let me know if you object so I can stop the process.

Cheers

[0] 
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#package-salvaging


-- System Information:
Debian Release: bullseye/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kcov depends on:
ii  libc6   2.28-10
ii  libdw1  0.176-1.1
ii  libelf1 0.176-1.1
ii  libgcc1 1:9.1.0-8
ii  libstdc++6  9.1.0-8

kcov recommends no packages.

kcov suggests no packages.


signature.asc
Description: PGP signature

Bug#926352: curl.1: Some lines begin with a ', causing them to not appear in the output

[Alessandro Ghedini]

Control: forwarded -1 https://github.com/curl/curl/pull/4111
Control: tags -1 pending

On Wed, Apr 03, 2019 at 09:48:15PM +, Bjarni Ingi Gislason wrote:
> Package: curl
> Version: 7.64.0-2
> Severity: normal
> Tags: patch
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
> Warnings from "nroff -ww ...", used in "man curl 2> ..." with
> MANOPT=--warnings=w
> MAN_KEEP_STDERR=yes
> 
> troff: :531: warning: macro 'foobar'' not defined
> troff: :1147: warning: macro '~/.ssh/id_rsa',' not defined
> troff: :1618: warning: macro 'all',' not defined
> 
> 
>   The patch:

Thanks for the patch. I imported it into the next version of the curl package
and also took the liberty of forwarding it upstream (maintaining credit to you
of course): https://github.com/curl/curl/pull/4111

Cheers


signature.asc
Description: PGP signature

Bug#927471: curl: Regression that fails to exhaust socket data

[Alessandro Ghedini]

On Sat, Apr 20, 2019 at 01:39:36PM +0200, Guillem Jover wrote:
> Source: curl
> Source-Version: 7.64.0-2
> Severity: serious
> Control: affects -1 rtorrent
> 
> Hi!

Hello,

> I've started noticing rtorrent busy-looping at some points after
> finishing a torrent. stracing and gdb'ing the process it was doing
> that in its main loop, spamming on gettimeofday() and epoll_wait().
> 
> Checking the rtorrent dependencies I've not seen much suspicious
> updated recently, except for curl. I checked then the upstream bug
> trackers and noticed quite many instances of "100% cpu usage" reports,
> such as . And that
> one points to old and new curl issue. The last instance of it appears
> to have been fixed with 
> in 7.64.1.
> 
> So I think curl should be either upgraded to that release, or the
> relevant commits cherry-picked.

I prepared an update for the curl package with the two upstream patches applied
(38d8e1b and 4015fae), and uploaded the result for amd64 at:
https://people.debian.org/~ghedo/libcurl4_7.64.0-3_amd64.deb

Guillem, could you try this version of the package and see if it fixes the
issue for you? Once that's confirmed I'll upload to sid and ask for unblock.

Cheers


signature.asc
Description: PGP signature

Bug#926132: unblock: curl/7.64.0-2

[Alessandro Ghedini]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package curl

The version in sid fixes #922554, which affects several users of NetworkManager.
and is marked as important (the patch is backported from upstream).

Debdiff is attached.

At the time I uploaded it I expected it to migrate to testing before the freeze,
but apparently I did the math wrong. Anyway an unrelated change adding a couple
of entries to the previous upload'ss changelog was also included (as you can see
from the debdiff), hope that's not too much of a problem.

unblock curl/7.64.0-2

-- System Information:
Debian Release: buster/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru curl-7.64.0/debian/changelog curl-7.64.0/debian/changelog
--- curl-7.64.0/debian/changelog	2019-02-06 22:33:05.0 +
+++ curl-7.64.0/debian/changelog	2019-03-07 20:02:35.0 +
@@ -1,3 +1,9 @@
+curl (7.64.0-2) unstable; urgency=medium
+
+  * Fix infinite loop when fetching URLs with unreachable IPv6 (Closes: #922554)
+
+ -- Alessandro Ghedini   Thu, 07 Mar 2019 20:02:35 +
+
 curl (7.64.0-1) unstable; urgency=medium
 
   * New upstream release
@@ -8,6 +14,8 @@
 + Fix SMTP end-of-response out-of-bounds read as per CVE-2019-3823
   https://curl.haxx.se/docs/CVE-2019-3823.html
 + Fix HTTP negotiation with POST requests (Closes: #920267)
+  * Refresh patches
+  * Import fixes for zsh completion script generator (Closes: #92145)
 
  -- Alessandro Ghedini   Wed, 06 Feb 2019 22:33:05 +
 
diff -Nru curl-7.64.0/debian/patches/13_singlesocket-fix-the-sincebefore-placement.patch curl-7.64.0/debian/patches/13_singlesocket-fix-the-sincebefore-placement.patch
--- curl-7.64.0/debian/patches/13_singlesocket-fix-the-sincebefore-placement.patch	1970-01-01 01:00:00.0 +0100
+++ curl-7.64.0/debian/patches/13_singlesocket-fix-the-sincebefore-placement.patch	2019-03-07 20:02:35.0 +
@@ -0,0 +1,38 @@
+From afc00e047c773faeaa60a5f86a246cbbeeba5819 Mon Sep 17 00:00:00 2001
+From: Daniel Stenberg 
+Date: Tue, 19 Feb 2019 15:56:54 +0100
+Subject: [PATCH] singlesocket: fix the 'sincebefore' placement
+
+The variable wasn't properly reset within the loop and thus could remain
+set for sockets that hadn't been set before and miss notifying the app.
+
+This is a follow-up to 4c35574 (shipped in curl 7.64.0)
+
+Reported-by: buzo-ffm on github
+Detected-by: Jan Alexander Steffens
+Fixes #3585
+Closes #3589
+---
+ lib/multi.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/lib/multi.c
 b/lib/multi.c
+@@ -2360,8 +2360,6 @@
+   int num;
+   unsigned int curraction;
+   int actions[MAX_SOCKSPEREASYHANDLE];
+-  unsigned int comboaction;
+-  bool sincebefore = FALSE;
+ 
+   for(i = 0; i< MAX_SOCKSPEREASYHANDLE; i++)
+ socks[i] = CURL_SOCKET_BAD;
+@@ -2380,6 +2378,8 @@
+   i++) {
+ unsigned int action = CURL_POLL_NONE;
+ unsigned int prevaction = 0;
++unsigned int comboaction;
++bool sincebefore = FALSE;
+ 
+ s = socks[i];
+ 
diff -Nru curl-7.64.0/debian/patches/series curl-7.64.0/debian/patches/series
--- curl-7.64.0/debian/patches/series	2019-02-06 22:33:05.0 +
+++ curl-7.64.0/debian/patches/series	2019-03-07 20:02:35.0 +
@@ -4,6 +4,7 @@
 08_enable-zsh.patch
 11_omit-directories-from-config.patch
 12_zsh.patch
+13_singlesocket-fix-the-sincebefore-placement.patch
 
 # do not add patches below
 90_gnutls.patch


signature.asc
Description: PGP signature

Bug#921452: curl: zsh completion for curl -E is borken

[Alessandro Ghedini]

forwarded -1 https://github.com/curl/curl/pull/3528
kthxbye

On Tue, Feb 05, 2019 at 01:58:50PM -0400, David Bremner wrote:
> Package: curl
> Version: 7.63.0-1
> Severity: normal
> 
> Seen on #zsh / arch, verified also present in Debian; presumably an upstream 
> bug.
> 
> ╭─ rocinante:~ 
> ╰─% curl -E 
> (eval):1: parse error near `>'
> _arguments:463: command not found: p

Yeah, the script that generates the completion has a bug. Submitted a PR to
fix it.

Cheers


signature.asc
Description: PGP signature

Bug#864440: xclip: Please package new upstream version 0.13

[Alessandro Ghedini]

On Sun, Dec 09, 2018 at 04:28:00PM -0500, Boyuan Yang wrote:
> X-Debbugs-CC: gh...@debian.org
> 
> Hi Alessandro,

Hello,

> On Thu, 08 Jun 2017 18:38:55 +0200 "W. Martin Borgert" <
> deba...@debian.org> wrote:
> > Package: xclip
> > Version: 0.12+svn84-4
> > Severity: wishlist
> > 
> > Upstream moved to github and published a new version:
> > https://github.com/astrand/xclip/releases/tag/0.13
> > "This release features several new features and bugfixes
> > done over the last 6 years. See ChangeLog for details."
> > I looks like the only Debian patch can be dropped then.
> 
> The new upstream release seems to be around for quite a few years. I'm
> wondering if you could make another upload before Buster release with
> new upstream version or make another upload without new upstream
> release to deal with existing bugs since xclip hasn't seen any upload
> for 4 years. Please let me know if NMU is okay to fix some obvious
> problems (Vcs-*, Homepage, etc).

If you are interested in maintaining xclip you are very welcome to join as
co-maintainer (or even only maintainer as I don't a whole lot of time to
dedicate to it).

The git repo is on salsa https://salsa.debian.org/debian/xclip so you are
welcome to do changes there.

CHeers


signature.asc
Description: PGP signature

Bug#914927: curl: Please recompile with new libssl-dev headers (1.1.1+).

[Alessandro Ghedini]

On Wed, Nov 28, 2018 at 07:19:25PM +, Witold Baryluk wrote:
> Package: curl
> Version: 1.1.1a-1
> Severity: important
> 
> 
> Hi,
> 
> I discovered that during test with curl, that curl in Debian doesn't support 
> TLSv1.3.

It works for me:

 % curl --tlsv1.3 -vso /dev/null https://www.cloudflare.com/ 
[...]
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
[...]

curl has already been migrated to OpenSSL 1.1 in Buster as part of #858398.

Cheers


signature.asc
Description: PGP signature

Bug#820775: libcurl3: Compile libcurl3 with c-ares support

[Alessandro Ghedini]

On Thu, Nov 01, 2018 at 08:01:24PM +, Luca Boccassi wrote:
> Control: tags -1 patch
> 
> On Tue, 12 Apr 2016 17:11:45 +1200 Jeremy Kuek  com> wrote:
> > Package: libcurl3
> > Version: 7.38.0-4+deb8u3
> > Severity: wishlist
> > 
> > Dear Maintainer,
> > 
> > My system has 2 network interfaces, one of which is connected to the
> internet, and the other is connected to an internal network.
> > 
> > My application is using libcurl to send HTTP and HTTPS requests to
> various servers.
> > 
> > I wish to be able to use hostnames on both interfaces, and the
> respective DNS servers to resolve those names. The curl documentation
> provides the options CURLOPT_DNS_INTERFACE, CURLOPT_DNS_SERVERS for
> just this purpose.
> > 
> > However, those options require libcurl to be compiled with the c-ares 
> backend.
> > 
> > Refer to:
> > https://curl.haxx.se/libcurl/c/CURLOPT_DNS_INTERFACE.html
> > https://curl.haxx.se/dev/readme-ares.html
> > 
> > 
> > Currently I am having to use IP addresses for the internal network. 
> > It seems like the only short term solution to use hostnames for both
> networks is to use a custom-compiled libcurl.
> > 
> > In the future, can the official libcurl package be compiled with c-
> ares support?
> 
> Dear maintainer,
> 
> I have opened a PR on Salsa for this:
> 
> https://salsa.debian.org/debian/curl/merge_requests/5

This is not really feasible at this point, because last time I checked c-ares
doesn't support glibc's NSS module system, which means this is likely to break
people's systems when NSS modules are used.

A long time ago there was also a problem related to IPv6 [0] which caused c-ares
to be disabled in curl (see #605558). Don't know if that's fixed now (but in
any case the NSS problem is a blocker on its own IMO).

Cheers

[0] https://curl.haxx.se/mail/lib-2009-08/0014.html


signature.asc
Description: PGP signature

Bug#909274: jansson: Please consider building jansson with -fPIC

[Alessandro Ghedini]

On Thu, Sep 20, 2018 at 09:09:39PM +0200, Jean Baptiste Favre wrote:
> Source: jansson
> Severity: wishlist
> 
> Dear Maintainer,
> 
> Next release of trafficserver provides a plugin depending on jansson.
> Currently, jansson seems to be built staticaly:
> 
> checking jansson.h usability... yes
> checking jansson.h presence... yes
> checking for jansson.h... yes
> checking whether jansson is dynamic... no
> 
> It also doen't use -fPIC, which prevent its use with trafficserver:
> 
> libtool: link:  cc -shared  -fPIC -DPIC
> experimental/uri_signing/.libs/uri_signing.o
> experimental/uri_signing/.libs/config.o
> experimental/uri_signing/.libs/cookie.o
> experimental/uri_signing/.libs/jwt.o
> experimental/uri_signing/.libs/match.o
> experimental/uri_signing/.libs/parse.o
> experimental/uri_signing/.libs/timing.o   -l:libjansson.a -l:libcjose.a
> -lpcre -lm -lcrypto -lbrotlienc -lpthread -ldl  -g -mcx16 -g -O2
> -fstack-protector-strong -O3 -Wl,-z -Wl,relro -Wl,-z -Wl,now
> -Wl,-soname -Wl,uri_signing.so -Wl,-version-script
> -Wl,experimental/uri_signing/.libs/uri_signing.ver -o
> experimental/uri_signing/.libs/uri_signing.so
> /usr/bin/ld:
> /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/libjansson.a(load.o):
> relocation R_X86_64_PC32 against symbol `stdin@@GLIBC_2.2.5' can not be
> used when making a shared object; recompile with -fPIC
> 
> Could you please consider adding this flag ?

AFAICT jansson is already built with -fPIC, see build logs:
https://buildd.debian.org/status/fetch.php?pkg=jansson&arch=amd64&ver=2.11-1&stamp=1518387251&raw=0
https://buildd.debian.org/status/fetch.php?pkg=jansson&arch=i386&ver=2.11-1&stamp=1518387065&raw=0

Cheers


signature.asc
Description: PGP signature

Bug#907830: O: hsetroot -- tool for composing root-pixmaps for X11

[Alessandro Ghedini]

Package: wnpp
Severity: normal

I intend to orphan the hsetroot package since I don't use thi myself anymore.

You can find the sources on salsa:
https://salsa.debian.org/debian/hsetroot

The package description is:
 hsetroot is a tool which allows you to compose wallpapers ("root pixmaps")
 for X. It has a lot of options like rendering gradients, solids, images but
 it also allows you to perform manipulations on those things, or chain them
 together.


signature.asc
Description: PGP signature

Bug#903389: valgrind can't read debug info from binaries built with -z separate-code

[Alessandro Ghedini]

On Wed, Jul 18, 2018 at 05:47:58PM +0200, Ansgar Burchardt wrote:
> Hi,
> 
> I can confirm that the patch referenced at [1] seems to fix the problem
> (upstream commit 64aa729bfae71561505a40c12755bd6b55bb3061).
> 
> I'll try to prepare a NMU for valgrind; maybe already this evening if I
> have time. The package isn't usable in the current state.

I'm currently travelling, so I won't be able to look at this until end of week.
NMU would be appreciated, thanks. Feel free to push to the salsa repo [0].

Cheers

[0] https://salsa.debian.org/debian/valgrind


signature.asc
Description: PGP signature

Bug#902644: upower: Upower breaks power saving settings after upgrade to 0.99.8-1

[Alessandro Ghedini]

On Thu, Jun 28, 2018 at 09:55:01PM -0300, Adilson dos Santos Dantas wrote:
> Package: upower
> Version: 0.99.8-1
> Severity: important
> 
> Dear Maintainer,
> 
> After upgrading upower to 0.99.8-1, my KDE power saving settings stops 
> working.
> There is no reaction when I unplug and plug back my notebook AC power.
> Only the battery charge status changes after a few minutes.
> 
> The only workaround found, for this problem, is a downgrade back to 0.99.7-2.

Same here. I noticed that after the upgrade, upower doesn't send the
PropertiesChanged D-Bus signal anymore, which I'm guessing is what most clients
use to detect changes in the upower status.

You can verify this by running "sudo busctl monitor org.freedesktop.UPower"
and unplugging/plugging the power cable: before the upgrade I see the signal,
but after the upgrade I don't see it anymore.

Looking at the changes in 0.99.8, [1] looks like it might be the source of the
problem.

Cheers

[1] 
https://gitlab.freedesktop.org/upower/upower/commit/41bce284476030b22cd6d60280fb875f507f47a2


signature.asc
Description: PGP signature

Bug#891872: transition: curl

[Alessandro Ghedini]

On Mon, May 28, 2018 at 01:09:14PM +0200, Emilio Pozuelo Monfort wrote:
> Control: tags -1 - confirmed
> 
> On 23/05/18 13:07, Emilio Pozuelo Monfort wrote:
> > On 23/04/18 20:38, Emilio Pozuelo Monfort wrote:
> >> On 01/03/18 22:31, Alessandro Ghedini wrote:
> >>> Package: release.debian.org
> >>> Severity: normal
> >>> User: release.debian@packages.debian.org
> >>> Usertags: transition
> >>>
> >>> Hello,
> >>>
> >>> I'd like to request a transition for curl in order to unblock the 
> >>> migration
> >>> to OpenSSL 1.1 (#871056). This is necessary due to the fact that the curl 
> >>> ABI
> >>> exposes a structure inherited from libssl itself, which was changed in 
> >>> the 1.1
> >>> update (see #844018 for more information).
> >>
> >> I was looking at this in order to ack it. However I've noticed that 
> >> libcurl4
> >> conflicts against libcurl3. Why is that? That's going to make the 
> >> transition
> >> hard, can it be removed?
> >>
> >> Hmm, I just realised libcurl3 ships libcurl.so.4, so that explains the 
> >> conflict.
> >> I just found the rationale for this in
> >> https://salsa.debian.org/debian/curl/merge_requests/2. That means this 
> >> will have
> >> to wait until there are no conflicting ongoing transitions. I will ack 
> >> this when
> >> that time comes.
> > 
> > Please go ahead now.
> > 
> > Since all packages need to migrate at the same time, some NMUs may be 
> > needed to
> > fix potential FTBFS in rdeps. I will notify this bug when the binNMUs are 
> > done
> > and we have a list of failing packages.
> 
> I've acked the R transition, so let's wait for that now.

Ugh, sorry for the big delay. curl 7.60.0-2 just got accepted (it was stuck in
NEW due to the fact I had to upload a new version to sid last week to fix
security issues so the experimental upload got removed, and I didn't make it in
time to clear 7.60.0 with the migration changes through experimental).

This is totally my fault, I should have notified you about that when I did the
upload. I hope this doesn;t cause you too much of a pain. Is there anything I
can do to fix this?

Cheers


signature.asc
Description: PGP signature

Bug#891872: transition: curl

[Alessandro Ghedini]

On Thu, Mar 01, 2018 at 09:31:20PM +, Alessandro Ghedini wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hello,
> 
> I'd like to request a transition for curl in order to unblock the migration
> to OpenSSL 1.1 (#871056). This is necessary due to the fact that the curl ABI
> exposes a structure inherited from libssl itself, which was changed in the 1.1
> update (see #844018 for more information).
> 
> It is for the most part a clean ABI bump, however a few packages that build
> depend on both libcurl and libssl will need source uploads so they can also
> migrate to OpenSSL 1.1. The following packages were identified as part of the
> discussion in #858398:
> 
> * hhvm: #858927 (sid-only)
> * lastpass-cli: #858991 
> * libapache2-mod-auth-cas: 858992
> * netsurf: #859230
> * xmltooling: #859831
> * zurl: #859841

To be clear, these are the packages that are affected by the ABI change, they
don't just build depend on both libcurl and libssl.

Cheers


signature.asc
Description: PGP signature

Bug#858398: Proposed (lib)curl switch to openssl 1.1

[Alessandro Ghedini]

On Sat, Feb 24, 2018 at 12:50:41PM +, Alessandro Ghedini wrote:
> On Wed, Feb 21, 2018 at 11:14:24AM -0800, Steve Langasek wrote:
> > Hi again,
> > 
> > On Tue, Feb 20, 2018 at 06:16:34PM -0800, Steve Langasek wrote:
> > > So, despite Julien's valid objection that core library conflicts cause
> > > dist-upgrades to be more brittle, I think the right answer here is:
> > 
> > > - keep all sonames as-is.
> > > - rename libcurl3 to libcurl4.
> > > - leave the package names of the other variants as-is.
> > > - *if* libcurl-gnutls.so.4 and libcurl-nss.so.4 sonames are known to exist
> > >   elsewhere outside the Debian ecosystem, fix the symbol versions for
> > >   libcurl3-gnutls and libcurl3-nss to use symbol aliases, so that 
> > > CURL_FOO_4
> > >   is used as the preferred name and CURL_FOO_3 is for compatibility only.
> > >   (This is only worth doing if this increases binary compatibility;
> > >   otherwise it's better to maintain bidirectional binary compatibility for
> > >   Debian-built binaries.)
> > > - change the symbol versions for libcurl4 to CURL_OPENSSL_4.
> > 
> > > I would be willing to prepare a patch that implements this.
> > 
> > I've done this now and raised an MP:
> > 
> >   https://salsa.debian.org/debian/curl/merge_requests/3
> > 
> > (I'm assuming there is no point in CURL_FOO_4 symbol version for
> > libcurl-gnutls and libcurl-nss, because these sonames come from a
> > Debian-specific patch and therefore there's no upstream binary compatibility
> > to be concerned about.)
> > 
> > Thoughts on this?
> > 
> > In terms of ABI changes, this appears to be a strict subset of what
> > Alessandro had proposed and would be binary-compatible for libcurl.so.4; so
> > at minimum, we will probably adopt this change in Ubuntu and proceed with
> > the transition ASAP there, even if Debian later decides to change the ABI
> > for gnutls and nss variants also.
> 
> I'm fine with going ahead with just the libcurl3 -> libcurl4 transition for
> now.
> 
> Julien: is this something that the Release Team would be ok with? As Steve
> pinted out before, libcurl3 has significantly lower usage than lubcurl3-gnutls
> so impact should be somewhat more limited.
> 
> I'd like to go ahead and upload Steve's patch to experimental (which means NEW
> queue) soon, and then request the transition.

Quick update, with a slight delay I went ahead and uploaded Steve's changes to
experimental as curl 7.58.0-3, which got accepted in record time, so I also
requested the transition https://bugs.debian.org/891872

Thanks a lot to everyone involved for the help with this.

Cheers


signature.asc
Description: PGP signature

Bug#891872: transition: curl

[Alessandro Ghedini]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hello,

I'd like to request a transition for curl in order to unblock the migration
to OpenSSL 1.1 (#871056). This is necessary due to the fact that the curl ABI
exposes a structure inherited from libssl itself, which was changed in the 1.1
update (see #844018 for more information).

It is for the most part a clean ABI bump, however a few packages that build
depend on both libcurl and libssl will need source uploads so they can also
migrate to OpenSSL 1.1. The following packages were identified as part of the
discussion in #858398:

* hhvm: #858927 (sid-only)
* lastpass-cli: #858991 
* libapache2-mod-auth-cas: 858992
* netsurf: #859230
* xmltooling: #859831
* zurl: #859841

The updated curl package (7.58.0-3) has been uploaded and accepted in
experimental. The full changeset (from Steve Langasek) can be found at:
https://salsa.debian.org/debian/curl/merge_requests/3/diffs

The auto-generated tracker (which looks correct) is:
https://release.debian.org/transitions/html/auto-curl.html

Let me know if you need more information.

Thanks

-- System Information:
Debian Release: buster/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.15.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


signature.asc
Description: PGP signature

Bug#797359: Reassign

[Alessandro Ghedini]

Control: owner -1 !

Since there hasn't been an update in over a year, I'm going to reassign this
ticket to myself. I already uploaded the initial version to NEW. For those
interested, here is the salsa repo:

  https://salsa.debian.org/debian/universal-ctags

Btw, I'm open to co-maintaining this with others if anyone wants to volunteer.

Cheers


signature.asc
Description: PGP signature

Bug#858398: Proposed (lib)curl switch to openssl 1.1

[Alessandro Ghedini]

On Wed, Feb 21, 2018 at 11:14:24AM -0800, Steve Langasek wrote:
> Hi again,
> 
> On Tue, Feb 20, 2018 at 06:16:34PM -0800, Steve Langasek wrote:
> > So, despite Julien's valid objection that core library conflicts cause
> > dist-upgrades to be more brittle, I think the right answer here is:
> 
> > - keep all sonames as-is.
> > - rename libcurl3 to libcurl4.
> > - leave the package names of the other variants as-is.
> > - *if* libcurl-gnutls.so.4 and libcurl-nss.so.4 sonames are known to exist
> >   elsewhere outside the Debian ecosystem, fix the symbol versions for
> >   libcurl3-gnutls and libcurl3-nss to use symbol aliases, so that CURL_FOO_4
> >   is used as the preferred name and CURL_FOO_3 is for compatibility only.
> >   (This is only worth doing if this increases binary compatibility;
> >   otherwise it's better to maintain bidirectional binary compatibility for
> >   Debian-built binaries.)
> > - change the symbol versions for libcurl4 to CURL_OPENSSL_4.
> 
> > I would be willing to prepare a patch that implements this.
> 
> I've done this now and raised an MP:
> 
>   https://salsa.debian.org/debian/curl/merge_requests/3
> 
> (I'm assuming there is no point in CURL_FOO_4 symbol version for
> libcurl-gnutls and libcurl-nss, because these sonames come from a
> Debian-specific patch and therefore there's no upstream binary compatibility
> to be concerned about.)
> 
> Thoughts on this?
> 
> In terms of ABI changes, this appears to be a strict subset of what
> Alessandro had proposed and would be binary-compatible for libcurl.so.4; so
> at minimum, we will probably adopt this change in Ubuntu and proceed with
> the transition ASAP there, even if Debian later decides to change the ABI
> for gnutls and nss variants also.

I'm fine with going ahead with just the libcurl3 -> libcurl4 transition for
now.

Julien: is this something that the Release Team would be ok with? As Steve
pinted out before, libcurl3 has significantly lower usage than lubcurl3-gnutls
so impact should be somewhat more limited.

I'd like to go ahead and upload Steve's patch to experimental (which means NEW
queue) soon, and then request the transition.

Cheers


signature.asc
Description: PGP signature

Bug#890196: O: xcompmgr -- X composition manager

[Alessandro Ghedini]

Package: wnpp
Severity: normal

I intend to orphan the xcompmgr package since I do not use it anymore.

The package description is:
 xcompmgr is the standard composition manager for the X Composite extension,
 which allows clients to modify what is drawn to the screen before it
 happens.  This composition manager implements shadows, fading, proper
 translucency, and more.


signature.asc
Description: PGP signature

Bug#858398: curl: Please migrate to openssl1.1 in Buster

[Alessandro Ghedini]

On Sun, Dec 17, 2017 at 11:16:29PM +0200, Adrian Bunk wrote:
> On Fri, Dec 08, 2017 at 05:44:55PM +0100, Ondřej Surý wrote:
> > Hi,
> > 
> > just innocent bystander here with an observation:
> > 
> > These two options:
> > 
> > a)
> > > I do agree it's the correct solution though, and it would be a good 
> > > opportunity
> > > to finally sync SONAME with upstream
> > 
> > b)
> > > Because of 1 I think we should change the package name (and SONAME) for
> > > libcurl3.  I don't think 2 is appropriate.
> > 
> > are mutually exclusive, so even if we rename the share library packages
> > to libcurl4*, they would have to conflict with libcurl3* because they
> > would contain same files.
> > 
> > And the SONAME is already libcurl.so.4 (at least on stretch):
> > 
> > $ objdump -p /usr/lib/x86_64-linux-gnu/libcurl* | grep SONAME
> >   SONAME   libcurl-gnutls.so.4
> >   SONAME   libcurl-gnutls.so.4
> >   SONAME   libcurl-gnutls.so.4
> >   SONAME   libcurl.so.4
> >   SONAME   libcurl.so.4
> >   SONAME   libcurl.so.4
> > 
> > So in this case, unfortunately, bumping the SONAME is actually something
> > different than changing package name to match to SONAME of the library. 
> >...
> 
> Similar to all the v5 postfixed packages in Debian for C++ ABI changes 
> in GCC 5, what matter here is actually not the SONAME but the package
> name and that the new package conflicts with the old package.
> 
> This is sufficient to fix the issue for all packages using curl.
> 
> And different from breaks on specific packages, it will also force an
> upgrade of packages from backports.
> 
> Non-packaged software is a different topic, but the whole OpenSSL 
> situation in stretch is already a mess for that.
> 
> This whole transition looks pretty straightforward to me,
> please let me know if there is anything where I could help.

Following Adrian's comment, I prepated a patch that:

 * Renames *all* lincurl3* packages to libcurl4* (with Conflicts+Replaces)
 * Removes the hacks for old SONAME and updates symbols (as Ondrej correctly
   pointed out, the SONAME doesn't actually change as ww already ship a
   "libcurl.so.4", but the lib symlinks and the symbols do)
 * Makes the OpenSSL libcurl build against OpenSSL 1.1

I think this satisfies all the requirements for the OpenSSL migration, as well
as finally cleaning up the mess from the last botched transition as an added
bonus.

Thoughts?

The patch is at https://salsa.debian.org/debian/curl/merge_requests/2

Cheers


signature.asc
Description: PGP signature

Bug#858398: Proposed (lib)curl switch to openssl 1.1

[Alessandro Ghedini]

On Sat, Dec 02, 2017 at 06:09:39PM +0100, Julien Cristau wrote:
> On Thu, Nov 23, 2017 at 15:49:26 +, Ian Jackson wrote:
> > Reasons I am aware that it *might* be a bad idea are:
> > 
> > 1. libcurl exposes parts of the openssl ABI, via
> >CURLOPT_SSL_CTX_FUNCTION, and this would be an implicit ABI break
> >without libcurl soname change.  This is not good, but it seems like
> >the alternative would be to diverge our soname from everyone else's
> >for the same libcurl.
> > 
> > 2. For the reason just mentioned, it might be a good idea to put in a
> >Breaks against old versions of packages using
> >CURLOPT_SSL_CTX_FUNCTION.  However, (a) I am not sure if this is
> >actually necessary (b) in any case I don't have a good list of all
> >the appropriate versions (c) maybe this would need coordination.
> > 
> > 3. This might be an implicit a "transition" (in the Debian release
> >management sense) which I would be mishandling, or starting without
> >permission, or something.
> > 
> Because of 1 I think we should change the package name (and SONAME) for
> libcurl3.  I don't think 2 is appropriate.

Following discussion on the ticket (#858398) it was suggested to follow the
strategy used for the GCC 5 C++ ABI transition, that is, rename the libcurl
package and add Conflicts+Replaces for teh old package.

Due to the fact that the previous transition (libcurl3 -> libcurl4) was
partially reverted (in 2007 according to the changelog), I'd also like to
taeke this opportunity to finally complete that as well, so I made a patch
to not only rename libcurl3 -> libcurl4, but also (libcurl3-gnutls,
libcurl3-nss) -> (libcurl4-gnutls, libcurl4-nss), and remove the hacks needed
to keep compatibility with the previous ABI.

Thoughts?

The patch is at https://salsa.debian.org/debian/curl/merge_requests/2

CHeers


signature.asc
Description: PGP signature

Bug#858398: Proposed (lib)curl switch to openssl 1.1

[Alessandro Ghedini]

On Thu, Nov 23, 2017 at 07:10:51PM +, Ian Jackson wrote:
> Adrian Bunk writes ("Re: Proposed (lib)curl switch to openssl 1.1"):
> > What I suggest above would be a transition that should be coordinated
> > with the release team like other transitions.
> 
> I'm not 100% opposed to doing this as a normal library transition with
> a soname change.  I don't feel I understand the tradeoffs well.

Well, one downside is that doing a full blown transition is likely to take
more work and time to see it completed. Unfortunately I don't have the time
required and can't commit to doing this myself.

I do agree it's the correct solution though, and it would be a good opportunity
to finally sync SONAME with upstream (last time a transition of libcurl was
attempted some 10 years or so ago, it was halted for reasons now lost in the
mists of time, so we have been stuck carrying some hacks to pretend we are
still using the old SONAME, see e.g. [0] [1]).

Cheers

[0] 
https://anonscm.debian.org/cgit/collab-maint/curl.git/tree/debian/patches/03_keep_symbols_compat.patch
[1] 
https://anonscm.debian.org/cgit/collab-maint/curl.git/tree/debian/libcurl3.links


signature.asc
Description: PGP signature

Bug#876256: RFA: imlib2 -- image loading, rendering, saving library

[Alessandro Ghedini]

Package: wnpp
Severity: normal

I don't quite have the time or interest to continue maintaining this, so I
request an adopter for the imlib2 package.

The package description is:
 Imlib2 is a library that does image file loading and saving as well as
 rendering, manipulation, arbitrary polygon support, etc.
 .
 It does ALL of these operations FAST. Imlib2 also tries to be highly
 intelligent about doing them, so writing naive programs can be done easily,
 without sacrificing speed.

Cheers


signature.asc
Description: PGP signature

Bug#876254: ITP: pulsemixer -- command-line mixer for PulseAudio with a curses interface

[Alessandro Ghedini]

Package: wnpp
Severity: wishlist
Owner: Alessandro Ghedini 

* Package name: pulsemixer
  Version : 1.3.0
  Upstream Author : George Filipkin 
* URL : https://github.com/GeorgeFilipkin/pulsemixer
* License : MIT
  Programming Lang: Python
  Description : command-line mixer for PulseAudio with a curses interface

pulsemixer is a command-line volume mixer for PulseAudio that provides a
customizable curses-based interactive user interface.


signature.asc
Description: PGP signature

Bug#874784: curl: undeclared build depencdency on dh-exec

[Alessandro Ghedini]

On Sat, Sep 09, 2017 at 04:11:59PM +0100, Wookey wrote:
> Package: curl
> Version: 7.52.1-5
> Severity: normal
> Tags: patch
> 
> curl needs dh-exec to build, because curl.install is
> #!/usr/bin/dh-exec
> usr/bin/curl
>  usr/share/zsh/*

Don't know where this comes from, but that's not the content of the file:
https://anonscm.debian.org/cgit/collab-maint/curl.git/tree/debian/curl.install

Cheers


signature.asc
Description: PGP signature

Bug#872502: curl FTBFS for hppa: error: unknown type name 'curl_off_t'

[Alessandro Ghedini]

On Sun, Aug 20, 2017 at 11:01:28AM -0400, John David Anglin wrote:
> Package: curl
> Version: 7.52.1-5
> Followup-For: Bug #872502
> 
> Dear Maintainer,
> 
> See buildd log here:
> https://buildd.debian.org/status/fetch.php?pkg=curl&arch=hppa&ver=7.55.0-1&stamp=1503192493&raw=0
> 
> "|| defined(__hppa__)" needs to be added to the same list as powerpc.

Please don't hijack bug reports. This is about powerpc, which, AFAICT has been
fixed upstream. If there's a problem with hppa please create a new report.

Anyway, it seems the hppa build is actually successful now:
https://buildd.debian.org/status/fetch.php?pkg=curl&arch=hppa&ver=7.55.0-1&stamp=1503251821&raw=0

Which is the one listed from:
https://buildd.debian.org/status/package.php?p=curl&suite=unstable

Is there still a problem for hppa?

Cheers


signature.asc
Description: PGP signature

Bug#856641: curl: X.509 certificates using md5RSA signatures should be rejected

[Alessandro Ghedini]

On Sun, Mar 12, 2017 at 02:11:48PM +, Alessandro Ghedini wrote:
> On Fri, Mar 03, 2017 at 09:41:03AM +0100, lcf wrote:
> > Package: curl
> > Version: 7.52.1-3
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > When establishing https connection X.509 certificates using md5RSA should be
> > rejected and connection should be terminated.
> > 
> > curl 7.52.1 can do that, when it's compiled against OpenSSL 1.1.0 and above.
> > Attempts to establish connection with hosts using md5RSA certificate result 
> > in
> > curl: (60) SSL certificate problem: CA signature digest algorithm too weak
> > error in that case.
> > 
> > OpenSSL 1.1.0 is already included in Debian Stretch, so curl should be 
> > compiled
> > against new OpenSSL to solve this security issue.
> 
> The switch to OpenSSL 1.1 was rolled back due to [0], as per release team
> decision (see [1]).

Ugh, [1] was meant to point to https://bugs.debian.org/850880


signature.asc
Description: PGP signature

Bug#856641: curl: X.509 certificates using md5RSA signatures should be rejected

[Alessandro Ghedini]

On Fri, Mar 03, 2017 at 09:41:03AM +0100, lcf wrote:
> Package: curl
> Version: 7.52.1-3
> Severity: important
> 
> Dear Maintainer,
> 
> When establishing https connection X.509 certificates using md5RSA should be
> rejected and connection should be terminated.
> 
> curl 7.52.1 can do that, when it's compiled against OpenSSL 1.1.0 and above.
> Attempts to establish connection with hosts using md5RSA certificate result in
> curl: (60) SSL certificate problem: CA signature digest algorithm too weak
> error in that case.
> 
> OpenSSL 1.1.0 is already included in Debian Stretch, so curl should be 
> compiled
> against new OpenSSL to solve this security issue.

The switch to OpenSSL 1.1 was rolled back due to [0], as per release team
decision (see [1]).

Cheers

[0] https://bugs.debian.org/844018


signature.asc
Description: PGP signature

Bug#845278: closed by Arturo Borrero Gonzalez (Bug#845278: fixed in iptables 1.6.0+snapshot20161117-3)

[Alessandro Ghedini]

On Tue, Nov 22, 2016 at 09:06:05AM +, Debian Bug Tracking System wrote:
>  iptables (1.6.0+snapshot20161117-3) unstable; urgency=medium
>  .
>* [21fdc57] libxtables12: breaks and replaces libxtables11 (Closes:
>  #845278)

This isn't actually fixed, "<<" doesn't mean what you think it means. It only
applies to version that are strctly lower than 1.6.0+snapshot20161117-1, not
lower or equal. The upgrade is still broken.

Cheers

Bug#842311: node-grunt-cli: uninstallable due to wrong dependency

[Alessandro Ghedini]

Package: node-grunt-cli
Version: 1.2.0-1
Severity: grave
Justification: renders package unusable

Hello,

when trying to install the package I get:

  The following packages have unmet dependencies:
   node-grunt-cli : Depends: node-findup-sync (>= 0.3.0) but 0.1.3-1 is to be 
installed
  E: Unable to correct problems, you have held broken packages.

Cheers

-- System Information:
Debian Release: stretch/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


signature.asc
Description: PGP signature

Bug#839581: git-buildpackage: '~' expansion not working anymore

[Alessandro Ghedini]

On Sun, Oct 02, 2016 at 07:31:17PM +0200, Guido Günther wrote:
> On Sun, Oct 02, 2016 at 11:42:49AM +0100, Alessandro Ghedini wrote:
> > Package: git-buildpackage
> > Version: 0.8.4
> > Severity: normal
> > 
> > Hello,
> > 
> > I have the following values in my gbp.conf:
> > 
> > [DEFAULT]
> > ...
> > export-dir   = ~/devel/debian/build-area
> > tarball-dir  = ~/devel/debian/build-area
> > 
> > However when building a package I now get:
> > 
> >  % gbp buildpackage --git-ignore-branch --git-verbose
> > gbp:debug: ['git', 'rev-parse', '--show-cdup']
> > gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
> > gbp:debug: true [] []
> > gbp:debug: ['git', 'status', '--porcelain']
> > gbp:debug: ['git', 'symbolic-ref', 'HEAD']
> > gbp:debug: ['git', 'show-ref', 'refs/heads/local']
> > gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'HEAD']
> > gbp:debug: ['git', 'ls-tree', 'HEAD']
> > gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/changelog']
> > gbp:error: Cannot create output dir 
> > /home/ghedo/devel/debian/chromium-browser/~/devel/debian/build-area
> > 
> > as you can see the '~' expansion isn't working anymore. Downgrading to 0.8.3
> > "fixes" the problem.
> 
> A cleanup made me drop _all_ --git-export-dir related options. Could you
> check if current master unbreaks it for you? I can provide a deb if it's
> simpler.

Not quite sure what master you refer to, but the git repo linked from
https://packages.qa.debian.org/g/git-buildpackage.html reports "Service
Temporarily Unavailable" (the certificate is also invalid) so having a
deb would probably be easier.

Cheers


signature.asc
Description: PGP signature

Bug#839581: git-buildpackage: '~' expansion not working anymore

[Alessandro Ghedini]

Package: git-buildpackage
Version: 0.8.4
Severity: normal

Hello,

I have the following values in my gbp.conf:

[DEFAULT]
...
export-dir   = ~/devel/debian/build-area
tarball-dir  = ~/devel/debian/build-area

However when building a package I now get:

 % gbp buildpackage --git-ignore-branch --git-verbose
gbp:debug: ['git', 'rev-parse', '--show-cdup']
gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
gbp:debug: true [] []
gbp:debug: ['git', 'status', '--porcelain']
gbp:debug: ['git', 'symbolic-ref', 'HEAD']
gbp:debug: ['git', 'show-ref', 'refs/heads/local']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'HEAD']
gbp:debug: ['git', 'ls-tree', 'HEAD']
gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/changelog']
gbp:error: Cannot create output dir 
/home/ghedo/devel/debian/chromium-browser/~/devel/debian/build-area

as you can see the '~' expansion isn't working anymore. Downgrading to 0.8.3
"fixes" the problem.

Cheers

-- System Information:
Debian Release: stretch/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages git-buildpackage depends on:
ii  devscripts2.16.8
ii  git   1:2.9.3-1
ii  man-db2.7.5-1
ii  python-dateutil   2.5.3-2
ii  python-pkg-resources  28.0.0-1
ii  python-six1.10.0-3
pn  python:any

Versions of packages git-buildpackage recommends:
ii  pbuilder 0.226.1
ii  pristine-tar 1.37
ii  python-requests  2.11.1-1

Versions of packages git-buildpackage suggests:
pn  python-notify  
ii  sudo   1.8.17p1-2
pn  unzip  

-- no debconf information


signature.asc
Description: PGP signature

Bug#836456: AttributeError: 'file' object has no attribute 'readable'

[Alessandro Ghedini]

Package: dput
Version: 0.10.2
Severity: grave
Justification: renders package unusable

Hello,

every time I try to upload something I get the following:

>  % dput local-desktop_0.83_amd64.changes
> Trying to upload package to ghedini.me
> Checking signature on .changes
> Traceback (most recent call last):
>   File "/usr/bin/dput", line 11, in 
> load_entry_point('dput==0.10.2', 'console_scripts', 'execute-dput')()
>   File "/usr/share/dput/dput/dput.py", line 1053, in main
> config, check_only, check_version, unsigned_upload, debug)
>   File "/usr/share/dput/dput/dput.py", line 415, in verify_files
> config, check_only, unsigned_upload, binary_upload, debug)
>   File "/usr/share/dput/dput/dput.py", line 313, in verify_signature
> check_signature(changes_file)
>   File "/usr/share/dput/dput/dput.py", line 248, in check_signature
> gnupg_stdout = dputhelper.make_text_stream(gnupg_subprocess.stdout)
>   File "/usr/share/dput/dput/helper/dputhelper.py", line 188, in 
> make_text_stream
> result = io.TextIOWrapper(stream, encoding=encoding)
> AttributeError: 'file' object has no attribute 'readable'
> gpg: Signature made Sat 03 Sep 2016 12:33:10 BST
> gpg:using RSA key 6F0CCBE021624728
> gpg:issuer "gh...@debian.org"
> gpg: Good signature from "Alessandro Ghedini " 
> [unknown]
> gpg: aka "Alessandro Ghedini " [unknown]
> gpg: aka "Alessandro Ghedini " [unknown]

then dput dies and the pckage does not get uploaded.

Cheers

-- System Information:
Debian Release: stretch/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dput depends on:
ii  gnupg 2.1.15-2
ii  python-debian 0.1.29
ii  python-pkg-resources  26.1.1-1
pn  python:any

dput recommends no packages.

Versions of packages dput suggests:
pn  lintian 
pn  mini-dinstall   
ii  openssh-client  1:7.3p1-1
pn  rsync   

-- no debconf information


signature.asc
Description: PGP signature

Bug#830273: curl: accesses the internet during build

[Alessandro Ghedini]

On Sat, Aug 20, 2016 at 11:50:56am +0100, Chris Lamb wrote:
> found 830273 7.50.1-1
> thanks
> 
> Alas,
> 
>   00:00:00.00 IP 370637f7189a.58723 > 10.0.1.1.domain: 48987+ A? 
> 1216.256.2.127. (32)
>   00:00:00.73 IP 370637f7189a.58723 > 10.0.1.1.domain: 25462+ ? 
> 1216.256.2.127. (32)
>   00:00:00.016656 IP 10.0.1.1.domain > 370637f7189a.58723: 25462 NXDomain* 
> 0/0/0 (32)
>   00:00:00.017927 IP 10.0.1.1.domain > 370637f7189a.58723: 48987 NXDomain* 
> 0/0/0 (32)
>   00:00:00.018115 IP 370637f7189a.52668 > 10.0.1.1.domain: 12746+ A? 
> 1216.256.2.127.chris-lamb.co.uk. (49)
>   00:00:00.018273 IP 370637f7189a.52668 > 10.0.1.1.domain: 22321+ ? 
> 1216.256.2.127.chris-lamb.co.uk. (49)
>   00:00:00.048244 IP 10.0.1.1.domain > 370637f7189a.52668: 12746 NXDomain* 
> 0/0/0 (49)
>   00:00:00.050825 IP 10.0.1.1.domain > 370637f7189a.52668: 22321 NXDomain* 
> 0/0/0 (49)
>   00:08:27.786810 IP 370637f7189a.46161 > 10.0.1.1.domain: 11686+ A? 
> 1216.256.2.127. (32)
>   00:08:27.786863 IP 370637f7189a.46161 > 10.0.1.1.domain: 44570+ ? 
> 1216.256.2.127. (32)
> 
>   [..]
> 
> The full build log (including tcpdump output) is attached.

Possible patch attached, could you please test it?

Thanks
From dcb559a161960ff387d2b1552ec4c81b54db4554 Mon Sep 17 00:00:00 2001
From: Alessandro Ghedini 
Date: Sun, 28 Aug 2016 14:45:15 +0100
Subject: [PATCH 1/2] Disable more network tests

Closes: #830273
---
 debian/patches/10_disable-network-tests.patch | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/debian/patches/10_disable-network-tests.patch b/debian/patches/10_disable-network-tests.patch
index 119df54..9bc4cd2 100644
--- a/debian/patches/10_disable-network-tests.patch
+++ b/debian/patches/10_disable-network-tests.patch
@@ -37,3 +37,13 @@ Last-Update: 2016-08-03
  
  
  
+--- a/tests/data/test237
 b/tests/data/test237
+@@ -2,6 +2,7 @@
+ 
+ 
+ FTP
++non-existing host
+ 
+ 
+ 
-- 
2.9.3



signature.asc
Description: PGP signature

Bug#833306: debian-keyring: duplicated key 0xAFA51BD6CDE573CB

[Alessandro Ghedini]

On Tue, Aug 02, 2016 at 06:52:39PM +0100, Alessandro Ghedini wrote:
> and when building the keyrings from the git repository it appears four times:
> 
>  % gpg2 --no-default-keyring --keyring output/keyrings/debian-keyring.gpg 
> --list-keys gh...@debian.org
> pub   rsa4096/AFA51BD6CDE573CB 2010-10-29 [SC]
> uid     [ unknown] Alessandro Ghedini 
> uid     [ unknown] Alessandro Ghedini 
> uid     [ unknown] Alessandro Ghedini 
> sub   rsa4096/386B706D9A7BDF04 2010-10-29 [E]
> sub   ed25519/1730268A0D03529E 2015-09-23 [A]
> sub   rsa2048/8481A825D63CF092 2015-09-23 [A]
> sub   rsa4096/6F0CCBE021624728 2016-06-20 [S]
> 
> pub   rsa4096/AFA51BD6CDE573CB 2010-10-29 [SC]
> uid [ unknown] Alessandro Ghedini 
> uid [ unknown] Alessandro Ghedini 
> uid [ unknown] Alessandro Ghedini 
> sub   rsa4096/386B706D9A7BDF04 2010-10-29 [E]
> sub   ed25519/1730268A0D03529E 2015-09-23 [A]
> sub   rsa2048/8481A825D63CF092 2015-09-23 [A]
> 
> pub   rsa4096/AFA51BD6CDE573CB 2010-10-29 [SC]
> uid [ unknown] Alessandro Ghedini 
> uid [ unknown] Alessandro Ghedini 
> uid [ unknown] Alessandro Ghedini 
> sub   rsa4096/386B706D9A7BDF04 2010-10-29 [E]
> sub   rsa2048/8481A825D63CF092 2015-09-23 [A]
> sub   rsa4096/6F0CCBE021624728 2016-06-20 [S]
> 
> pub   rsa4096/AFA51BD6CDE573CB 2010-10-29 [SC]
> uid     [ unknown] Alessandro Ghedini 
> uid     [ unknown] Alessandro Ghedini 
> uid [ unknown] Alessandro Ghedini 
> sub   rsa4096/386B706D9A7BDF04 2010-10-29 [E]
> sub   ed25519/1730268A0D03529E 2015-09-23 [A]
> sub   rsa2048/8481A825D63CF092 2015-09-23 [A]

Actually, the two additional keys are there due to the fact that I had the
system debian-keyring.gpg enabled in gpg.conf. This is the correct output:

 % gpg2 --no-default-keyring --keyring output/keyrings/debian-keyring.gpg 
--list-keys gh...@debian.org
pub   rsa4096/AFA51BD6CDE573CB 2010-10-29 [SC]
uid [ unknown] Alessandro Ghedini 
uid [ unknown] Alessandro Ghedini 
uid [ unknown] Alessandro Ghedini 
sub   rsa4096/386B706D9A7BDF04 2010-10-29 [E]
sub   rsa2048/8481A825D63CF092 2015-09-23 [A]
sub   rsa4096/6F0CCBE021624728 2016-06-20 [S]

pub   rsa4096/AFA51BD6CDE573CB 2010-10-29 [SC]
uid [ unknown] Alessandro Ghedini 
uid [ unknown] Alessandro Ghedini 
uid [ unknown] Alessandro Ghedini 
sub   rsa4096/386B706D9A7BDF04 2010-10-29 [E]
sub   ed25519/1730268A0D03529E 2015-09-23 [A]
sub   rsa2048/8481A825D63CF092 2015-09-23 [A]

(the correct key being the first one)

Cheers


signature.asc
Description: PGP signature

Bug#833306: debian-keyring: duplicated key 0xAFA51BD6CDE573CB

[Alessandro Ghedini]

Package: debian-keyring
Version: 2016.07.02
Severity: normal

Hello,

it appears that my key has been included twice in the debian-keyring.gpg as
shipped in the debian-keyring package:

 % gpg2 --no-default-keyring --keyring /usr/share/keyrings/debian-keyring.gpg 
--list-keys gh...@debian.org
pub   rsa4096/AFA51BD6CDE573CB 2010-10-29 [SC]
uid [ unknown] Alessandro Ghedini 
uid [ unknown] Alessandro Ghedini 
uid [ unknown] Alessandro Ghedini 
sub   rsa4096/386B706D9A7BDF04 2010-10-29 [E]
sub   ed25519/1730268A0D03529E 2015-09-23 [A]
sub   rsa2048/8481A825D63CF092 2015-09-23 [A]
sub   rsa4096/6F0CCBE021624728 2016-06-20 [S]

pub   rsa4096/AFA51BD6CDE573CB 2010-10-29 [SC]
uid [ unknown] Alessandro Ghedini 
uid [ unknown] Alessandro Ghedini 
uid [ unknown] Alessandro Ghedini 
sub   rsa4096/386B706D9A7BDF04 2010-10-29 [E]
sub   ed25519/1730268A0D03529E 2015-09-23 [A]
sub   rsa2048/8481A825D63CF092 2015-09-23 [A]

and when building the keyrings from the git repository it appears four times:

 % gpg2 --no-default-keyring --keyring output/keyrings/debian-keyring.gpg 
--list-keys gh...@debian.org
pub   rsa4096/AFA51BD6CDE573CB 2010-10-29 [SC]
uid [ unknown] Alessandro Ghedini 
uid [ unknown] Alessandro Ghedini 
uid [ unknown] Alessandro Ghedini 
sub   rsa4096/386B706D9A7BDF04 2010-10-29 [E]
sub   ed25519/1730268A0D03529E 2015-09-23 [A]
sub   rsa2048/8481A825D63CF092 2015-09-23 [A]
sub   rsa4096/6F0CCBE021624728 2016-06-20 [S]

pub   rsa4096/AFA51BD6CDE573CB 2010-10-29 [SC]
uid [ unknown] Alessandro Ghedini 
uid [ unknown] Alessandro Ghedini 
uid [ unknown] Alessandro Ghedini 
sub   rsa4096/386B706D9A7BDF04 2010-10-29 [E]
sub   ed25519/1730268A0D03529E 2015-09-23 [A]
sub   rsa2048/8481A825D63CF092 2015-09-23 [A]

pub   rsa4096/AFA51BD6CDE573CB 2010-10-29 [SC]
uid [ unknown] Alessandro Ghedini 
uid [ unknown] Alessandro Ghedini 
uid [ unknown] Alessandro Ghedini 
sub   rsa4096/386B706D9A7BDF04 2010-10-29 [E]
sub   rsa2048/8481A825D63CF092 2015-09-23 [A]
sub   rsa4096/6F0CCBE021624728 2016-06-20 [S]

pub   rsa4096/AFA51BD6CDE573CB 2010-10-29 [SC]
uid [ unknown] Alessandro Ghedini 
uid [ unknown] Alessandro Ghedini 
uid [ unknown] Alessandro Ghedini 
sub   rsa4096/386B706D9A7BDF04 2010-10-29 [E]
sub   ed25519/1730268A0D03529E 2015-09-23 [A]
sub   rsa2048/8481A825D63CF092 2015-09-23 [A]

I'm wondering, is it harmless? Was it my fault when applying changes to my key?
Is there any way I can prevent this from happening again in the future?

In any case I think it'd be better to de-duplicate the key if possible.

Thanks!

-- System Information:
Debian Release: stretch/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

debian-keyring depends on no packages.

Versions of packages debian-keyring recommends:
ii  gnupg  1.4.20-6

debian-keyring suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#809194: ITP: golang-github-docopt-docopt-go -- An implementation of docopt in the Go programming language.

[Alessandro Ghedini]

On Wed, Jul 06, 2016 at 11:15:44am +0200, gustavo panizzo wrote:
> >  * I think the examples/ directory should be included in the package but
> >installed as examples files. See dh_installexamples(1) for more 
> > information,
> >but basically you'd need to create an *.examples file under debian/ 
> > listing
> >which file / directory to install as example.
> 
> I don't agree, I think most people will use upstream Golang to develop
> Go apps so they will use go get.

Fair enough.

> >  * The git repo doesn't have an upstream/ tag. You also probably want to 
> > wait
> >to create the debian/ one until after the package is uploaded. Otherwise
> >you'll need to delete it and recreate it if you need to do some changes.
> >In general when sponsoring a package, I prefer to create the tag myself
> >just before uploading (so you don't need to generate it yourself).
> 
> upstream tags are not prefixed, they are 0.6.1, 0.6.2, etc.
> I've deleted the Debian tag

Looks like it's still there (did you remove the remote tag as well?). In any
case it turns out I can't write to pkg-go repos on alioth, so you'll have to
recreate the tag push it yourself for now.

> I've pushed to alioth, take a look to it

Built, signed and uploaded :)

Feel free to ping me next time you need to do an upload for this package.

Cheers


signature.asc
Description: PGP signature

Bug#809194: ITP: golang-github-docopt-docopt-go -- An implementation of docopt in the Go programming language.

[Alessandro Ghedini]

On Mon, Jul 04, 2016 at 09:52:50AM +0200, gustavo panizzo wrote:
> On Mon, Jul 04, 2016 at 12:57:47AM +0100, Alessandro Ghedini wrote:
> > 
> > Any news about this? I'd be interested in using such package :)
> > 
> > Cheers
> 
> Packaging is ready waiting for review and sponsorship
> git://anonscm.debian.org/pkg-go/packages/golang-github-docopt-docopt-go.git
> 
> This package is a dependency of asciinema, please consider to sponsor
> them both, together with golang-github-creack-termios (another asciinema
> dependency).
> 
> git://anonscm.debian.org/pkg-go/packages/asciinema.git
> git://anonscm.debian.org/pkg-go/packages/golang-github-creack-termios.git

TBH I don't really care about the other packages and I don't have enough time
to review something I don't care about, sorry :/

As for golang-github-docopt-docopt-go, I looked at your repo and it looks good
except for a few small nits:

 * You remove bith binaries and examples from the target directory, but it
   seems you missed a couple of files that should also be removed:

-rw-r--r-- root/root 42954 2016-07-03 05:04 
./usr/share/gocode/src/github.com/docopt/docopt-go/docopt_test.go
-rw-r--r-- root/root   891 2016-07-03 05:04 
./usr/share/gocode/src/github.com/docopt/docopt-go/example_test.go

 * I think the examples/ directory should be included in the package but
   installed as examples files. See dh_installexamples(1) for more information,
   but basically you'd need to create an *.examples file under debian/ listing
   which file / directory to install as example.

 * The git repo doesn't have an upstream/ tag. You also probably want to wait
   to create the debian/ one until after the package is uploaded. Otherwise
   you'll need to delete it and recreate it if you need to do some changes.
   In general when sponsoring a package, I prefer to create the tag myself
   just before uploading (so you don't need to generate it yourself).

Thanks for your work :)

Cheers


signature.asc
Description: PGP signature

Bug#809194: ITP: golang-github-docopt-docopt-go -- An implementation of docopt in the Go programming language.

[Alessandro Ghedini]

Hello,

On Mon, Dec 28, 2015 at 02:04:06pm +0800, gustavo panizzo wrote:
> Package: wnpp
> Severity: wishlist
> Owner: gustavo panizzo 
> 
> * Package name: golang-github-docopt-docopt-go
>   Version : 0.6.1
>   Upstream Author : Keith Batten
> * URL : http://docopt.org
> * License : MIT/X
>   Programming Lang: Go
>   Description : An implementation of docopt in the Go programming 
> language.
> 
> docopt helps you define an interface for your command-line app and
> automatically generate a parser for it. Its interface descriptions are
> based on a formalization of the standard conventions used in help
> messages and man pages.
> 
> This package provides an implementation of docopt in the Go programming
> language.

Any news about this? I'd be interested in using such package :)

Cheers


signature.asc
Description: PGP signature

Bug#816973: marked as pending

[Alessandro Ghedini]

On Sat, Apr 09, 2016 at 10:03:08am +, Mateusz Łukasik  wrote:
> tag 816973 pending
> thanks
> 
> Hello,
> 
> Bug #816973 reported by you has been fixed in the Git repository. You can
> see the changelog below, and you can check the diff of the fix at:
> 
> http://git.debian.org/?p=pkg-multimedia/mpv.git;a=commitdiff;h=75e886f
> 
> ---
> commit 75e886f33177df6ed88a5b6141143fdbdf4c9d22
> Author: Mateusz Łukasik 
> Date:   Sat Apr 9 12:03:51 2016 +0200
> 
> Drop mpv-dbg and libmpv-dbg packages.
> 
> diff --git a/debian/changelog b/debian/changelog
> index b01cd4e..be2d643 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,7 +1,7 @@
>  mpv (0.16.0-1) UNRELEASED; urgency=medium
>  
>* Team upload.
> -  * New upstream release. (Closes: #815692)
> +  * New upstream release. (Closes: #815692, #816973)

Please explain how you think this bug is fixed by the new release. The
commit seems completely unrelated.

Cheers


signature.asc
Description: PGP signature

Bug#809710: mpv can never load external subtitle file.

[Alessandro Ghedini]

On Sun, Jan 03, 2016 at 05:30:58PM +0800, Tianming Xie wrote:
> Package: mpv
> Version: 0.14.0-1
> Severity: normal
> 
> Dear Maintainer,
> 
> After upgraded to the current version, mpv can never load external ASS 
> subtitle
> file any more, neither a subtitle file located beside the corresponding video
> file, which may be loaded automatically when opening the video file, nor
> explicitly assigned targets via --sub-file, with the following error log:
> 
> [cplayer] Can not open external file 
> 
> The last version does not have this bug.
> 
> Subtitles embedded as stream within video files seem not affected, but I lack
> more samples to test, and now I do not have subtitle files in other formats.

Could you please provide the ASS file that doesn't work, so I can try to
reproduce this?

Thanks


signature.asc
Description: PGP signature

Bug#810295: WARNING: Serious error when reading debug info

[Alessandro Ghedini]

On Fri, Jan 08, 2016 at 01:31:48PM +1100, Martin Schwenke wrote:
> Package: valgrind
> Version: 1:3.11.0-1
> Severity: important
> 
> When I run valgrind against anything, I see warnings like this:
> 
> $ valgrind -q /bin/echo
> --14923-- WARNING: Serious error when reading debug info
> --14923-- When reading debug info from /lib/x86_64-linux-gnu/ld-2.21.so:
> --14923-- Ignoring non-Dwarf2/3/4 block in .debug_info
> --14923-- WARNING: Serious error when reading debug info
> --14923-- When reading debug info from /lib/x86_64-linux-gnu/ld-2.21.so:
> --14923-- Last block truncated in .debug_info; ignoring
> --14923-- WARNING: Serious error when reading debug info
> --14923-- When reading debug info from /lib/x86_64-linux-gnu/ld-2.21.so:
> --14923-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4
> --14923-- WARNING: Serious error when reading debug info
> --14923-- When reading debug info from /lib/x86_64-linux-gnu/libc-2.21.so:
> --14923-- Ignoring non-Dwarf2/3/4 block in .debug_info
> --14923-- WARNING: Serious error when reading debug info
> --14923-- When reading debug info from /lib/x86_64-linux-gnu/libc-2.21.so:
> --14923-- Last block truncated in .debug_info; ignoring
> --14923-- WARNING: Serious error when reading debug info
> --14923-- When reading debug info from /lib/x86_64-linux-gnu/libc-2.21.so:
> --14923-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4
> 
> This might not actually be a valgrind bug...
> 
>   $ dwarfdump -i 
> /usr/lib/debug/.build-id/1c/3104f034cf1caf07cdc1c4a5f342610146ebe5.debug
> 
>   .debug_info
>   dwarfdump ERROR:  attempting to print .debug_info:  DW_DLE_CU_LENGTH_ERROR 
> (47) (47)
>   attempting to continue.
> 
>   $ dpkg -S 
> /usr/lib/debug/.build-id/1c/3104f034cf1caf07cdc1c4a5f342610146ebe5.debug
>   libc6-dbg:amd64: 
> /usr/lib/debug/.build-id/1c/3104f034cf1caf07cdc1c4a5f342610146ebe5.debug
> 
> So it might be a libc6 bug.
> 
> However, I'm only seeing it causes problems in valgrind so, I guess,
> this seems a good place to start...  :-)

I think this may be related to https://bugs.debian.org/780173. The glibc
package recently enabled compressed debug symbols but valgrind doesn't
support them yet. Though I'm not sure what would be a good way to verify
this.

As for solutions, we can wait for valgrind to add support for compressed
symbols or ask the glibc maintainers to not compress debug symbols. Either
way there's not much I, as maintainer of valgrind, can do about this.

Cheers


signature.asc
Description: PGP signature

Bug#802778: False positive mem leak

[Alessandro Ghedini]

On Fri, Oct 23, 2015 at 03:25:53PM +0200, Mathieu Malaterre wrote:
> Package: valgrind
> Version: 1:3.11.0-1
> Tags: upstream
> 
> Seems like gcc 5 is doing something funky
> (/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21):
> 
> ==3674==
> ==3674== HEAP SUMMARY:
> ==3674== in use at exit: 72,704 bytes in 1 blocks
> ==3674==   total heap usage: 306,736 allocs, 306,735 frees, 22,184,464
> bytes allocated
> ==3674==
> ==3674== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1
> ==3674==at 0x4C28C4F: malloc (vg_replace_malloc.c:299)
> ==3674==by 0x72ED11F: pool (eh_alloc.cc:117)
> ==3674==by 0x72ED11F: __static_initialization_and_destruction_0
> (eh_alloc.cc:244)
> ==3674==by 0x72ED11F: _GLOBAL__sub_I_eh_alloc.cc (eh_alloc.cc:307)
> ==3674==by 0x400EA09: call_init.part.0 (dl-init.c:78)
> ==3674==by 0x400EAF2: call_init (dl-init.c:36)
> ==3674==by 0x400EAF2: _dl_init (dl-init.c:126)
> ==3674==by 0x40011C9: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so)
> ==3674==by 0x1: ???
> ==3674==by 0xFFF00049A: ???
> ==3674==by 0xFFF0004A9: ???
> ==3674==
> ==3674== LEAK SUMMARY:
> ==3674==definitely lost: 0 bytes in 0 blocks
> ==3674==indirectly lost: 0 bytes in 0 blocks
> ==3674==  possibly lost: 0 bytes in 0 blocks
> ==3674==still reachable: 72,704 bytes in 1 blocks
> ==3674== suppressed: 0 bytes in 0 blocks

This is a false positive and should be suppressed. It may take me some time to
look into this though, so if you want to provide a patch (to the debian.supp
file) feel free to do so.

Thanks


signature.asc
Description: PGP signature

Bug#802751: mpv leaks memory while playing vp9/opus/webm video

[Alessandro Ghedini]

On Fri, Oct 23, 2015 at 05:06:17PM +1100, Sylvain BERTRAND wrote:
> Package: mpv
> Version: 0.6.2-2
> 
> mpv fill memory while playing a vp9/opus/webm video file.
> totem is fine, it seems mpv is fine while playing an avc/aac/mp4 video file.

It's probably a ffmpeg issue, but could you upload somewhere a sample of the
file that causes this? So, I can try to reproduce.

Thanks


signature.asc
Description: PGP signature

Bug#803645: fixed in libclang-perl 0.09-3

[Alessandro Ghedini]

On Fri, Dec 04, 2015 at 05:52:36PM +0100, gregor herrmann wrote:
> On Wed, 02 Dec 2015 17:20:31 +0100, Sylvestre Ledru wrote:
> 
> > >> Does this make sense? (Adding Alessandro as well as both upstream and
> > >> DD.)
> > > That's even better, indeed! Sylvestre can better comment on the approach, 
> > > it
> > > looks sensible to me but I don't know if there is a better way.
> > If it builds with that, I am happy :)
> 
> Thanks guys, uploaded with these changes.
> 
> If Alessandro has better ideas or finds a way to add a dynamic
> version check upstream, we can always revisit this fix.

So, from the upstream POV, the main problem is that new clang releases often
break compatibility. This is usually caught by the test suite, but some stuff
might pass through and silently break applications. On the other hand there's
not a lot of stuff using libclang-perl so that's probably not much of a problem.
There's also probably some difference between the default version on Ubuntu,
Debian and other distros, so if someone tried to build with the wrong default
LLVM/Clang version then there's a good chance it will not work.

The other problem is that the default LLVM/Clang versions in Debian adapted
quite slowly to new upstream releases in the past, so if we (me, upstream)
wanted to switch to a newer version, then we'd have to wait for Debian (and
whatever other distro) to switch as well.

Overall I don't have a strong opinion on this, so if someone opens a pull
request on GitHub and manages to not break anything, I'll look into it (though
I won't have lots of time in the next few days/weeks). In the worst case it
will just get reverted in a future release (libclang-perl is really not that
much of an active project anyway).

Finally, to Lucas & co., I'm also open to adding co-maintainers upstream or
even just giving the project away since it seems that I've become the
bottleneck and I'm not really using the project myself. Since you are the ones
doing all the development lately I thought you might be interested. If you are,
just write me an email and we'll coordinate this (but keep in mind the above
about me not being much available in the short term).

Cheers


signature.asc
Description: PGP signature

Bug#803410: jessie-pu: package libvdpau/0.8-3+deb8u2

[Alessandro Ghedini]

On Thu, Oct 29, 2015 at 07:52:23pm +, luca wrote:
> Package: release.debian.org
> Severity: normal
> Tags: jessie
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Dear release team,
> 
> We would like to update libvdpau in jessie to address a segmentation fault in 
> a
> particular use case.
> 
> 0.8-3+deb8u1 was uploaded through jessie-security with an upstream fix for 3
> security bugs: CVE-2015-5198 CVE-2015-5199 CVE-2015-5200 (see
> https://bugs.debian.org/797895).
> 
> The upstream patch unfortunately introduced a regression when running with
> DRI_PRIME=1, as reported by a user in https://bugs.debian.org/802625 and
> upstream has committed a fix for it.
> 
> We already uploaded a fixed version to unstable, and now we would like to
> backport it to jessie as well. The debdiff follows. I have verified that it
> fixes the problem on a vanilla jessie amd64 installation.
> 
> Thank you!
> 
> Kind regards,
> Luca Boccassi
> 
> 
> diff -Nru libvdpau-0.8/debian/changelog libvdpau-0.8/debian/changelog
> --- libvdpau-0.8/debian/changelog   2015-09-05 13:14:50.0 +0100
> +++ libvdpau-0.8/debian/changelog   2015-10-29 19:30:28.0 +
> @@ -1,3 +1,10 @@
> +libvdpau (0.8-3+deb8u2) jessie; urgency=medium

The diff looks good, could you change the target to jessie-security and upload
to security-master?

Also, do you plan to prepare an update for wheezy-security as well?

Cheers


signature.asc
Description: PGP signature

Bug#801113: czmq: Add support for GNU/hurd

[Alessandro Ghedini]

On Tue, Oct 06, 2015 at 05:14:15PM +0100, Luca Boccassi wrote:
> On Tue, 2015-10-06 at 14:18 +0200, Svante Signell wrote:
> > 
> > Currently czmq is not available for GNU/Hurd due to an unsupported OS
> > error and a build dependency on zeromq3.
> > 
> > zeromq3 FTBFS due to an unsupported OS error too and two failing tests.
> > Support for Hurd has been added to zeromq3 in a recent patch to bug
> > #799435.
> > 
> > Attached is a patch that also enables Hurd support for czmq. The package
> > builds fine and all selftests pass.
> 
> Hi Svante,
> 
> Thanks you very much for the patch! Committed and pushed to git on
> Alioth. I tested it on a couple of architectures on Linux, as I have no
> access to a Hurd box.
> 
> Are you going to submit this upstream as well?
> 
> Alessandro, when you have time, could you please do a new upload of CZMQ
> to unstable? Thank you!

Uploaded.

Cheers


signature.asc
Description: PGP signature

Bug#800109: mpv no longer play with --vo x11 option

[Alessandro Ghedini]

Control: tags - fixed-upstream

On Sun, Sep 27, 2015 at 11:08:14am -0500, Herminio Hernandez Jr. wrote:
> I tried with both option and video playback was extremely slow and out of sync
> with the audio. Below is the output I got.

So, even with --hwdec=no mpv decides to fallback to vo=sdl and the end result
is the same. Another thing you might try is use --vo=opengl:sw.

However upstream decided to restore the x11 output, so you'll be able to use it
again in the next release.

Cheers


signature.asc
Description: PGP signature

Bug#800517: curl: the --http2 option does not work

[Alessandro Ghedini]

On Wed, Sep 30, 2015 at 10:05:09PM +0200, Tomasz Buchert wrote:
> On 30/09/15 21:31, Alessandro Ghedini wrote:
> > On Wed, Sep 30, 2015 at 01:00:55pm +0200, Tomasz Buchert wrote:
> > > Package: curl
> > > Version: 7.44.0-2
> > > Severity: normal
> > >
> > > Hi,
> > > curl --http2  does not work for me.
> >
> 
> Hi Alessandro,
> 
> > Works fine here with e.g. https://www.google.com, https://http2.golang.org 
> > and
> > https://http2.cloudflare.com.
> 
> Indeed, -v shows quite well that it works.
> 
> >
> > > I have nghttpx proxy serving content over HTTP2 and when I do:
> > >
> > > curl --http2 https://ADDRESS
> >
> > Can you please post the output with the '-v' flag? Also, how do I configure
> > nghttpx to reproduce this?
> 
> Here is the relevant part:
> 
> ...
> * Connected to tomasz.buchert.pl ([ IP ]) port [ PORT ] (#0)
> * found 181 certificates in /etc/ssl/certs/ca-certificates.crt
> * found 728 certificates in /etc/ssl/certs
> * ALPN, offering h2
> * ALPN, offering http/1.1
> * SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
> *  server certificate verification OK
> *  server certificate status verification SKIPPED
> *  common name: [ COMMON-NAME ] (matched)
> *  server certificate expiration date OK
> *  server certificate activation date OK
> *  certificate public key: RSA
> *  certificate version: #3
> *  subject: C=FR,CN=[ COMMON-NAME ],EMAIL=[ MAIL ]
> *  start date: Wed, 01 Apr 2015 20:47:39 GMT
> *  expire date: Sat, 02 Apr 2016 06:13:28 GMT
> *  issuer: C=IL,O=StartCom Ltd.,OU=Secure Digital Certificate 
> Signing,CN=StartCom Class 1 Primary Intermediate Server CA
> *  compression: NULL
> * ALPN, server did not agree to a protocol
> > GET / HTTP/1.1

Here is what's happening: curl tries to negotiate HTTP/2 during the TLS
handshake using the ALPN extension, but the server doesn't support ALPN (e.g.
OpenSSL in jessie doesn't support it) and instead supports the older NPN
extension (which is deprecated, but still in use).

The problem being that curl in sid uses GnuTLS which *only* supports ALPN and
not NPN, so the client and the server can't negotiate HTTP/2 and fallback to
HTTP/1.1.

It's not really a curl bug, though if curl used OpenSSL (in sid) instead of
GnuTLS this would work. TBH I'm not really inclined to switch back to OpenSSL
for this problem alone (mostly because the intention is to, at some point,
completely drop curl's non-GnuTLS backends from Debian and because NPN is
deprecated), but I can't exclude it completely either.

nghttp2 could implement support for ALPN on its own if it detects that the used
OpenSSL version doesn't support it, but it's probably overkill...

Cheers


signature.asc
Description: PGP signature

Bug#800517: curl: the --http2 option does not work

[Alessandro Ghedini]

On Wed, Sep 30, 2015 at 01:00:55pm +0200, Tomasz Buchert wrote:
> Package: curl
> Version: 7.44.0-2
> Severity: normal
> 
> Hi,
> curl --http2  does not work for me.

Works fine here with e.g. https://www.google.com, https://http2.golang.org and
https://http2.cloudflare.com.

> I have nghttpx proxy serving content over HTTP2 and when I do:
> 
> curl --http2 https://ADDRESS

Can you please post the output with the '-v' flag? Also, how do I configure
nghttpx to reproduce this?

Cheers


signature.asc
Description: PGP signature

Bug#800109: mpv no longer play with --vo x11 option

[Alessandro Ghedini]

On Sat, Sep 26, 2015 at 05:18:01pm -0500, Herminio Hernandez Jr wrote:
> Package: mpv
> Version: 0.11.0-1
> Severity: normal
> 
> Dear Maintainer,
> 
> I am can no longer play videos on mplayer with the --vo x11 option. I am
> running Sid on PowerPC and the video card I have crashes when I have hardware
> acceleration on, so I need to have it disabled. This was working before I
> performed a system upgrade on my system.

The x11 video output was removed (see /usr/share/doc/mpv/changelog.gz) in the
0.11.0 upstream release.

You might want to either try the sdl video output (--vo=sdl) or disable hw
acceleration with --hwdec=no and let mpv pick an appropriate output.

Let me know if any of that helps.

Cheers


signature.asc
Description: PGP signature

Bug#800013: valgrind: New upstream release available (3.11.0)

[Alessandro Ghedini]

On Fri, Sep 25, 2015 at 11:45:09am +0200, Raphaël Hertzog wrote:
> Package: valgrind
> Version: 1:3.10.1-4
> Severity: wishlist
> User: de...@kali.org
> Usertags: origin-kali
> 
> Hello,
> 
> I just noticed[1] that there's a new upstream version of valgrind:
> http://valgrind.org/downloads/valgrind-3.11.0.tar.bz2

Yeah, it was released two days ago.

> It would be nice to update the package in sid/stretch.

I'm already working on it.

Cheers


signature.asc
Description: PGP signature

Bug#796302: nghttp2 is updated

[Alessandro Ghedini]

On Thu, Sep 10, 2015 at 08:05:22am +0200, Daniel Stenberg wrote:
> Seeing that nghttp2 was just updated in Sid to 1.3.0, is there a chance now
> for curl to get HTTP/2 enabled?

Uploaded curl 7.44.0-2 just now, with HTTP/2 support enabled

Chers


signature.asc
Description: Digital signature

Bug#798543: [valgrind] false positives on socket calls with not specially handled address families

[Alessandro Ghedini]

Control: tags -1 fixed-upstream

On Thu, Sep 10, 2015 at 03:29:57pm +0200, Andre Naujoks wrote:
> Hi.
> 
> Sorry for the noise. I just noticed, that this fix is already in the
> upstream svn. Not yet released though.
> 
> I don't know how something like this is handled, so ..  - again - sorry
> for the noise.

No problem, I tagged the report as "fixed-upstream". Thanks for reporting.

Cheers


signature.asc
Description: Digital signature

Bug#797895: libvdpau: CVE-2015-5198, CVE-2015-5199, CVE-2015-5200

[Alessandro Ghedini]

On Sat, Sep 05, 2015 at 12:55:43PM +0100, Luca Boccassi wrote:
> On Thu, 2015-09-03 at 14:49 +0200, Alessandro Ghedini wrote:
> > Source: libvdpau
> > Severity: important
> > Tags: security, fixed-upstream
> > 
> > Hi,
> > 
> > the following vulnerabilities were published for libvdpau.
> > 
> > CVE-2015-5198[0]:
> > incorrect check for security transition
> > 
> > CVE-2015-5199[1]:
> > directory traversal in dlopen
> > 
> > CVE-2015-5200[2]:
> > vulnerability in trace functionality
> > 
> > All of them are fixed by the patch [3], shipped in the 1.1.1 upstream
> > release.
> > 
> > If you fix the vulnerabilities please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
> > 
> > For further information see:
> > 
> > [0] https://security-tracker.debian.org/tracker/CVE-2015-5198
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5198
> > [1] https://security-tracker.debian.org/tracker/CVE-2015-5199
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5199
> > [2] https://security-tracker.debian.org/tracker/CVE-2015-5200
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5200
> > [3] 
> > http://cgit.freedesktop.org/~aplattner/libvdpau/commit/?id=d1f9c16b1a8187110e501c9116d21ffee25c0ba4
> 
> Dear Alessandro and dear Security Team,
> 
> I have backported the upstream patch for the aforementioned CVEs to
> jessie, wheezy and squeeze. I have attached the debdiffs for review.
> 
> I have verified they all build in amd64 and i386 chroots.
> 
> I have verified that the jessie and wheezy amd64 packages work using
> "vdpauinfo".
> 
> Due to the need of a bare-metal installation (direct access to Nvidia
> GPU is required), I have _NOT_ tested other architecture for jessie and
> wheezy, and I have _NOT_ tested the squeeze build at all, because I do
> not possess hardware capable of running with squeeze drivers, but given
> the fact that it's the same upstream version as the wheezy build I am
> reasonably confident it should work.
> 
> Two questions for you:
> 
> 1) Do these CVEs warrant a DSA and an upload to security.debian.org, or
> should I go through the proposed-updates route and ping the release team
> instead?

Yeah, we intend to release a DSA for this. The jessie and wheezy diffs look
good, so please go ahead and upload them to security-master. Note that they
both need to be built with the -sa dpkg-buildpackage flag, since these would
be the first jessie and wheezy security uploads for the package.

> 2) If the answer to 1) is yes, does this apply to squeeze as well or
> should I work with debian-lts team instead?

Yeah, you need to contact the LTS people for squeeze.

Thanks for your help.

Cheers


signature.asc
Description: Digital signature

Bug#797895: libvdpau: CVE-2015-5198, CVE-2015-5199, CVE-2015-5200

[Alessandro Ghedini]

Source: libvdpau
Severity: important
Tags: security, fixed-upstream

Hi,

the following vulnerabilities were published for libvdpau.

CVE-2015-5198[0]:
incorrect check for security transition

CVE-2015-5199[1]:
directory traversal in dlopen

CVE-2015-5200[2]:
vulnerability in trace functionality

All of them are fixed by the patch [3], shipped in the 1.1.1 upstream
release.

If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2015-5198
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5198
[1] https://security-tracker.debian.org/tracker/CVE-2015-5199
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5199
[2] https://security-tracker.debian.org/tracker/CVE-2015-5200
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5200
[3] 
http://cgit.freedesktop.org/~aplattner/libvdpau/commit/?id=d1f9c16b1a8187110e501c9116d21ffee25c0ba4

Please adjust the affected versions in the BTS as needed.

Cheers


signature.asc
Description: Digital signature

Bug#791026: ecasound: library transition may be needed when GCC 5 is the default

[Alessandro Ghedini]

Control: forwarded -1 
https://release.debian.org/transitions/html/auto-ecasound.html

On Mon, Aug 24, 2015 at 10:25:46am +0100, Simon McVittie wrote:
> On Wed, 19 Aug 2015 at 10:17:19 +0100, Simon McVittie wrote:
> > In the case of ecasound, the C++ dependencies don't seem to have been
> > flagged for transition, so I think this means you can upload any time
> > (but please check).
> 
> I have NMU'd this to DELAYED/2, with no changes other than to the changelog.
> 
> Please let me know if I should reschedule or cancel it (for instance
> to DELAYED/0 to speed things up). You are also welcome to do a
> higher-versioned MU, which would cause my NMU to be refused.

After your previous email I had prepared an upload which also fixes a bunch of
other stuff, but then I forgot to upload it :/ so I just uploaded it now as
2.9.1-7.

Cheers


signature.asc
Description: Digital signature

Bug#759005: xdm: Missing xdm.service, can't use with systemd

[Alessandro Ghedini]

On Sun, Aug 23, 2015 at 05:32:18PM +0200, Julien Cristau wrote:
> On Fri, Nov 21, 2014 at 16:02:15 +0100, Alessandro Ghedini wrote:
> 
> > diff --git a/debian/patches/22_systemd_service.diff 
> > b/debian/patches/22_systemd_service.diff
> > new file mode 100644
> > index 000..3d8161d
> > --- /dev/null
> > +++ b/debian/patches/22_systemd_service.diff
> > @@ -0,0 +1,13 @@
> > +--- a/xdm.service.in
> >  b/xdm.service.in
> > +@@ -3,7 +3,7 @@
> > + After=systemd-user-sessions.service
> > + 
> > + [Service]
> > ++# temporary safety check until all DMs are converted to correct
> > ++# display-manager.service symlink handling
> > ++ExecStartPre=/bin/sh -c '[ "$(cat /etc/X11/default-display-manager 
> > 2>/dev/null)" = "/usr/bin/xdm" ]'
> > + ExecStart=BINDIR/xdm -nodaemon
> > +-
> > +-[Install]
> > +-Alias=graphical.target.wants/xdm.service
> 
> What does "correct" mean here?

"correct" as in "how systemd expects it" I suppose. That part came from the
lightdm.service file though, so they are not my own words.

I imagine they meant that once every dm provides a systemd unit file, the
/etc/X11/default-display-manager mechanism can be replaced by the
display-manager.service symlink when systemd is used, so that that check can be
removed.

> How is that symlink handled exactly?

As far as I understand it, just like /etc/X11/default-display-manager is. The
display-manager.service symlink points to the unit file of the default display
manager (the difference being that default-display-manager is not a symlink)
and systemd will start it automatically 

From the systemd.special(7) manpage:

> display-manager.service
> The display manager service. Usually this should be aliased (symlinked) to
> gdm.service or a similar display manager service.

Cheers


signature.asc
Description: Digital signature

Bug#796302: curl: enable http2

[Alessandro Ghedini]

Control: block -1 by 784666

On Fri, Aug 21, 2015 at 10:59:41am +0200, Arnout Engelen wrote:
> Package: curl
> Version: 7.44.0-1
> Severity: normal
> 
> Dear Maintainer,
> 
> When making a request with '--http2', I get the error message
> "curl: (1) Unsupported protocol".

Unfortunately the version of the nghttp2 library (which is used by curl to
implement HTTP/2 support) in Debian is too old.

Cheers


signature.asc
Description: Digital signature

Bug#795595: libasound2-plugin-equal: change package name to "alsa-equalizer-plugin" or similar and move to sound section

[Alessandro Ghedini]

On Sat, Aug 15, 2015 at 05:00:29PM +0200, Marcel Partap wrote:
> Package: libasound2-plugin-equal
> Version: 0.6-6
> Severity: wishlist
> 
> The main reasons being that
> a) it is a hidden gem that should not hide in the dark (libs section)
> b) it easily gets removed accidently by marking all packages in the libs
> section auto-installed, which f.e. can be used to clean up packages on crufty
> machines.

The name was decided to follow the libasound2-plugins package naming scheme, so
I think that before renaming alsaequal, this should maybe be discussed with the
ALSA maintainers (I added jordi to CC since he has been doing alsa-plugins
uploads, and since the ALSA Maintainers mailing list seems to be mostly spam).

TBH I'm not really sure if following the alsa-plugins naming scheme actually
makes sense, and personally I would be okay with a rename.

Cheers


signature.asc
Description: Digital signature

Bug#795958: lynx-cur: certificate revocation checking is buggy

[Alessandro Ghedini]

On Tue, Aug 18, 2015 at 01:32:19pm +0200, Vincent Lefevre wrote:
> Package: lynx-cur
> Version: 2.8.9dev6-3
> Severity: serious
> Tags: security
> 
> If I run
> 
>   lynx https://www.vinc17.net:4434/
> 
> I get
> 
>   SSL error:The certificate is NOT trusted. The certificate chain is revoked.
>   -Continue? (n) 
> 
> as expected. But If I set up a test server with the same certificate
> with:
> 
>   openssl s_server -CAfile old.crt -key old.key -cert old.crt -www

Try adding the "-status" option here.

I think the problem is that both lynx and curl only support OCSP stapling,
while firefox also does full-blown OCSP. So, if you don't enable OCSP stapling
in s_server (with the -status option), lynx and curl won't receive any response,
while firefox will also try to contact the CA's OCSP server and receive a
response from that.

It's more like lack of a feature than an actual bug (hardly RC material though,
IMO).

Hope this helps.

Cheers


signature.asc
Description: Digital signature

Bug#794478: Fwd: Bug#794478: [Security][RC] RFS: imagemagick/8:6.8.9.9-5+deb8u1

[Alessandro Ghedini]

On Sat, Aug 08, 2015 at 09:25:01pm +0200, Bastien ROUCARIES wrote:
> Dear security team
> 
>   I am looking for a sponsor for my package "imagemagick" about a
> security fix and I am waiting for your green light.. Fixing  #770009
> help buildd but is not a security fix (but nevertheless it will help
> the infrastructure).

Thanks for your help, however, all the issues fixed by this update are marked
"no-dsa" in the security tracker [0] for being of minor impact, so we won't
release a DSA for them alone (feel free to comment if you disagree).

As far as wheezy (oldstable) is concerned, there is the matter of #773834
(which is not marked no-dsa), so if you decide to prepare a wheezy-security
upload fixing those issues, you can include the no-dsa fixes as well.

Given that you already prepared the package for jessie, it should be released
through stable-proposed-updates instead, as explained at [1] (so the release
team will handle this). You'll only need to change the target distribution and
open a bug report against release.debian.org (just follow the "reportbug"
instructions).

>* Fix four security bugs:
>  - A DOS on specially crafted MIFF file (TEMP-000-FDAC72).
>  - A DOS on specially crafted Vicar file (TEMP-000-EEF23C).
>  - A DOS on specially crafted HDR file (TEMP-000-7C079F).
>  - A DOs on specially crafted PDB file (TEMP-000-2FC21E).

Please don't mention the "TEMP-" IDs in the changelog, since, as the prefix
suggests, they are only temporary and may change in the future. Proper CVE IDs
were requested for these issues a few months ago [2], but apparently they
haven't been assigned yet.

Again, thanks for your work.

Cheers

[0] https://security-tracker.debian.org/tracker/source-package/imagemagick
[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable
[2] http://www.openwall.com/lists/oss-security/2015/02/26/13


signature.asc
Description: Digital signature

Bug#794851: CVE-2015-0851: shibboleth-sp2 needs to be rebuilt against new xmltooling

[Alessandro Ghedini]

Control: found -1 opensaml2/2.4.3-4
Control: fixed -1 opensaml2/2.4.3-4+deb7u1
Control: fixed -1 opensaml2/2.5.3-2+deb8u1

On Fri, Aug 07, 2015 at 12:36:18pm +0200, Sergio Gelato wrote:
> Package: opensaml2
> Version: 2.5.3-2
> Severity: serious
> Tags: security
> 
> The upstream security advisory for CVE-2015-0851 (see #793855) states
> in part: "Correcting this bug requires that the OpenSAML library be
> rebuilt against the corrected version of the XMLTooling-C library,
> which is normally assured by obtaining updates to both."

Yes, sorry for the delay. I just released fixed opensaml2 packages for wheezy
and jessie security.

Given that unstable is still vulnerable (since a fixed xmltooling version
hasn't been uploaded yet), I'll leave this open for now.

Cheers


signature.asc
Description: Digital signature

Bug#791026: ecasound: library transition may be needed when GCC 5 is the default

[Alessandro Ghedini]

reopen 791026
user release.debian@packages.debian.org
usertag 791026 + transition
block 791026 by 790756
reassign 791026 release.debian.org
kthxbye

On Fri, Jul 03, 2015 at 01:09:43pm +, Matthias Klose wrote:
> Package: src:ecasound
> Version: 2.9.1-5
> Severity: important
> Tags: sid stretch
> User: debian-...@lists.debian.org
> Usertags: libstdc++-cxx11
> 
> Background [1]: libstdc++6 introduces a new ABI to conform to the
> C++11 standard, but keeps the old ABI to not break existing binaries.
> Packages which are built with g++-5 from experimental (not the one
> from testing/unstable) are using the new ABI.  Libraries built from
> this source package export some of the new __cxx11 or B5cxx11 symbols,
> and dropping other symbols.  If these symbols are part of the API of
> the library, then this rebuild with g++-5 will trigger a transition
> for the library.

ecasound needs a transition. I already uploaded the version with the renamed
package to experimental and tested that both reverse build dependencies
(libaudio-ecasound-perl and soundscaperenderer) build fine (soundscaperenderer
is the only reverse dep that would be affected by the symbols renaming).

Cheers


signature.asc
Description: Digital signature

Bug#790750: [curl] HTTPS client certificates don't work anymore

[Alessandro Ghedini]

On mer, lug 01, 2015 at 01:17:10 +, Franz Schrober wrote:
> Package: curl
> Version: 7.43.0-1
> Severity: normal

Hi Franz,

sorry for the delay, I seem to have missed the report when you submitted it...

> sid seems to be changed from curl-openssl to curl-gnutls. As result client
> certificates don't work anymore. The client cert packet just contains 0
> certificates when 1 certificate is expected. It worked fine with curl-openssl.

I can't reproduce this. I tried using "openssl s_server" with the -verify
option and the client certificate is sent correctly AFAICT. Could you try this
as well and post what s_server says?

Cheers


signature.asc
Description: Digital signature

Bug#790365: closed by Alessandro Ghedini (Bug#790365: fixed in libwmf 0.2.8.4-10.4)

[Alessandro Ghedini]

Control: notfixed -1 libwmf/0.2.8.4-10.4

On Fri, Jul 31, 2015 at 09:45:17AM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the pycode-browser package:
> 
> #790365: pycode-browser: CVE-2015-0849: predictable temporary file 
> vulnerability
> 
> It has been closed by Alessandro Ghedini .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Alessandro Ghedini 
>  by
> replying to this email.

Not sure how this happened, but it looks like I closed the wrong bug... Sorry
for the noise.

Cheers


signature.asc
Description: Digital signature

Bug#630761: RFP: libczmq -- High-level C binding for ZeroMQ

[Alessandro Ghedini]

On Thu, Jul 30, 2015 at 08:24:34PM +0100, Luca Boccassi wrote:
> On Thu, 2015-07-30 at 16:58 +0200, Alessandro Ghedini wrote:
> > * The -dev package should just be named libczmq-dev (i.e. without the 
> > version),
> >   this way next time the project bumps the SONAME it'll be easier to do the
> >   transition (you won't have to update all the reverse build dependencies).
> > 
> > * Same goes for -dbg, but it's less important in that case.
> 
> Reasoning for this choice was to follow what libzmq does, since the
> maintainer is making both libzmq1 and libzmq3 (and libzmq5 in
> experimental) available at the same time, and I thought in the future
> I'd do the same for libczmq.

FWIW, being the one who originally packaged the zeromq and zeromq3 packages,
the reason why I kept them separate was that some of the reverse dependencies
of libzmq-dev did not build with the newer version, so both had to be kept in
the archive. Otherwise I would have just renamed libzmq1 to libzmq3 and kept
the same -dev, -dbg and source package names.

> > * The README.source doesn't really provide any useful information, so it can
> >   be removed (also, since the dh-autoreconf plugin is used, the tarball
> >   generated from GitHub would probably work as well).
> 
> I added it since there is a discrepancy between the tarballs on the
> official website and Github, and to explain it.
> 
> If it is all right with you, I would rather keep using the tarball from
> the website

Yeah, that's fine. My point was that you don't really need to justify why you
used one tarball instead of the other, so the README.source file is useless
(the debian/watch file already tells people where the tarball comes from).

> > * No need to override the debian-watch-may-check-gpg-signature lintian 
> > warning
> >   (but it's not a problem if you want to do it anyway...).
> 
> It was giving a warning on the Mentors upload page, so I added it. I'd
> like to keep it overridden if you don't mind :-)

Sure, no problem.

So, now the package looks good. Please set the target distribution to "unstable"
in the changelog and I'll upload.

Cheers


signature.asc
Description: Digital signature

Bug#630761: RFP: libczmq -- High-level C binding for ZeroMQ

[Alessandro Ghedini]

On Thu, Jul 23, 2015 at 03:58:55AM +0100, Luca Boccassi wrote:
> owner 630761 luca.bocca...@gmail.com
> thanks

Note that you need to CC cont...@bugs.debian.org for this to work, or you can
use the "Control" pseudo-header.

> Hello,

Hi,

> I took the liberty of upgrading the repository on Alioth [1] to CZMQ
> 3.0.2, and uploaded the resulting packages to Mentors [2]. I added 2
> backported patches, fixed some warnings and other changes.
> 
> If it is all right with you, I will take over maintenance of this
> package and try to find a sponsor to finally upload it to Debian. The
> RFP is now 4 years old! :-)
> 
> I already am the maintainer of the internal build of CZMQ at Brocade, so
> I am already doing this job for the company. Might as well do it for the
> community too!

So, I had a look at the package and here are a few notes:

* The changelog entries should be merged into a single one since it would be
  the first upload for the package. There's no need to list all the changes
  there either, the "Initial release" message with the closed bug is enough.

* The -dev package should just be named libczmq-dev (i.e. without the version),
  this way next time the project bumps the SONAME it'll be easier to do the
  transition (you won't have to update all the reverse build dependencies).

* Same goes for -dbg, but it's less important in that case.

* The Conflicts field is not needed either way since the libczmq-dev package
  doesn't exist (and if you do rename the -dev package the Provides field is
  not needed either).

* The README.source doesn't really provide any useful information, so it can
  be removed (also, since the dh-autoreconf plugin is used, the tarball
  generated from GitHub would probably work as well).

* No need to use both autotools-dev and dh-autoreconf. autoreconf is enough.

* No need to override the debian-watch-may-check-gpg-signature lintian warning
  (but it's not a problem if you want to do it anyway...).

* Generally it's better to license the debian/* files under the same license
  of the project, in this case MPL-2.0. It seems that when the project was
  relicensed from the LGPL-3+, Arnaud decided to put the debian files under
  GPL-3 (without my consent...) which IMO doesn't make a lot of sense.

* You can safely remove Gergely and myself from the Uploaders list. I think
  it's also safe to remove Arnaud as well since he's been inactive for a while
  (he can always be added back if needed).

* You might want to update the page at http://zeromq.org/distro:debian with
  your name.

I think that's all, though I might have missed something.

So, anyway, I'm open to sponsoring the package if needed, since Arnaud seems to
be inactive. Once you've fixed the above just ping me and I'll have another look
(no need to upload the package to mentors.d.n, I only use git anyway).

Cheers


signature.asc
Description: Digital signature

Bug#790446: mpv: Warning about mismatch between build and run-time ffmpeg libraries

[Alessandro Ghedini]

Control: tags -1 fixed-upstream

On Mon, Jun 29, 2015 at 06:01:04pm +0200, Guillem Jover wrote:
> Package: mpv
> Version: 0.9.2-1+ffmpeg
> Severity: normal
> 
> Hi!
> 
> [ First of all, thanks for providing a ffmpeg version of the package,
>   there's quite some media that does not play correctly with libav. ]
> 
> The mpv program emits the following warning on startup:
> 
> ,---
> Warning: mpv was compiled against a different version of ffmpeg than the 
> shared
> library it is linked against. This can expose subtle ABI compatibility issues
> and can lead to misbehavior and crashes.
> `---
> 
> Which, to me points out there's a problem somewhere. Either:
> 
>  * the warning is bogus, and
>- mpv should be silenced in common/av_log.c:print_libav_versions, or

Upstream removed the warning now, see [0].

Cheers

[0] 
https://github.com/mpv-player/mpv/commit/5594379b27f3c19a475b83a001a1cd96946c


signature.asc
Description: Digital signature

Bug#792571: tidy: CVE-2015-5522 and CVE-2015-5523

[Alessandro Ghedini]

Source: tidy
Version: 20091223cvs-1.2
Severity: important
Tags: security upstream patch

Hi,

the following vulnerabilities were published for tidy.

CVE-2015-5522[0]:
AddressSanitizer: heap-buffer-overflow WRITE of size 1

CVE-2015-5523[1]:
small file can lead to a 4 Gb allocation; potential DoS

A patch is provided by the tidy-html5 fork at [2].

If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2015-5522
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5522
[1] https://security-tracker.debian.org/tracker/CVE-2015-5523
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5523
[2] 
https://github.com/htacg/tidy-html5/commit/c18f27a58792f7fbd0b30a0ff50d6b40a82f940d

Cheers


signature.asc
Description: Digital signature

Bug#790446: mpv: Warning about mismatch between build and run-time ffmpeg libraries

[Alessandro Ghedini]

Control: forwarded -1 https://github.com/mpv-player/mpv/issues/2110

Sorry for the delay.

On mer, lug 01, 2015 at 10:35:13 +0200, Andreas Cadhalpun wrote:
> Hi Guillem,
> 
> On 30.06.2015 23:14, Andreas Cadhalpun wrote:
> > On 30.06.2015 21:40, Guillem Jover wrote:
> >> Perhaps, but the comment at
> >> 
> >> was not very soothing, so that was one additional reason for the bug. :)
> > 
> > Hmm, this comment is indeed a bit worrisome.
> > But I'm not sure I understand the reasoning given there. As far as I know
> > the accessor functions are only necessary for API that is not present
> > in Libav (in order to be ABI compatible after Libav merges, as the comment
> > says). So whether or not one uses the accessors shouldn't make a difference
> > for compatibility with Libav.
> 
> I've investigated this a bit more and it seems that the only potentially
> problematic FFmpeg-only API used by mpv is AVFrame->metadata, which mpv
> accesses via av_frame_get_metadata. [1]
> Thus I think the comment is just wrong and the warning should be removed.

If I understand the comment correctly, the problem isn't so much ffmpeg-only
APIs like ->metadata, but the fact that mpv doesn't use accessor functions for
struct fields provided by ffmpeg to maintain ABI compatibility because libav
doesn't have those functions (but it still has the structs).

IMO the warning can be removed in the Debian packages because it's fairly
annoying and mostly useless (it's not like Debian users can do anything about
it besides recompiling the package), but maybe we should better investigate
this alleged ABI compatibility problem in ffmpeg.

For example the upstream-tracker thingy shows several ABI changes introduced in
ffmpeg 2.5 (e.g. new fields in the middle of structs) without a SONAME bump:
http://upstream.rosalinux.ru/versions/ffmpeg.html

The mpv Debian package could also start using the accessors that ffmpeg
provides but only when built with ffmpeg (which should hopefully become the
default soonish), but tracking down where these accessors should be used is
probably going to be a bit of a pain.

Cheers


signature.asc
Description: Digital signature

Bug#789748: jansson: [PATCH] please make the build reproducible

[Alessandro Ghedini]

Control: tags -1 pending

On mer, giu 24, 2015 at 12:24:57 -0300, Juan Picca wrote:
> Package: jansson
> Version: 2.7-3
> Severity: wishlist
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: timestamps
> 
> Hi!
> 
> While working on the "reproducible builds" effort [1], we have noticed
> that jansson could not be built reproducibly.
> 
> The attached patch removes extra timestamps from the build system.
> Once applied, jansson can be built reproducibly in our current
> experimental framework.

I merged your patch in the git repository, thanks.

Cheers


signature.asc
Description: Digital signature

Bug#781640: Downgrading bug severity

[Alessandro Ghedini]

On Thu, Jun 18, 2015 at 09:17:40PM +0200, Daniele Tricoli wrote:
> On Wednesday 17 June 2015 22:49:24 Moritz Mühlenhoff wrote:
> > Any feedback from your sponsor?
> 
> Sorry I was a bit busy so I finalized the package only now. :(
> 
> Already sent an RFS and Piotr is usually very fast, so it should be uploaded 
> soon.

I just released the DSA for jessie. What's the status for the unstable upload?

Cheers


signature.asc
Description: Digital signature

Bug#788349: mpv: Segmentation fault after upgrade (libnettle6 installation)

[Alessandro Ghedini]

Control: reassign -1 libnettle4
Control: forcemerge 787620 -1

On Wed, Jun 10, 2015 at 03:31:13PM +0200, nfb wrote:
> Package: mpv
> Version: 0.9.2-1
> Severity: important
> 
> Hi,
> after today's upgrade which installed libnettle6 as dependency, i get
> segmentation fault running mpv.
> Here is the gdb output:
> 
> 
> $ gdb mpv
> (gdb) run
> Starting program: /usr/bin/mpv 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library
> "/lib/arm-linux-gnueabihf/libthread_db.so.1".
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0xb468e580 in nettle_yarrow256_update () from
> /usr/lib/arm-linux-gnueabihf/libnettle.so.6
> (gdb) bt
> #0  0xb468e580 in nettle_yarrow256_update () from
> /usr/lib/arm-linux-gnueabihf/libnettle.so.6
> #1  0xb51bc76c in ?? () from
> /usr/lib/arm-linux-gnueabihf/libgnutls-deb0.so.28
> Backtrace stopped: previous frame identical to this frame (corrupt
> stack?)
> 
> 
> May be related to bug #788333:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788333

Yep, same as #787620 as well. It's caused by the fact that libnettle4 doesn't
provide symbols versioning so both libenttle4 and libnettle6 may get loaded at
the same time.

To fix this you should make sure that packages that use nettle are updated, in
particular libgnutls-deb0-28.

Since mpv doesn't depend directly on nettle or gnutls (they are pulled in due
to other packages), there isn't anything I can do about this.

Cheers


signature.asc
Description: Digital signature

Bug#786487: wordpress: 4.2.2 needs php-getid3 from unstable, request for backport or dependency version downgrade

[Alessandro Ghedini]

On lun, giu 08, 2015 at 03:29:02 +0200, Raphael Hertzog wrote:
> On Mon, 08 Jun 2015, Alessandro Ghedini wrote:
> > On lun, giu 08, 2015 at 02:36:17 +0200, Raphael Hertzog wrote:
> > > Dear members of the security team,
> > > 
> > > Craig told me (cf message below) that you refused new upstream releases of
> > > Wordpress to fix security issues in stable/oldstable. Since we already did
> > > that in the past with Yves-Alexis Perez, what is the reason of this change
> > > of policy?
> > 
> > I did not refuse the update. I simply pointed out that the new upstream 
> > release
> > had several changes that didn't seem appropriate for a stable upload and
> > suggested to seek the release team's opinion about them. Though I can see 
> > how
> > that could have been misinterpreted.
> 
> I don't think that we seeked the stable RM's approval for any previous
> upload that introduced a new upstream version, Yves-Alexis, do you
> remember?
> 
> AFAIK if the securiy team is OK with the new upstream release on
> security.debian.org, then it's good enough. It's a matter of doing the
> right thing for our users. And I believe that everybody in the wordpress
> community (developers and users alike) want to have the latest version
> since that's the only one truly supported.
> 
> Craig has been doing much more backporting work than what I used to do in
> the past and it would be sad to impose him stricter rules just because he
> made the efforts that I did not do at that time.

Sure, whatever. I'll just let someone else from the team handle wordpress from
now on.

Cheers


signature.asc
Description: Digital signature

Bug#786487: wordpress: 4.2.2 needs php-getid3 from unstable, request for backport or dependency version downgrade

[Alessandro Ghedini]

On Mon, Jun 08, 2015 at 03:10:53PM +0200, Alessandro Ghedini wrote:
> On lun, giu 08, 2015 at 02:36:17 +0200, Raphael Hertzog wrote:
> > Dear members of the security team,
> > 
> > Craig told me (cf message below) that you refused new upstream releases of
> > Wordpress to fix security issues in stable/oldstable. Since we already did
> > that in the past with Yves-Alexis Perez, what is the reason of this change
> > of policy?
> 
> I did not refuse the update. I simply pointed out that the new upstream 
> release
> had several changes that didn't seem appropriate for a stable upload and
> suggested to seek the release team's opinion about them. Though I can see how
> that could have been misinterpreted.

To be precise, I'm referring to the automatic database updates. However, if
similar changes have been accepted in the past, I guess I'm ok with them.

Cheers


signature.asc
Description: Digital signature

Bug#786487: wordpress: 4.2.2 needs php-getid3 from unstable, request for backport or dependency version downgrade

[Alessandro Ghedini]

On lun, giu 08, 2015 at 02:36:17 +0200, Raphael Hertzog wrote:
> Dear members of the security team,
> 
> Craig told me (cf message below) that you refused new upstream releases of
> Wordpress to fix security issues in stable/oldstable. Since we already did
> that in the past with Yves-Alexis Perez, what is the reason of this change
> of policy?

I did not refuse the update. I simply pointed out that the new upstream release
had several changes that didn't seem appropriate for a stable upload and
suggested to seek the release team's opinion about them. Though I can see how
that could have been misinterpreted.

Cheers


signature.asc
Description: Digital signature

Bug#787960: libcurl3-gnutls: breaks bti

[Alessandro Ghedini]

On dom, giu 07, 2015 at 01:44:36 +0200, Vincent Lefevre wrote:
> On 2015-06-07 11:40:56 +0200, Alessandro Ghedini wrote:
> > I can't reproduce any of this. Can you please run the command above
> > with the "-v" option and post the output?
> 
> xvii:~> curl -v https://www.vinc17.net/
> *   Trying 92.243.22.117...
> * Connected to www.vinc17.net (92.243.22.117) port 443 (#0)
> * found 180 certificates in /etc/ssl/certs/ca-certificates.crt

Ok, nevermind, that looks ok. Looking at your original report again, I noticed
the following:

> Versions of packages libcurl3-gnutls depends on:
>  [...]
>  ii  libgnutls-deb0-28  3.3.14-2

Essentially you have installed an older version of libgnutls-deb0-28 (the
current one is 3.3.15-5). I think the problem is that the older libgnutls uses
a different version of nettle (libnettle.so.4) than the one libcurl3-gnutls
uses (libnettle.so.6), and they somehow interfere with each other since nettle
doesn't use symbols versioning.

Could you update libgnutls-deb0-28 and see what happens? In any case it doesn't
look like a libcurl bug, although maybe the versioned depends on libgnutls could
be strengthened (it's currently calculated automatically by dpkg-shlibdeps).

Cheers


signature.asc
Description: Digital signature

Bug#787960: libcurl3-gnutls: breaks bti

[Alessandro Ghedini]

On dom, giu 07, 2015 at 12:21:15 +0200, Vincent Lefevre wrote:
> Control: retitle -1 no longer works with https - breaks bti and curl
> 
> On 2015-06-07 00:16:15 +0200, Vincent Lefevre wrote:
> > After the upgrade to libcurl3-gnutls 7.42.1-2+b1, bti no longer works
> > at all. For instance:
> [...]
> 
> It also breaks curl:
> 
> $ curl https://www.vinc17.net/
> curl: (60) server certificate verification failed. CAfile: 
> /etc/ssl/certs/ca-certificates.crt CRLfile: none
> More details here: http://curl.haxx.se/docs/sslcerts.html

I can't reproduce any of this. Can you please run the command above with the
"-v" option and post the output? Also, what's the content of the file
/etc/ssl/certs/ca-certificates.crt?

Cheers


signature.asc
Description: Digital signature

Bug#787712: libcurl: relocation error libcurl.so.4: symbol SSLv3_client_method

[Alessandro Ghedini]

Control: reassign -1 openssl
Control: forcemerge 768476 -1
Control: affects -1 + libcurl3

On gio, giu 04, 2015 at 11:52:27 +0100, Peter T. Breuer wrote:
> Versions of packages libcurl3:i386 depends on:
> ii  libc6 2.19-18
> ii  libcomerr21.42.12-1.1
> ii  libgssapi-krb5-2  1.12.1+dfsg-19
> ii  libidn11  1.29-1+b2
> ii  libk5crypto3  1.12.1+dfsg-19
> ii  libkrb5-3 1.12.1+dfsg-19
> ii  libldap-2.4-2 2.4.40+dfsg-1
> ii  librtmp1  2:2.4~20150315.gita107cef9b-dmo1
> ii  libssh2-1 1.4.3-4.1
> ii  libssl1.0.0   1.0.2-1

libssl1.0.0 version 1.0.2-1 only ever existed in experimental and is now
outdated (replaced by 1.0.2a-1 in unstable). Your problem is the same as bug
#768476 [0] which is *not* a libcurl3 bug, and can be solved by updating the
libssl1.0.0 package to version 1.0.2a-1.

Cheers

[0] https://bugs,debian.org/768476


signature.asc
Description: Digital signature

Bug#786670: ffmpeg: too many dependencies?

[Alessandro Ghedini]

On lun, mag 25, 2015 at 01:46:47 +0200, Bálint Réczey wrote:
> Hi Alessandro,
> 
> 2015-05-24 12:50 GMT+02:00 Alessandro Ghedini :
> > Source: ffmpeg
> > Version: 7:2.6.3-1+b1
> > Severity: wishlist
> >
> > Hello,
> >
> > I was looking at the various dependencies of the -ffmpeg packages, and it 
> > seems
> > to me some of them are a bit superfluous. For example:
> >
> > - Do we really need 2 different MP3 encoders (libmp3lame and libshine)?
> > - Given the libmp3lame support, what's the purpose of libtwolame?
> > - What is the purpose of the libopenjpeg support given that ffmpeg has its
> >   own built-in JPEG2000 encoder/decoder?
> >
> > Other stuff seems a bit niche to me (e.g. the libzmq thing in libavfilter), 
> > but
> > I guess someone could find that useful.
> >
> > I mean, if people actually ask for these features then I see no problem, but
> > you might want to reduce the number of dependencies otherwise, to reduce the
> > attack surface of the ffmpeg packages.
> >
> > Any thought?
> As the maintainer of xbmc/kodi I prefer to ffmpeg to provide all
> codecs rather than having to handle ones implemented in other packages
> separately.

But why provide multiple implementations for the same formats? Also, if people
really need them they can be readded later.

Cheers


signature.asc
Description: Digital signature

Bug#786670: ffmpeg: too many dependencies?

[Alessandro Ghedini]

Source: ffmpeg
Version: 7:2.6.3-1+b1
Severity: wishlist

Hello,

I was looking at the various dependencies of the -ffmpeg packages, and it seems
to me some of them are a bit superfluous. For example:

- Do we really need 2 different MP3 encoders (libmp3lame and libshine)?
- Given the libmp3lame support, what's the purpose of libtwolame?
- What is the purpose of the libopenjpeg support given that ffmpeg has its
  own built-in JPEG2000 encoder/decoder?

Other stuff seems a bit niche to me (e.g. the libzmq thing in libavfilter), but
I guess someone could find that useful.

I mean, if people actually ask for these features then I see no problem, but
you might want to reduce the number of dependencies otherwise, to reduce the
attack surface of the ffmpeg packages.

Any thought?

Cheers

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.0.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


signature.asc
Description: Digital signature

Bug#786512: curl: fails on non-fatal TLS warning

[Alessandro Ghedini]

Control: tags -1 fixed-upstream

On Fri, May 22, 2015 at 10:29:16PM +1000, Dmitry Smirnov wrote:
> Package: curl
> Version: 7.42.1-2
> Severity: normal
> X-Debbugs-CC: arno.schnei...@hs-augsburg.de
> 
> Command
> 
> curl https://moodle.hs-augsburg.de/
> 
> returns the following error:
> 
> 
> curl: (51) gnutls_handshake() warning: The server name sent was not recognized
> 
> 
> Quick searching suggests that it might be a GNUTLS-related regression (it was 
> working properly on curl-7.38.0-4+deb8u2) similar to #731287 in "wget".
> 
> Worth noticing that command 
> 
> wget https://moodle.hs-augsburg.de/
> 
> emits the following warning but succeeds:
> 
> 
> GnuTLS: A TLS warning alert has been received.
> GnuTLS: received alert [112]: The server name sent was not recognized
> 
> 
> I found about this problem during attempt to monitor HTTPS-secured web site 
> in 
> Zabbix so apparently "libcurl4-gnutls" is also affected.

Yup, this issue has been fixed upstream a few days ago [0].

Cheers

[0] 
https://github.com/bagder/curl/commit/d5aab55b3353bec1d34a2e1434399d23db79b254


signature.asc
Description: Digital signature

Bug#786576: mpv: --vo=opengl-old:rectangle=1 fails to render OSD

[Alessandro Ghedini]

On sab, mag 23, 2015 at 03:02:17 +0300, Yuriy M. Kaminskiy wrote:
> Package: mpv
> Version: 0.6.2-2
> Severity: normal
> 
> Dear Maintainer,
> 
> mpv --vo=opengl-old fails to render OSD (draws empty rectangles instead)
> when sub-option rectangle is 1 (it is set to 1 by default on some
> video-cards [with mesa ATI r200 driver], otherwise can be enabled by
> --vo=opengl-old:rectangle=1).
> OSD rendering assumes GL_TEXTURE_2D was glEnable'd, while with this
> sub-option video rendering glEnable(GL_TEXTURE_RECTANGLE) (which has higher
> priority).
> Attached patch (tested, seems to work) mitigates this by temporarily
> switching texture targets when rendering OSD.
> 
> Notes:
> 1) This bug does not affect testing and upstream (--vo=opengl-old was
> completely removed since mpv-0.8), only jessie is affected;
> 2) --vo=opengl-old is not used by default, however, it was suggested by mpv
> for very old videocards that lacks OpenGL-2.0, and on some of such cards
> rectangle suboption is enabled by default.

Same as the other one, I don't think this issue is serious enough to warrant
a stable update, sorry. Can you use a different vo? (e.g. xv, x11 or sdl).

Cheers


signature.asc
Description: Digital signature

Bug#786572: mpv: always dies in assert() on --vo=opengl-old:force-pbo=yes

[Alessandro Ghedini]

On sab, mag 23, 2015 at 02:15:05 +0300, Yuriy M. Kaminskiy wrote:
> Package: mpv
> Version: 0.6.2-2
> Severity: normal
> 
> Dear Maintainer,
> 
> $ mpv --vo=opengl-old:force-pbo=yes any-video.avi
> [...]
> AO: [alsa] 48000Hz stereo 2ch float
> VO: [opengl-old] 1280x720 => 1280x720 yuv420p
> mpv: ../ta/ta.c:333: ta_dbg_check_header: Assertion `h->canary ==
> 0xD3ADB3EF' failed.
> $ gdb mpv core
> [...]
> Program terminated with signal SIGABRT, Aborted.
> (gdb) bt
> [...]
> #5  0xb75c6cf8 in ta_dbg_check_header (h=0xaf4f70cc) at ../ta/ta.c:333
> #6  0xb769d59e in ta_dbg_check_header (h=0xaf4f70cc) at ../ta/ta.c:269
> #7  get_header (ptr=0xaf4f70ec) at ../ta/ta.c:77
> #8  ta_free (ptr=0xaf4f70ec) at ../ta/ta.c:255
> #9  0xb768af19 in draw_image (vo=0xb81e2300, mpi=0xb8571730) at
> ../video/out/vo_opengl_old.c:2007
> #10 0xb7683582 in render_frame (vo=) at ../video/out/vo.c:581
> [...]
> 
> When force-pbo enabled, mpi == &mpi2, so it attempts to free variable on
> stack.
> Patch attached (tested, works).
> 
> Notes:
> 1) This bug does not affect testing and upstream (--vo=opengl-old was
> completely removed since mpv-0.8), only jessie is affected;
> 2) It can be only triggered by user with --vo=opengl-old:force-pbo=yes
> option;
> 3) It is expected to always die in assert, before triggering heap
> corruption, so there should be no security implications.

Given the above notes I don't think this issue warrants a stable update (I
don't think the release managers would allow one anyway), so there's not much
I can do about this.

Cheers


signature.asc
Description: Digital signature

Bug#785326: libavcodec56: CVE-2014-7937 - Multiple off-by-one errors in libavcodec/vorbisdec.c

[Alessandro Ghedini]

On Sat, May 16, 2015 at 03:43:37PM +0200, Alessandro Ghedini wrote:
> On Sat, May 16, 2015 at 03:07:57PM +0200, Sebastian Ramacher wrote:
> > On 2015-05-15 15:22:28, Alessandro Ghedini wrote:
> > > On Fri, May 15, 2015 at 11:05:17AM +0200, Sebastian Ramacher wrote:
> > > > Version: 6:11.3-1
> > > > 
> > > > On 2015-05-14 20:41:15, Arne Wichmann wrote:
> > > > > Package: libavcodec56
> > > > > Version: 6:11.3-2
> > > > > Severity: grave
> > > > > Tags: security
> > > > > Justification: user security hole
> > > > > 
> > > > > Hi, as far as I can see this has not yet been reported or fixed:
> > > > > 
> > > > > CVE-2014-7937 : Multiple off-by-one errors in libavcodec/vorbisdec.c 
> > > > > in
> > > > > FFmpeg before 2.4.2, as used in Google Chrome before 40.0.2214.91, 
> > > > > allow
> > > > > remote attackers to cause a denial of service (use-after-free) or 
> > > > > possibly
> > > > > have unspecified other impact via crafted Vorbis I data [1]
> > > > > 
> > > > > I marked this as grave as the impact is unclear and might include 
> > > > > arbitrary
> > > > > code execution. Feel free do downgrade if this can be ruled out.
> > > > > 
> > > > > (Actually I would like to have a look at the test case to check a bit 
> > > > > more
> > > > > thoroughly, but AFAICS I would need to talk to google for this.)
> > > > > 
> > > > > [1] https://security-tracker.debian.org/tracker/CVE-2014-7937
> > > > >   
> > > > > https://lists.libav.org/pipermail/libav-devel/2015-January/066433.html
> > > > 
> > > > A similar commit to the one maintained in this mailing list post was 
> > > > applied to
> > > > 11.3. So closing with that version.
> > > 
> > > Do you mean the patch at [0]? Honestly it doesn't look like the ffmpeg 
> > > patch at
> > > all, and the commit message doesn't even mention the bug fix. How can you 
> > > be so
> > > sure that the bug is fixed?
> > 
> > I might have read the commit wrong. Do you have a sample for this CVE?
> 
> Unfortunately the reproducer isn't public. I contacted ffmpeg-security about
> it, I'll keep you posted.

I got the reproducer from ffmpeg and it seems that libav in sid isn't affected
like Sebastian said. So yeah, this bug should stay closed. I don't know if the
patch linked above is what fixed the issue though.

Cheers


signature.asc
Description: Digital signature

Bug#785326: libavcodec56: CVE-2014-7937 - Multiple off-by-one errors in libavcodec/vorbisdec.c

[Alessandro Ghedini]

On Sat, May 16, 2015 at 03:07:57PM +0200, Sebastian Ramacher wrote:
> On 2015-05-15 15:22:28, Alessandro Ghedini wrote:
> > On Fri, May 15, 2015 at 11:05:17AM +0200, Sebastian Ramacher wrote:
> > > Version: 6:11.3-1
> > > 
> > > On 2015-05-14 20:41:15, Arne Wichmann wrote:
> > > > Package: libavcodec56
> > > > Version: 6:11.3-2
> > > > Severity: grave
> > > > Tags: security
> > > > Justification: user security hole
> > > > 
> > > > Hi, as far as I can see this has not yet been reported or fixed:
> > > > 
> > > > CVE-2014-7937 : Multiple off-by-one errors in libavcodec/vorbisdec.c in
> > > > FFmpeg before 2.4.2, as used in Google Chrome before 40.0.2214.91, allow
> > > > remote attackers to cause a denial of service (use-after-free) or 
> > > > possibly
> > > > have unspecified other impact via crafted Vorbis I data [1]
> > > > 
> > > > I marked this as grave as the impact is unclear and might include 
> > > > arbitrary
> > > > code execution. Feel free do downgrade if this can be ruled out.
> > > > 
> > > > (Actually I would like to have a look at the test case to check a bit 
> > > > more
> > > > thoroughly, but AFAICS I would need to talk to google for this.)
> > > > 
> > > > [1] https://security-tracker.debian.org/tracker/CVE-2014-7937
> > > >   https://lists.libav.org/pipermail/libav-devel/2015-January/066433.html
> > > 
> > > A similar commit to the one maintained in this mailing list post was 
> > > applied to
> > > 11.3. So closing with that version.
> > 
> > Do you mean the patch at [0]? Honestly it doesn't look like the ffmpeg 
> > patch at
> > all, and the commit message doesn't even mention the bug fix. How can you 
> > be so
> > sure that the bug is fixed?
> 
> I might have read the commit wrong. Do you have a sample for this CVE?

Unfortunately the reproducer isn't public. I contacted ffmpeg-security about
it, I'll keep you posted.

Cheers


signature.asc
Description: Digital signature

Bug#784666: nghttp2: new upstream release v0.7.13

[Alessandro Ghedini]

Control: retitle -1 nghttp2: new upstream release v1.0.0

On Thu, May 07, 2015 at 06:08:47PM +0200, Alessandro Ghedini wrote:
> Source: nghttp2
> Version: 0.6.7-1
> Severity: wishlist
> 
> Hello,
> 
> upstream has released several new upstream versions, would it be possible to
> update the Debian package?

It seems a new version has been released not long ago.

Anyway, to expand on my original report, I was looking to enable the HTTP/2
support in curl, which requires nghttp2. Unfortunately the current nghttp2
version in Debian doesn't work very well with some sites, and future curl
releases will probably require nghttp2 1.0.0 [0].

If needed I can help update the package.

Cheers

[0] https://github.com/bagder/curl/pull/271


signature.asc
Description: Digital signature

Bug#785326: libavcodec56: CVE-2014-7937 - Multiple off-by-one errors in libavcodec/vorbisdec.c

[Alessandro Ghedini]

On Fri, May 15, 2015 at 11:05:17AM +0200, Sebastian Ramacher wrote:
> Version: 6:11.3-1
> 
> On 2015-05-14 20:41:15, Arne Wichmann wrote:
> > Package: libavcodec56
> > Version: 6:11.3-2
> > Severity: grave
> > Tags: security
> > Justification: user security hole
> > 
> > Hi, as far as I can see this has not yet been reported or fixed:
> > 
> > CVE-2014-7937 : Multiple off-by-one errors in libavcodec/vorbisdec.c in
> > FFmpeg before 2.4.2, as used in Google Chrome before 40.0.2214.91, allow
> > remote attackers to cause a denial of service (use-after-free) or possibly
> > have unspecified other impact via crafted Vorbis I data [1]
> > 
> > I marked this as grave as the impact is unclear and might include arbitrary
> > code execution. Feel free do downgrade if this can be ruled out.
> > 
> > (Actually I would like to have a look at the test case to check a bit more
> > thoroughly, but AFAICS I would need to talk to google for this.)
> > 
> > [1] https://security-tracker.debian.org/tracker/CVE-2014-7937
> >   https://lists.libav.org/pipermail/libav-devel/2015-January/066433.html
> 
> A similar commit to the one maintained in this mailing list post was applied 
> to
> 11.3. So closing with that version.

Do you mean the patch at [0]? Honestly it doesn't look like the ffmpeg patch at
all, and the commit message doesn't even mention the bug fix. How can you be so
sure that the bug is fixed?

Cheers

[0] 
https://github.com/libav/libav/commit/0025f7408a0fab2cab4a950064e4784a67463994


signature.asc
Description: Digital signature

Bug#779201: kfreebsd-{8,9}: CVE-2015-1414: DoS via IGMP packet

[Alessandro Ghedini]

On Sun, May 10, 2015 at 09:12:43PM +0100, Steven Chamberlain wrote:
> Dear Security Team,
> 
> This bug was reopened because the original fix from upstream was found
> to be incomplete.
> 
> Please may I upload to wheezy-security with the attached debdiff,
> replacing the CVE-2015-1414 patch with the new one, and also patching
> CVE-2015-2923 (Debian Bug #782735).

Looks good, go ahead and upload.

Thanks


signature.asc
Description: Digital signature

Bug#784666: nghttp2: new upstream release v0.7.13

[Alessandro Ghedini]

Source: nghttp2
Version: 0.6.7-1
Severity: wishlist

Hello,

upstream has released several new upstream versions, would it be possible to
update the Debian package?

Thanks

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


signature.asc
Description: Digital signature

Bug#745837: curl should use a Certificate Revocation List by default

[Alessandro Ghedini]

Control: tags -1 wontfix

On mar, mag 05, 2015 at 01:23:46 +0200, Vincent Lefevre wrote:
> On 2015-05-04 19:57:25 +0200, Alessandro Ghedini wrote:
> > On lun, mag 04, 2015 at 12:28:02 +0200, Vincent Lefevre wrote:
> > > OK, if I understand, it just supports OCSP stapling, not plain OCSP.
> > > So, why not using plain OCSP if no OCSP stapling information is
> > > received?
> > 
> > Plain OCSP has several problems
> 
> This is FUD. The possible problems are very minor compared to other
> problems, in particular compared to the potential security probems.
> 
> > (increased latency,
> 
> Only for the first request to the server. So, in average, I doubt that
> this is noticeable. Adverts and images on web sites are much worse.

You seem to keep confusing libcurl for a web browser. It's not (unless you
decide for whatever reason to build one yourself on top of it). "Adverts and
images on web sites" are of no concern to curl developers (not to mention that
adverts would probably require their own additional OCSP requests...).

> > privacy concerns,
> 
> Well, at worse, the OCSP responder just gets the domain and the IP of
> the user, right?

At worse, major certificate authorities get The IP address of every user
connecting to most websites using TLS.

> There are similar privacy concerns with the DNS, and even worse with the ISP
> (which can get much more information on the user).

And? Just because there are other ways to fuck you over it doesn't mean it's ok
to add yet another one. Not to mention that it's much easier for, say, law
enforcement, to randomly fish for "criminals" by requesting information from a
few big  CAs, then do the same for every website and ISP.

> And with Google and Facebook too.

How does this have anything to do with OCSP?

> > and general unreliability)
> 
> Very rare. I've been using security.OCSP.require = true with Firefox
> for one year now

So? No one is going to make a decision based on what you, a single user out of
a few million ones, do.

Anyway, you forgot the part where the OCSP server is not responding because
someone is intercepting and blocking your OCSP requests. Or actively DDoSing
the OCSP server.

> > so there's little chance it will be implemented, let alone enabled
> > by default.
> 
> If curl were built against GnuTLS, it would have it automatically
> (like lynx and wget).

curl *is* built againt GnuTLS as of a couple of days ago, and no, this didn't
magically add support for OCSP as you seem to think.

GnuTLS (like most other TLS libraries) supports creating OCSP requests, but you
also need to send them (e.g. ocsptool in gnutls-bin implements its own HTTP
client) and then verify that the response is valid. None of this is automatic.

Also, how exactly do wget and lynx support OCSP? Because AFAICT they don't (they
don't even support OCSP stapling).

Cheers


signature.asc
Description: Digital signature

Bug#784267: mpv: please make the build reproducible

[Alessandro Ghedini]

Control: tags -1 pending

On Mon, May 04, 2015 at 07:53:23PM +0200, Jérémy Bobbio wrote:
> Source: mpv
> Version: 0.9.1-1
> Severity: wishlist
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: timestamps
> 
> Hi!
> 
> While working on the “reproducible builds” effort [1], we have noticed
> that foo could not be built reproducibly.
> 
> The attached patch disable recording the build date. Once applied,
> mpv can be built reproducibly in our current experimental framework.

I just merged your patch in the git repo, thanks.

Cheers


signature.asc
Description: Digital signature

Bug#745837: curl should use a Certificate Revocation List by default

[Alessandro Ghedini]

On lun, mag 04, 2015 at 12:28:02 +0200, Vincent Lefevre wrote:
> On 2015-05-04 10:57:36 +0200, Alessandro Ghedini wrote:
> > --cert-status only checks for the status_request TLS extension which is not
> > supported by most servers (which means curl will fail by default on most
> > requests). So no, curl will not enable the option by default, at least until
> > status_request catches on.
> 
> OK, if I understand, it just supports OCSP stapling, not plain OCSP.
> So, why not using plain OCSP if no OCSP stapling information is
> received?

Plain OCSP has several problems (increased latency, privacy concerns, and
general unreliability) so there's little chance it will be implemented, let
alone enabled by default.

CHeers


signature.asc
Description: Digital signature

Bug#745837: curl should use a Certificate Revocation List by default

[Alessandro Ghedini]

On Mon, May 04, 2015 at 03:15:19AM +0200, Vincent Lefevre wrote:
> Control: retitle -1 curl should check certificate revocation status by default
> 
> On 2014-04-26 13:19:35 +0200, Alessandro Ghedini wrote:
> > TL;DR: let's do OCSP instead of downloading CRLs. It would still
> > need someone to actually write the code though (ideally for all
> > OpenSSL, GnuTLS and NSS).
> 
> Well, I can see that curl now has a --cert-status option, which works:
> 
> xvii:~> curl --cert-status https://www.vinc17.net:4434/
> curl: (91) SSL certificate revocation reason: (UNKNOWN) (-1)
> 
> Without it, no errors. :(
> 
> But most users and scripts don't use it (because it is new and/or they
> don't know it?), thus are potentially vulnerable to MITM attack.
> 
> Checking the certificate revocation status should be done by default
> for security reasons, like what lynx and wget now do thanks to the new
> GnuTLS version.

--cert-status only checks for the status_request TLS extension which is not
supported by most servers (which means curl will fail by default on most
requests). So no, curl will not enable the option by default, at least until
status_request catches on.

Cheers


signature.asc
Description: Digital signature

Bug#784214: allow manual override for the regression DLA/DSA Id

[Alessandro Ghedini]

On Mon, May 04, 2015 at 09:09:04AM +0200, Mike Gabriel wrote:
> Package: security-tracker
> Severity: wishlist
> Tags: patch
> 
> Hi,
> 
> attached is a patch that adds manual DLA/DSA id override support if an
> upload tackles a regression already announce via an earlier DSA/DLA.
> 
> Current use case / example:
> 
>   xorg-server +deb6u1 (DLA-120-1) fixed CVE-2014-8092
>   xorg-server +deb6u2 (DLA-218-1) fixed some other CVE (irrelevant here)
>   xorg-server +deb6u3 (DLA-120-2) fixes CVE-2015-3418 (regression of
>fix for CVE-2014-8092)
> 
> At the moment: when using bin/genDLA like this:
> 
>   $ bin/gen-DLA  --save xorg-server regression CVE-2015-3418
> 
>  the script will create a follow-DLA for 218-1 (i.e., 218-2). Whereas
> the correct/wanted DLA id would be 120-2.
> 
> The attached patch allows one to specify the DLA id to follow up on with
> the "regression" keyword. Thus, with the patch applied, I can do this:
> 
>   $ bin/gen-DLA  --save xorg-server regression:120-1 CVE-2015-3418
> 
>  which then will provide me with a DLA-120-2 mail template and put
> the prepared upload of my xorg-server package into data/DLA/list.

You can just run:

   $ bin/gen-DLA  --save 120-2 xorg-server regression CVE-2015-3418

and it will create DLA-120-2 as you instruct the script to do.

Cheers


signature.asc
Description: Digital signature

Bug#784027: apt: broken "apt-get changelog" command

[Alessandro Ghedini]

On Sat, May 02, 2015 at 12:48:22PM +0200, Alessandro Ghedini wrote:
> Package: apt
> Version: 1.0.9.9
> Severity: normal
> 
> Hello,
> 
> it seems that the "changelog" command of apt-get is broken:
> 
> > % apt-get changelog debhelper
> > Err Changelog per debhelper 
> > (http://packages.debian.org/changelogs/pool/main/d/debhelper/debhelper_9.20150501/changelog)
> >   404  Not Found
> > Err Changelog per debhelper 
> > (http://httpredir.debian.org/debian/pool/main/d/debhelper/debhelper_9.20150501.changelog)
> >   404  Not Found [IP: 129.187.10.100 80]
> > E: changelog download failed
> 
> The changelog is now available at:
> 
>   
> http://metadata.ftp-master.debian.org/changelogs/main/d/debhelper/unstable_changelog

Don't know what happened, but it works again now. You may still want to change
the URL anyway, so I'm leaving this open.

Cheers


signature.asc
Description: Digital signature

Bug#783685: valgrind: False positive with openmp: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)

[Alessandro Ghedini]

Control: tags -1 pending

On mer, apr 29, 2015 at 09:56:51 +0200, Mathieu Malaterre wrote:
> Package: valgrind
> Version: 1:3.10.0-4
> Severity: normal
> 
> Dear Maintainer,
> 
> It feels like there is a missing suppression for openmp on valgring+openmp 
> (jessie amd64). Steps:
> 
> $ cat t.c
> int main()
> {
> }
> $ gcc -o t t.c -fopenmp
> $ valgrind --leak-check=full --show-leak-kinds=all ./t
> ==4125== Memcheck, a memory error detector
> ==4125== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==4125== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
> ==4125== Command: ./t
> ==4125== 
> ==4125== 
> ==4125== HEAP SUMMARY:
> ==4125== in use at exit: 8 bytes in 1 blocks
> ==4125==   total heap usage: 2 allocs, 1 frees, 32,824 bytes allocated
> ==4125== 
> ==4125== 8 bytes in 1 blocks are still reachable in loss record 1 of 1
> ==4125==at 0x4C28C20: malloc (vg_replace_malloc.c:296)
> ==4125==by 0x4E3B628: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
> ==4125==by 0x4E447C7: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
> ==4125==by 0x4E39D2C: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
> ==4125==by 0x400E9F9: call_init.part.0 (dl-init.c:78)
> ==4125==by 0x400EAE2: call_init (dl-init.c:36)
> ==4125==by 0x400EAE2: _dl_init (dl-init.c:126)
> ==4125==by 0x40011C9: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so)
> ==4125== 
> ==4125== LEAK SUMMARY:
> ==4125==definitely lost: 0 bytes in 0 blocks
> ==4125==indirectly lost: 0 bytes in 0 blocks
> ==4125==  possibly lost: 0 bytes in 0 blocks
> ==4125==still reachable: 8 bytes in 1 blocks
> ==4125== suppressed: 0 bytes in 0 blocks
> ==4125== 
> ==4125== For counts of detected and suppressed errors, rerun with: -v
> ==4125== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

I just added the following suppression to the debian.supp file:

{
  openmp with libgomp bug#783685
  Memcheck:Leak
  fun:malloc
  fun:gomp_malloc
  fun:gomp_init_num_threads
  fun:initialize_env
  fun:call_init.part.0
  fun:call_init
}

Thanks for reporting.

Cheers


signature.asc
Description: Digital signature

Bug#784027: apt: broken "apt-get changelog" command

[Alessandro Ghedini]

Package: apt
Version: 1.0.9.9
Severity: normal

Hello,

it seems that the "changelog" command of apt-get is broken:

> % apt-get changelog debhelper
> Err Changelog per debhelper 
> (http://packages.debian.org/changelogs/pool/main/d/debhelper/debhelper_9.20150501/changelog)
>   404  Not Found
> Err Changelog per debhelper 
> (http://httpredir.debian.org/debian/pool/main/d/debhelper/debhelper_9.20150501.changelog)
>   404  Not Found [IP: 129.187.10.100 80]
> E: changelog download failed

The changelog is now available at:

  
http://metadata.ftp-master.debian.org/changelogs/main/d/debhelper/unstable_changelog

Cheers

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apt depends on:
ii  debian-archive-keyring  2014.3
ii  gnupg   1.4.18-7
ii  libapt-pkg4.12  1.0.9.9
ii  libc6   2.19-18
ii  libgcc1 1:5.1.1-3
ii  libstdc++6  5.1.1-3

apt recommends no packages.

Versions of packages apt suggests:
pn  apt-doc  
pn  aptitude | synaptic | wajig  
ii  dpkg-dev 1.17.25
pn  python-apt   

-- no debconf information


signature.asc
Description: Digital signature