Bug#1018763: old conffiles not removed

[Stefan Bühler]

Package: rspamd
Version: 2.5-1

Hi,

lots of conffiles didn't get removed when upgrading from older
installations.

Candidates that should have been removed can be found with this:

  git log --full-history --diff-filter=DR --summary -- conf/

Those should either make it to debian/rspamd.maintscript as rm_conffile,
or perhaps remove-on-upgrade ... lines could be created in
debian/rspamd.conffiles [1] [2].

A few of those files actually got only renamed, but I think it's too
late now to mark them as moved.

You can use `adequate` to detect those obsolete conffiles on an affected
system:

  adequate --tags obsolete-conffile rspamd

I found this because rspamdadm complained with this message:

  ip_score module is deprecated in honor of reputation module!

cheers,
Stefan

[1] https://manpages.debian.org/testing/dpkg-dev/deb-conffiles.5.en.html
[2] https://manpages.debian.org/testing/debhelper/dh_installdeb.1.en.html

Bug#848945: grub-common: Empty rpool leaves ZFS systems unbootable

[Stefan Bühler]

Hi,

this bug is really annoying...

How about using this simple line instead?

LINUX_ROOT_DEVICE="ZFS=$(findmnt --direction backward --first-only --noheadings -o 
SOURCE /)"

"--direction backward" should find the "active mount" first (in case
there are multiple mounts on "/").

cheers,
Stefan

Bug#995242: isc-dhcp-server: omshell returns inconsistent results or segfaults

[Stefan Bühler]

Hi,

On Tue, 10 May 2022 10:13:11 +0200 Santiago Ruano =?iso-8859-1?Q?Rinc=F3n?= 
 wrote:

Control: forwarded -1 https://gitlab.isc.org/isc-projects/dhcp/-/issues/167

On Mon, 7 Mar 2022 14:41:23 -0800 Harris Enniss  wrote:
> We encountered this as well. It seems to be an issue with the way debian's
> fork is linked against system bind libraries (i.e. libiscexport-1105);
> segfaults disappear once we link them statically, as the isc sources do.

The latest release (4.4.3-1) removed that bind against bind system
libraries. Are you able to confirm this bug disappeared with it?


I observed this issue as well (context: foreman, dhcp only used to
deploy new systems, i.e. leases file usually empty).

omshell crashed in about 9 out of 10 times (in various stages) - can't
be that hard to reproduce.

Installing the testing package on stable sucks, because it wants libc6
from testing, so I "backported" it locally:

  sbuild -d bullseye-backports -c bullseye-amd64-sbuild --append-to-version='~bpo10+1' 
isc-dhcp_4.4.3-1.dsc -e 'me ' -m 'me '

Worked fine so far - omshell seems to be fixed.

cheers,
Stefan

Bug#996754: invalid debian/patches/series in 1.1.3-1 and bpo

[Stefan Bühler]

Package: ocserv
Version: 1.1.3-1

Dear maintainer,

you can't specify multiples patches on a single line; the logs show 
clearly only the first one gets applied.

debian/patches/series:
---
legacy_pidfile.patch
0005-pcl-removed-code-causing-use-after-free.patch 
0006-disable_system_calls-added-newfstatat-unconditionall.patch 
0010-seccomp-Add-epoll_pwait-to-allow-list.-AArch64-requi.patch
---

log:
---
...
dpkg-source: info: applying legacy_pidfile.patch
dpkg-source: info: applying 0005-pcl-removed-code-causing-use-after-free.patch
...
---

cheers,
Stefan

Bug#714726: wrong (as in: release-specific) "Suite:" entry in backports Release file

[Stefan Bühler]

Hi again,

small status update: it seems bookworm (now testing) backports was 
created correctly (yay \o/), but bullseye (now stable) wasn't fixed.

I still doubt release.txt contains the correct instructions to update 
bookworm-backports to suite stable-backports on bookworm release.

---
$ curl -s http://ftp.debian.org/debian/dists/buster-backports/Release | head -n4
Origin: Debian Backports
Label: Debian Backports
Suite: buster-backports
Codename: buster-backports

$ curl -s http://ftp.debian.org/debian/dists/bullseye-backports/Release | head 
-n4
Origin: Debian Backports
Label: Debian Backports
Suite: bullseye-backports
Codename: bullseye-backports

$ curl -s http://ftp.debian.org/debian/dists/bookworm-backports/Release | head 
-n4
Origin: Debian Backports
Label: Debian Backports
Suite: testing-backports
Codename: bookworm-backports
---

cheers,
Stefan

Bug#988310: ssl-cert: make-ssl-cert uses same filename for template and output

[Stefan Bühler]

Hi,

On Mon, 10 May 2021 11:09:58 +0200 Parodper  wrote:
> Package: ssl-cert
> Version: 1.1.0
> Severity: grave
> Tags: patch
> Justification: renders package unusable

Given ssl-cert is installed on many systems probably just for the
snakeoil self-signed certificate I think the severity isn't justified,
or at least the Justification is wrong.

"Only" creating other certificates seems to be impacted by this.  Is
there any data which packages are affected by this issue?

> The suggested patch shifts the arguments, like it is done on other parts of 
> the
> script.

The patch is not in "unified diff" format, which makes it hard to read /
apply in a safe way.

Apart from that it looks like a simple change though.

cheers,
Stefan

Bug#987967: jade replaced by pug for ages, doesn't work anymore

[Stefan Bühler]

Package: node-jade
Version: 1.11.0+~cs4.1.0-1
Severity: grave

Hi,

https://www.npmjs.com/package/jade says last release was 6 years ago and
it got replaced by pug.

Also it doesn't work anymore in bullseye for two reasons:

1. CLI tool broken due to "--name" conflicting with existing property:

---
Error: option 'name' clashes with existing property 'name' on Command
- call storeOptionsAsProperties(false) to store option values safely,
- or call storeOptionsAsProperties(true) to suppress this check,
- or change option name
---

2. It fails: parseMax got removed in character-parser:

https://github.com/ForbesLindesay/character-parser#parsemax

With this as test.jade:
---
div(class='test')
---

And renaming --name to --nameX in /usr/share/nodejs/jade/bin/jade.js it
fails like this:
---
$ jadejs test.jade

/usr/share/nodejs/jade/lib/runtime.js:240
  throw err;
  ^

TypeError: test.jade:1
  > 1| div(class='test')
2|

characterParser.parseMax is not a function
at Lexer.bracketExpression (/usr/share/nodejs/jade/lib/lexer.js:129:33)
at Lexer.attrs (/usr/share/nodejs/jade/lib/lexer.js:610:24)
at Lexer.next (/usr/share/nodejs/jade/lib/lexer.js:939:15)
at Lexer.lookahead (/usr/share/nodejs/jade/lib/lexer.js:113:46)
at Parser.lookahead (/usr/share/nodejs/jade/lib/parser.js:102:23)
at Parser.peek (/usr/share/nodejs/jade/lib/parser.js:79:17)
at Parser.tag (/usr/share/nodejs/jade/lib/parser.js:773:22)
at Parser.parseTag (/usr/share/nodejs/jade/lib/parser.js:759:17)
at Parser.parseExpr (/usr/share/nodejs/jade/lib/parser.js:211:21)
at Parser.parse (/usr/share/nodejs/jade/lib/parser.js:122:25) {
  path: 'test.jade'
}
---

This is also the reason why isso doesn't build anymore: see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959644 "isso: FTBFS:
TypeError: Jade:1"

cheers,
Stefan

Bug#714726: wrong (as in: release-specific) "Suite:" entry in backports Release file

[Stefan Bühler]

Hi,

it seems dak got improved [1] (or at least the release instructions), 
although no changes were made to the current releases afaict (not even 
testing/bullseye).

The instructions also don't include yet the part to update the 
suite_name on release - backports and (proposed-)updates are in a "MOVE 
STUFF AROUND:" section [2] that manipulates symlinks but doesn't 
actually update suite_name in the database (contrary to most suites [3] 
which are handled by a "rename-suite" function [4]).

The "rename-suite" won't work with broken suites - as its database 
updates are based on the previous "suite_name" value (which is the part 
that is broken right now afaict).

I hope this is going to work out somehow - and it is nice to see some 
progress was made :)

cheers,
Stefan

[1]: 
https://salsa.debian.org/ftp-team/dak/-/commit/bc0f26a328ff6f3a26ff0f04a6e51a8ac6cd5e7f
[2]: 
https://salsa.debian.org/ftp-team/dak/-/blob/8f090ecf549fcc8713af3e2a993fc52bcd66bc91/docs/release.txt#L117-136
[3]: 
https://salsa.debian.org/ftp-team/dak/-/blob/8f090ecf549fcc8713af3e2a993fc52bcd66bc91/docs/release.txt#L69-84
[4]: 
https://salsa.debian.org/ftp-team/dak/-/blob/8f090ecf549fcc8713af3e2a993fc52bcd66bc91/docs/release.txt#L15-42

On 20.06.19 14:06, Stefan Bühler wrote:
> Hi,
> 
> here we are again for the buster release cycle.
> 
> $ curl -s http://ftp.debian.org/debian/dists/buster-backports/Release | head 
> -n4
> Origin: Debian Backports
> Label: Debian Backports
> Suite: buster-backports
> Codename: buster-backports
> 
> $ curl -s http://ftp.debian.org/debian/dists/buster/Release | head -n4
> Origin: Debian
> Label: Debian
> Suite: testing
> Codename: buster
> 
> The Suite for buster-backports should be "testing-backports" right now 
> and become "stable-backports" when buster gets released.
> 
> cheers,
> Stefan
> 
> On 18.06.17 09:46, Stefan Bühler wrote:
>> Hi,
>>
>> On Tue, 6 Jun 2017 13:33:03 +0200 Stefan Bühler wrote:
>>> Hi,
>>>
>>> On Sun, 26 Apr 2015 22:01:03 +0200 Stefano Zacchiroli 
>>> wrote:
>>>> Heya,
>>>>
>>>> On Tue, Jul 02, 2013 at 10:30:40AM +0200, Stefano Zacchiroli wrote:
>>>>>   ./wheezy-backports/Release:Suite: wheezy-backports
>>>>>   ./wheezy-backports/Release:Codename: wheezy-backports
>>>>>
>>>>> as you can see from the last 2 lines, both Suite and Codename are set
>>>>> to "wheezy-backports" whereas, to be consistent with the rest, the
>>>>> suite should be something like "stable-backports".
>>>>
>>>> JFTR, it looks like this bug has been propagated to the just released
>>>> suite Jessie. Currently,
>>>> http://ftp.debian.org/debian/dists/jessie-backports/Release reads:
>>>>
>>>>   Suite: jessie-backports
>>>>   Codename: jessie-backports
>>>>
>>>> To cope with this, I've just hard-coded yet another release name in
>>>> sources.d.n configuration, to make sure that the new backports suite is
>>>> included.
>>>>
>>>> It would be nice to fix this now for jessie+1.
>>>
>>> Didn't work out so far, stretch is affected by this as well:
>>>
>>> $ curl -s http://ftp.debian.org/debian/dists/stretch-backports/Release
>>> Origin: Debian Backports
>>> Label: Debian Backports
>>> Suite: stretch-backports
>>> Codename: stretch-backports
>>> [...]
>>>
>>> Maybe this could still be fixed in time? I guess right now "Suite"
>>> should read "testing-backports", hoping it becomes "stable-backports" on
>>> release.
>>
>> Still broken after the stretch release.  Maybe this time just fix it
>> although it is already released (right now there is nothing in it yet
>> anyway)?
>>
>> As a workaround if someone wants to pin:
>>
>> Pin: release o=Debian Backports,a=stable-backports
>>
>> They should pin instead or additionally:
>>
>> Pin: release o=Debian Backports,n=stretch-backports
>>
>> Or (if you don't mix oldstable / stable backports sources):
>>
>> Pin: release o=Debian Backports
>>
>> Pinning a=stretch-backports ("a=" instead of "n="!) might work now, but
>> breaks if this bug gets fixed.
>>
>> cheers,
>> Stefan
>>

Bug#982844: two regressions in ocserv 1.1.2 regarding udp handling

[Stefan Bühler]

Package: ocserv
Version: 1.1.2-1~bpo10+1
Severity: important

Hi,

two bugs in the UDP handling (both leading to 100% CPU usage of a
worker) have been fixed upstream:

1. "Busyloop on unexpected incoming UDP packet"

If the handshake failed any unexpected UDP packet won't be read, leading
to epoll_wait always reparting EPOLLIN for it.  It will still be able to
handle the TCP connection though.

https://gitlab.com/openconnect/ocserv/-/issues/400
https://gitlab.com/openconnect/ocserv/-/merge_requests/253

2. "dtls connection setup: fix memory corruption, proper watcher setup"

There are two UDP "ev_io" watchers (introduced in 1.1.2) to handle a new
UDP session handshake without breaking the existing connection.

If a watcher gets reused (I'd guess in the 3rd UDP connection) it won't
stop it before clearing it, leaving a "dangling" reference in libev
internals.  Afaict it doesn't break anything apart from leading to an
infinite loop within libev - it won't handle any events at that point
anymore.

https://gitlab.com/openconnect/ocserv/-/merge_requests/255

When backporting those commits to 1.1.2 you'll have to replace
"worker_loop" with "loop" (got renamed).

I have built local packages with those two patches, and haven't seen
further issues so far.

cheers,
Stefan

Bug#982777: lighttpd: no restart of php-cgi children after php update

[Stefan Bühler]

Hi,

On 14.02.21 12:18, Christian Göttsche wrote:
> Package: lighttpd
> Version: 1.4.58-2
> 
> After a package upgrade of php the lighttpd spawned children of a
> fastcgi setup are not restarted.
> 
> In case of a security update of php, one would still run the vulnerable 
> version.
> 
> Please consider adding a trigger or the like to execute `service
> lighttpd reload` after a php package upgrade.

I strongly recommend using needrestart (which is very good at finding
systemd services that need to be restarted after binary / library
updates), which solves this problem in a very generic way.

Also I strongly recommend not having webservers run/spawn backends -
php-fpm is a way better alternative, and makes it quite easy to run a
backend as a different user than the webserver (which, if you do care
about security, you really should do).

Not sure whether such trigger is implementable if php doesn't have a
hook available for it anyway - and I doubt it is worth the effort.

cheers,
Stefan

Bug#980354: mailman3: should depend on python3-pymysql

[Stefan Bühler]

Hi,

On 18.01.21 04:25, Russell Coker wrote:
> Package: mailman3
> Version: 3.3.2-1
> Severity: normal
> 
> When you run mailman without python3-pymysql installed you get the following:
> Traceback (most recent call last):
> [...]
> ModuleNotFoundError: No module named 'pymysql'

I see:

Package: mailman3
Version: 3.2.2-1
Depends: ..., python3-psycopg2 | python3-pymysql, ...

and that should be good enough; I don't want the mysql packages on my
system as I'm using postgres.

Perhaps it could be added to the Recommends/Suggest section, but please
don't add it as a hard dependency.

cheers,
Stefan

Bug#966906: bird2: FTBFS: collect2: error: ld returned 1 exit status

[Stefan Bühler]

Hi Ondrej,

On Mon, 3 Aug 2020 10:00:07 +0200 Lucas Nussbaum  wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> > /usr/bin/ld: obj/sysdep/unix/main.o:././nest/route.h:461: multiple 
> > definition of `rta_dest_names'; 
> > obj/conf/cf-parse.tab.o:././nest/route.h:461: first defined here
> > LD -Wl,-z,relro -Wl,-z,now -g -O2 -fno-strict-aliasing -fno-strict-overflow 
> > -fPIC -Wl,-z,defs -Wl,--as-needed -pthread -o birdcl obj/client/commands.o 
> > obj/client/util.o obj/client/client.o obj/client/birdcl.o
> > LD -Wl,-z,relro -Wl,-z,now -g -O2 -fno-strict-aliasing -fno-strict-overflow 
> > -fPIC -Wl,-z,defs -Wl,--as-needed -pthread -o birdc obj/client/commands.o 
> > obj/client/util.o obj/client/client.o obj/client/birdc.o -lreadline -ltinfo
> > collect2: error: ld returned 1 exit status

this got fixed upstream in:

https://gitlab.nic.cz/labs/bird/-/commit/4bbc1061

With this patch bird2 compiles in my sbuild chroot.

Please also keep https://salsa.debian.org/debian/bird2 synchronized; it
is missing the 2.0.7-4 upload.

cheers,
Stefan

-- 
Stefan BühlerMail/xmpp: stefan.bueh...@tik.uni-stuttgart.de
Netze und Kommunikationssysteme der Universität Stuttgart (NKS)
https://www.tik.uni-stuttgart.de/Telefon: +49 711 685 60854

Bug#971583: New /var/log/tomcat9 permissions break logrotate

[Stefan Bühler]

Package: tomcat9
Version: 9.0.38-1~bpo10+1

Hi.

logrotate fails with:

logrotate[5006]: error: skipping "/var/log/tomcat9/catalina.out" because parent 
directory has insecure permissions (It's world writable or writable by group 
which is not "root") Set "su" directive in config file to tell logrotate which 
user/group should be used for rotation.

References:
- https://bugs.launchpad.net/ubuntu/+source/tomcat9/+bug/1861881
- 
https://salsa.debian.org/java-team/tomcat9/-/commit/51128fe9fb2d4d0b56be675d845cf92e4301a6c3

cheers,
Stefan

-- 
Stefan BühlerMail/xmpp: stefan.bueh...@tik.uni-stuttgart.de
Netze und Kommunikationssysteme der Universität Stuttgart (NKS)
https://www.tik.uni-stuttgart.de/Telefon: +49 711 685 60854

Bug#510368: libgamin0: libfam shlib dependency wrongly set to libfam0

[Stefan Bühler]

Hi,

On Thu, 1 Jan 2009 10:46:05 +0100 =?iso-8859-1?Q?Lo=EFc?= Minier 
 wrote:
> On Wed, Dec 31, 2008, Andres Mejia wrote:
> > The libfam shlib entry in libgamin0 is wrongly set to libfam0. Since 
> > libgamin 
> > is provided as a replacement for libfam, the entry should be set to 
> > libgamin0. This is a problem for packages that build depend on libgamin-dev 
> > since their dependency on libfam gets set to libfam0 instead of libgamin0.
> > 
> > A fix for this would be to simply set the entry as "libfam 0 libgamin0". 
> > Better yet, just delete the libgamin0.shlibs file from the debian directory 
> > and let the shlibs file be automatically generated.
> 
>  I think you misunderstood the current shlibs; the point is to allow
>  building against the FAM API and ABI and depend on libfam0 (provided by
>  libgamin0) if programs are linked to libfam.  This means you can
>  build-dep on fam or on gamin if you use the FAM API and this will
>  result on a dep on the FAM ABI and allow users to install either FAM or
>  Gamin as an implementation of the FAM ABI.  You can also use the Gamin
>  API and link to libgamin which will result in a dep on the Gamin ABI.
> 
>  What problem are you trying to solve?

This is an actual problem, as libfam0 doesn't provide the FAMNoExists 
symbol, but programs building against libgamin-dev might detect the 
symbol as available and use it.

So libfam0 can't properly provide "libfam.so*" from libgamin0, and 
shouldn't be allowed to by libgamin0.shlibs.

(As the gamin homepage says "The functions FAMSuspendMonitor(), 
FAMResumeMonitor() and FAMMonitorCollection() are not implemented." I 
think libgamin0 shouldn't have ever provided libfam0 either - it's 
basically broken in both directions.)

I think fixing libgamin0.shlibs and dropping fam from the archives is 
the smoothest path to fixing this mess.

Also see:
- https://salsa.debian.org/debian/lighttpd/-/merge_requests/18
- https://bugs.launchpad.net/bugs/1453463 [lighttpd] "undefined symbol: 
FAMNoExists"
- https://bugs.debian.org/966273 "RFA: fam -- File Alteration Monitor"
  (also: FAM upstream has been dead for some time)
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438330
  "Symbol `FamErrlist' has different size in shared object, consider re-linking"
  (this was just an annoying warning, not a real issue)
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438552
  "libgamin0: is Conflicts: libfam0 still necessary/valid?"
  (2007: perhaps libfam0 wasn't "provided" at the time?)

cheers,
Stefan

Bug#966273: RFA: fam -- File Alteration Monitor

[Stefan Bühler]

Hi,

On Sat, 25 Jul 2020 11:49:07 -0700 Chuan-kai Lin  wrote:
> Package: wnpp
> Severity: normal
> 
> I request an adopter for the fam package.
> 
> I can no longer invest sufficient time to maintain this package.
> Upstream had disappeared a long time ago, and gamin is a better
> maintained alternative.
> 
> The package description is:
>  FAM monitors files and directories, notifying interested applications
>  of changes.
>  .
>  This package provides a server that can monitor a given list of files
>  and notify applications through a socket.  If the kernel supports
>  dnotify (kernels >= 2.4.x) FAM is notified directly by the kernel.
>  Otherwise it has to poll the files' status.  FAM can also provide an
>  RPC service for monitoring remote files (such as on a mounted NFS
>  filesystem).

Is there any reason to keep FAM around any longer in your opinion, given
upstream is dead and there is gamin?

Or, in other words, why didn't you file a package removal request?

Imho providing a package that runs a (even if just local) service as
root doesn't combine well with a dead upstream with regards to security.

I see the following reverse dependencies in aptitude:

fam: (recommends) gnubiff

libfam0: (depends)
 courier-base
 courier-imap
 doodled
 gnubiff
 libkf5coreaddons5
 lighttpd
 omake
 sqwebmail

Is any of these known to actually need fam instead of gamin? (For
lighttpd I happen to know it is probably the other way round:
https://salsa.debian.org/debian/lighttpd/-/merge_requests/18)

cheers,
Stefan

Bug#961712: vsftpd package can't be installed when ipv6 is disabled

[Stefan Bühler]

Hi,

On Thu, 28 May 2020 11:26:09 +0200 Jean-Jacques Brucker
 wrote:
> Source: vsftpd
> Severity: critical
> Tags: ipv6
> Justification: breaks the whole system
> 
> Dear Maintainer,
> 
>  In some case (eg. embeded devices or private network), it sounds good to 
> desactivate ipv6.
> 
>  But when ipv6 is desactivated, for exemple with "ipv6.disable=1" into the 
> GRUB_CMDLINE_LINUX,
>  the vsftpd package can't be use, but also can't be installed, or reinstalled,
>  since installation fail when postinst fail to start vsftpd service.

It is a widespread and imho completely acceptable solution to support
IPv6 by binding to [::] (which usually binds both IPv4 and IPv6), and to
do this by default.

If you decide to brick your local IPv6, it is up to you to fix the
config files of all the network daemons. (In this case simply enable
"listen" instead of "listen_ipv6" in the config.)

If you can't figure this out: don't disable IPv6 (or perhaps try to only
disable IPv6 addresses on your network adapters instead of killing the
address family).

You already should have noticed when installing vsftpd that you need to
fix this, so it is your fault the package management is in a bad state.

>  Fail during package install/upgrade is critical because it may leave the 
> system in a brocken
>  state (cf. "apt-get check").

If you think postinst failures breaking "apt-get check" are such a big
problem I suggest you file a bug with apt. Or with debhelper. This
certainly isn't a vsftpd-only issue.  Lots of post-inst scripts break if
the config files are broken.

>  To at least decrease the severity of the bug, a workaround could be to NOT 
> start or restart
>  vsftpd service during install or upgrade, or maybe better : to check ipv6 
> (somewhere in /proc)
>  before to start or restart service in postinst.

It is ridiculous to ask your completely non-standard setup to be
supported out of the box. (Also I doubt such changes would ever get
backported to stable, much less oldstable.)

Also your chosen severity level led to this:
> Version 3.0.3-12 of vsftpd is marked for autoremoval from testing on
> Fri 26 Jun 2020.
which is completely unreasonable.

I'm going to degrade the severity to normal; although if I were the
maintainer I'd probably go for "wishlist" and close it with a "wontfix" tag.

regards,
Stefan

Bug#955532: Deprecation warning in Ruby 2.7: URI.escape is obsolete

[Stefan Bühler]

Hi,

On Thu, 2 Apr 2020 01:02:46 -0400 =?UTF-8?Q?Louis-Philippe_V=c3=a9ronneau?= 
 wrote:> Package: puppet
> Version: 5.5.19-1
> Severity: wishlist
> 
> Hi,
> 
> Running a fresh sid install with ruby 2.7, I get a few deprecation
> warnings, but mostly this one:
> 
> /usr/lib/ruby/vendor_ruby/puppet/util.rb:461: warning: URI.escape is obsolete

there are also these warnings (getting quite a lot of them too):

/usr/lib/ruby/vendor_ruby/puppet/file_system/file_impl.rb:80: warning: Using 
the last argument as keyword parameters is deprecated
/usr/lib/ruby/vendor_ruby/puppet/util.rb:315: warning: deprecated Object#=~ is 
called on Puppet::Transaction::Report; it always returns nil
/usr/lib/ruby/vendor_ruby/puppet/file_system/uniquefile.rb:126: warning: $SAFE 
will become a normal global variable in Ruby 3.0
/usr/lib/ruby/vendor_ruby/puppet/indirector/request.rb:283: warning: 
URI.unescape is obsolete

They all get silenced by
https://salsa.debian.org/puppet-team/puppet/-/merge_requests/2/diffs - 
thanks for that.

cheers,
Stefan

Bug#940264: vpnc-scripts: vpnc-script ignores netmask in VPN-provided routes

[Stefan Bühler]

Hi,

On Sat, 14 Sep 2019 23:00:42 +0300 Dmitry Semyonov  wrote:
> Package: vpnc-scripts
> Version: 0.1~git20190117-1
> Severity: normal
> 
> Dear Maintainer,
> 
> When VPN server (Cisco in my case) provides a list of sub-nets that should not
> be routed through VPN, the script creates a bunch of corresponding routes but
> omits the provided netmasks, thus effectively ignoring the feature. Moreover,
> on termination of VPN connection the script is not able to properly remove
> created routes because they use invalid netmask (/32 by default).
> 
> I traced the problem down to the 'route add' command executed inside
> set_exclude_route(). The following hack fixes the issue for me:
> 
> cmd="$IPROUTE route add `$IPROUTE route get "$NETWORK/$NETMASKLEN"
> | fix_ip_get_output`"
> cmd=`echo $cmd | sed -e 's@ via @'"/$NETMASKLEN via @"` # add proper 
> netmask
> $cmd
> 
> (A similar change is needed for set_ipv6_exclude_route() if you use IPv6.)

This has been fixed upstream:
- 
http://git.infradead.org/users/dwmw2/vpnc-scripts.git/commitdiff/fe5cb8a6d9791aa5217db31825b66eb185066a8d
- cleanup: 
http://git.infradead.org/users/dwmw2/vpnc-scripts.git/commitdiff/0851a20770d875d5b6cb76ec49b3137f56410f9a

Any chance this could end up in a stable update?

cheers,
Stefan

Bug#954285: Updating prometheus-node-exporter to bullseye leaves dangling symlinks

[Stefan Bühler]

Package: prometheus-node-exporter
Version: 0.18.1+ds-2

Hi,

after updating prometheus-node-exporter I get these dangling symlinks:

lrwxrwxrwx 1 root root 54 Jul 31  2019 
/etc/systemd/system/timers.target.wants/prometheus-node-exporter-apt.timer -> 
/lib/systemd/system/prometheus-node-exporter-apt.timer
lrwxrwxrwx 1 root root 66 Jul 31  2019 
/etc/systemd/system/timers.target.wants/prometheus-node-exporter-ipmitool-sensor.timer
 -> /lib/systemd/system/prometheus-node-exporter-ipmitool-sensor.timer
lrwxrwxrwx 1 root root 68 Jul 31  2019 
/etc/systemd/system/timers.target.wants/prometheus-node-exporter-mellanox-hca-temp.timer
 -> /lib/systemd/system/prometheus-node-exporter-mellanox-hca-temp.timer
lrwxrwxrwx 1 root root 59 Jul 31  2019 
/etc/systemd/system/timers.target.wants/prometheus-node-exporter-smartmon.timer 
-> /lib/systemd/system/prometheus-node-exporter-smartmon.timer

Maybe you can somehow "properly" remove the systemd unit files in a way 
that also disables them first?

cheers,
Stefan

Bug#928714: bird6 next hop keep not forwarded to bgp neighbor

[Stefan Bühler]

Hi,

On Thu, 09 May 2019 12:42:15 +0200 Diego Arroyo 
wrote:
> Package: bird
> Version: 1.6.3-2
> Version: 1.6.5-1
> Version: 1.6.6-1
> Severity: normal
> 
> Dear Maintainer,
> 
> In a working environment with bgp and ipv4 I am configuring bgp for ipv6 
> with similar configuration, but I cannot forward next hop.
> I have tested on debian stable with bird 1.6.3-2 and on lab with debian 
> buster and versions from buster (1.6.5-1) and sid (1.6.6-1)
> 
> Setup consists on 4 routers: 1 and 2 announce network to 3 and 4, that 
> are provider-edge to made network public available.
> Routers 1 and 2 use own ip for bgp protocol, but they also have a 
> virtual IP for the network announce in order to have faster transition 
> in case of one of our routers fail when it is not possible to have BFD 
> (that is the reason of use "next hop keep" in this environment)
> 
> For IPv4 all works as expected and provider-edge routers learn announced 
> network with next hop virtual ip, but for IPv6 only learns each node 
> self IP independent of the configuration: none, next hop self or next 
> hop keep.
> 
> I have replicated environment on lab to have access to all 4 routers and 
> check if it could be a problem between bird to cisco communication (real 
> setup provider-edge routers are cisco), but the problem happens also 
> having all 4 routers with bird.
> 
> Also, Routers 1 and 2 belongs to one AS, and 3 and 4 belongs to a second 
> AS.

I added "missing lladdr ignore;" to my bgp protocols, and this seemed to
fix it.

My scenario is an originator, a "reflector" (connected via iBGP to the
originator), and the cisco device (connected via eBGP to the "reflector").

For IPv6 the nexthop contains two addresses; the second is the link-local.

The main problem seems that when bird6 imports the route the nexthop
"link-local" is set to zero; but (the next) bird6 doesn't like
forwarding those, and will set itself as nexthop (both global and
link-local).

The statement above makes it keep a zero link-local and not touch the
main nexthop in such cases; it seems to be needed on the "receiving"
protocol on the reflector (didn't try reproducing it carefully though;
just putting it everywhere solved it).

cheers,
Stefan

Bug#945920: Random Chromium crashes

[Stefan Bühler]

Hi,

On Fri, 27 Dec 2019 15:31:13 +0100 Jaap Joris Vens  wrote:
> On Fri, Dec 27, 2019 at 01:29:13PM +0100, Stefan Bühler wrote:
> >Hi,
> >
> >yes, you are right, my patch only fixes the task manager crash.
> >
> >I now took a look at all backtraces, and all apart the first one
> >(probably older version?) seem to be the same "other" instance:
> >
> --- 8< ---
> 
> I am not quite following the intricacies of this crash anymore, but might
> this be something that we will need to report upstream?

Yes, that is how it looks to me (although I didn't take a look at the
debian patches and whether they have any impact on this). I don't quite
understand under which circumstances the MemoryInstrumentation
"singleton" instance is supposed to exist; but more importantly I
couldn't see any relation between the conditions when it gets created
and when it gets used.

Which imho means all uses need to check whether the instance actually
exists, or creating it automatically whenever it is requested.

Apart from that the singleton pointer is managed in a very dangerous
manner; the destructor will reset the singleton pointer, which makes it
look like that is supposed to do something meaningful, but in a
multi-threaded environment this simply can't go well imho; this probably
should use shared ownership and locking, or `call_once` and never
destroying it ever (and maybe calling abort in the destructor...).

cheers,
Stefan

Bug#945920: Random Chromium crashes

[Stefan Bühler]

Hi,

yes, you are right, my patch only fixes the task manager crash.

I now took a look at all backtraces, and all apart the first one 
(probably older version?) seem to be the same "other" instance:

---
#0  0x5a77cee7 in 
memory_instrumentation::MemoryInstrumentation::RequestGlobalDump(std::vector, std::allocator >, 
std::allocator, 
std::allocator > > > const&, base::OnceCallback >)>) ()
#1  0x58f8ddb0 in 
ProcessMemoryMetricsEmitter::FetchAndEmitProcessMemoryMetrics() ()
#2  0x58f85e82 in (anonymous namespace)::RecordMemoryMetrics() ()
#3  0x593b5165 in base::TaskAnnotator::RunTask(char const*, 
base::PendingTask*) ()
---

The underlying issue is the same: it crashes when dereferencing `this` 
(as it is NULL).

It gets started in `RecordMemoryMetricsAfterDelay`:

https://github.com/chromium/chromium/blob/07653652c58cc019af7f833bd63eb0c2eceaab5e/chrome/browser/metrics/chrome_browser_main_extra_parts_metrics.cc#L72-L90

The "time to live" (until the first actual call) is determined in 
`GetDelayForNextMemoryLog`:

https://github.com/chromium/chromium/blob/07653652c58cc019af7f833bd63eb0c2eceaab5e/services/resource_coordinator/public/cpp/memory_instrumentation/browser_metrics.cc#L52-L61

And `FetchAndEmitProcessMemoryMetrics` doesn't check the `GetInstance()` 
result either:

https://github.com/chromium/chromium/blob/07653652c58cc019af7f833bd63eb0c2eceaab5e/chrome/browser/metrics/process_memory_metrics_emitter.cc#L636-L642

I'm not quite sure about the consequences, for now I tried skipping 
`RecordMemoryMetrics` completely - we'll see how that goes..

So as additional patch I replaced 0x55 (`push %rbp`) at offset 
0x03a31e50 (start of `RecordMemoryMetrics`) with 0xc3 (`retq`):

$ xxd -s 0x3a31e50 -l 16 /usr/lib/chromium/chromium
03a31e50: 55bf 4000  4889 e541 5453 e8cf dd49  u...@...h..ats...I
$ printf '03a31e50: c3\n' | xxd -r -  /usr/lib/chromium/chromium
$ sha1sum /usr/lib/chromium/chromium* 
fbfb255a77f38b629c19eabddff577a1b26f4395  /usr/lib/chromium/chromium
5056c781602f4bbd41f06b3bd1940b6edbd7dc8c  /usr/lib/chromium/chromium-pre-patch

cheers,
Stefan

Bug#945920: Chromium segfaults - analysis and binary hotfix

[Stefan Bühler]

Hi.

Thanks for the hint with reproducing it via the Task Manager, makes 
debugging a lot easier :)

So the problem is `task_manager::TaskManagerImpl::Refresh()` calling
`memory_instrumentation::MemoryInstrumentation::GetInstance()` and using the
returned pointer without checking it; but is is `NULL`; this is what the
segfault in
`memory_instrumentation::MemoryInstrumentation::RequestPrivateMemoryFootprint()`
(0x55...f87; dereferencing `this` from register `rdi`) is about.

(gdb) frame 1
(gdb) disassemble /r
Dump of assembler code for function 
_ZN12task_manager15TaskManagerImpl7RefreshEv:
...
   0x591ba757 <+39>:41 80 bd 99 01 00 00 00 cmpb   $0x0,0x199(%r13)
   0x591ba75f <+47>:0f 84 7b 02 00 00   je 0x591ba9e0 
<_ZN12task_manager15TaskManagerImpl7RefreshEv+688>
   0x591ba765 <+53>:a8 80   test   $0x80,%al
   0x591ba767 <+55>:0f 85 b3 01 00 00   jne0x591ba920 
<_ZN12task_manager15TaskManagerImpl7RefreshEv+496>
...
(gdb) info proc mappings
...
  Start Addr   End Addr   Size Offset objfile
  0x4000 0x6035b000  0xae070000x0 
/usr/lib/chromium/chromium
  0x6035b000 0x60922000   0x5c7000  0xae06000 
/usr/lib/chromium/chromium
  0x60922000 0x6098b0000x69000  0xb3cd000 
/usr/lib/chromium/chromium

So for a hotfix I changed the `je` at `+47` into `jne`; this negates
the check for `!waiting_for_memory_dump_` in
https://github.com/chromium/chromium/blob/master/chrome/browser/task_manager/sampling/task_manager_impl.cc#L603
and should make it never use that block.

The offset of `0f 84` in the file is:
0x591ba75f - 0x4000 = 0x3C6675F

To patch it to `0f 85`:

$ cp -a /usr/lib/chromium/chromium /usr/lib/chromium/chromium-pre-patched
$ printf '3C66760: 85\n' | xxd -r -  /usr/lib/chromium/chromium
$ sha1sum /usr/lib/chromium/chromium*
036f623e158cffaa91be63df307bb2eda4d359e1  /usr/lib/chromium/chromium
5056c781602f4bbd41f06b3bd1940b6edbd7dc8c  /usr/lib/chromium/chromium-pre-patched

cheers,
Stefan

Bug#946143: cfg80211: double-free after changing network namespace

[Stefan Bühler]

Package: linux-signed-amd64
Version: 4.19.67+2+deb10u1
Tags: patch
Forwarded: https://patchwork.kernel.org/patch/11261855/

Hi,

I already reported this upstream, but didn't get much of a response yet,
see:

https://patchwork.kernel.org/patch/11261855/

We've been running the attached patch on 4.19.67 (rebuilt debian kernel
source with KASAN and the patch) for about a week now without crashes on
a few boxes.

It would save me a lot of time and effort if this would be included in
debian :)

cheers,
Stefan

-- 
Stefan BühlerMail/xmpp: stefan.bueh...@tik.uni-stuttgart.de
Netze und Kommunikationssysteme der Universität Stuttgart (NKS)
https://www.tik.uni-stuttgart.de/Telefon: +49 711 685 60854
From e34c3d99095cadb7f764cdc497de57a7fc44cf55 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20B=C3=BChler?= 
Date: Tue, 26 Nov 2019 10:25:31 +0100
Subject: [PATCH 1/1] cfg80211: fix double-free after changing network
 namespace (backport for 4.19.87)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

If wdev->wext.keys was initialized it didn't get reset to NULL on
unregister (and it doesn't get set in cfg80211_init_wdev either), but
wdev is reused if unregister was triggered through
cfg80211_switch_netns.

The next unregister (for whatever reason) will try to free
wdev->wext.keys again.

X-Ref: https://patchwork.kernel.org/patch/11261855/
Signed-off-by: Stefan Bühler 
---
 net/wireless/core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/wireless/core.c b/net/wireless/core.c
index 68660781aa51..e556965220b7 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -1310,6 +1310,7 @@ static int cfg80211_netdev_notifier_call(struct notifier_block *nb,
 			cfg80211_mlme_purge_registrations(wdev);
 #ifdef CONFIG_CFG80211_WEXT
 			kzfree(wdev->wext.keys);
+			wdev->wext.keys = NULL;
 #endif
 			flush_work(>disconnect_wk);
 			cfg80211_cqm_config_free(wdev);
-- 
2.24.0

Bug#932054: rspamd "phones home" by default

[Stefan Bühler]

Package: rspamd
Version: 1.9.4-2

Hi,

I see various connections from my system to 88.99.142.95 (the rspamd 
home).

The https ones seem to be targeted at "maps.rspamd.com", which are used 
by the default config to download various "map" files.

I'd feel safer if an independent cronjob would handle those (and maybe 
even disable it by default), or maybe deploy through a separate package? 
(No idea how often those are updated.)

Then there are UDP connections to port 11335, which probably comes from:

servers = "round-robin:fuzzy1.rspamd.com:11335,fuzzy2.rspamd.com:11335";

in /etc/rspamd/modules.d/fuzzy_check.conf.

This module should imho be disabled by default, especially given there 
is a "usage policy" connected to it:

https://rspamd.com/doc/usage_policy.html

cheers,
Stefan

Bug#714726: wrong (as in: release-specific) "Suite:" entry in backports Release file

[Stefan Bühler]

Hi,

here we are again for the buster release cycle.

$ curl -s http://ftp.debian.org/debian/dists/buster-backports/Release | head -n4
Origin: Debian Backports
Label: Debian Backports
Suite: buster-backports
Codename: buster-backports

$ curl -s http://ftp.debian.org/debian/dists/buster/Release | head -n4
Origin: Debian
Label: Debian
Suite: testing
Codename: buster

The Suite for buster-backports should be "testing-backports" right now 
and become "stable-backports" when buster gets released.

cheers,
Stefan

On 18.06.17 09:46, Stefan Bühler wrote:
> Hi,
> 
> On Tue, 6 Jun 2017 13:33:03 +0200 Stefan Bühler wrote:
>> Hi,
>>
>> On Sun, 26 Apr 2015 22:01:03 +0200 Stefano Zacchiroli 
>> wrote:
>>> Heya,
>>>
>>> On Tue, Jul 02, 2013 at 10:30:40AM +0200, Stefano Zacchiroli wrote:
>>>>   ./wheezy-backports/Release:Suite: wheezy-backports
>>>>   ./wheezy-backports/Release:Codename: wheezy-backports
>>>>
>>>> as you can see from the last 2 lines, both Suite and Codename are set
>>>> to "wheezy-backports" whereas, to be consistent with the rest, the
>>>> suite should be something like "stable-backports".
>>>
>>> JFTR, it looks like this bug has been propagated to the just released
>>> suite Jessie. Currently,
>>> http://ftp.debian.org/debian/dists/jessie-backports/Release reads:
>>>
>>>   Suite: jessie-backports
>>>   Codename: jessie-backports
>>>
>>> To cope with this, I've just hard-coded yet another release name in
>>> sources.d.n configuration, to make sure that the new backports suite is
>>> included.
>>>
>>> It would be nice to fix this now for jessie+1.
>>
>> Didn't work out so far, stretch is affected by this as well:
>>
>> $ curl -s http://ftp.debian.org/debian/dists/stretch-backports/Release
>> Origin: Debian Backports
>> Label: Debian Backports
>> Suite: stretch-backports
>> Codename: stretch-backports
>> [...]
>>
>> Maybe this could still be fixed in time? I guess right now "Suite"
>> should read "testing-backports", hoping it becomes "stable-backports" on
>> release.
> 
> Still broken after the stretch release.  Maybe this time just fix it
> although it is already released (right now there is nothing in it yet
> anyway)?
> 
> As a workaround if someone wants to pin:
> 
> Pin: release o=Debian Backports,a=stable-backports
> 
> They should pin instead or additionally:
> 
> Pin: release o=Debian Backports,n=stretch-backports
> 
> Or (if you don't mix oldstable / stable backports sources):
> 
> Pin: release o=Debian Backports
> 
> Pinning a=stretch-backports ("a=" instead of "n="!) might work now, but
> breaks if this bug gets fixed.
> 
> cheers,
> Stefan
> 

Bug#929608: pmciscoios parser module not enabled

[Stefan Bühler]

Hi,

On 5/28/19 4:32 PM, Michael Biebl wrote:
> On 27.05.19 10:26, Stefan Bühler wrote:
>> Package: rsyslog
>>
>> Hi,
>>
>> please enable the pmciscoios parser module.
> 
> Can you provide a bit more feedback where and why you want to use this
> module?

This is going to be a surprise: I need to parse syslog messages from 
cisco devices, and they look bad using the standard parser (which, again 
surprise, is probably the reason someone bothered to write a custom 
one).

> Rainer, what's your take on this module? Is it properly maintained? Do
> you recommend to enable it?

I'd like to point out that the online documentation does list 
'pmciscoios' but not 'pmcisconames':
https://www.rsyslog.com/doc/v8-stable/configuration/modules/idx_parser.html

Also I'm having a really bad user experience because you didn't enable 
modules that don't even need further dependencies just because no user 
asked for it yet (and provided a justification for it).  Which means it 
will take years until I can use it in debian stable.

May I suggest (to both of you) reading:
https://michael.stapelberg.ch/posts/2019-05-23-optional-dependencies/
(found via: https://planet.debian.org/)

cheers,
Stefan

-- 
Stefan BühlerMail/xmpp: stefan.bueh...@tik.uni-stuttgart.de
Netze und Kommunikationssysteme der Universität Stuttgart (NKS)
https://www.tik.uni-stuttgart.de/Telefon: +49 711 685 60854

Bug#929608: pmciscoios parser module not enabled

[Stefan Bühler]

Package: rsyslog

Hi,

please enable the pmciscoios parser module.

cheers,
Stefan

-- 
Stefan BühlerMail/xmpp: stefan.bueh...@tik.uni-stuttgart.de
Netze und Kommunikationssysteme der Universität Stuttgart (NKS)
https://www.tik.uni-stuttgart.de/Telefon: +49 711 685 60854

Bug#924005: client certificate verification regression with puppetdb

[Stefan Bühler]

Package: jetty9
Version: 9.4.15-1
Severity: important

Hi.

The update (libjetty9-java and libjetty9-extra-java) to 9.4.15-1 broke 
our puppetdb setup; a downgrade to 9.4.14-1 fixes the issue.

I can't see any (new/useful/related) error message in the puppetdb log.

The error message from our puppetmaster is:

Error connecting to puppet-db.XXX on 8081 at route /pdb/cmd/v1?..., error 
message received was 'SSL_connect returned=1 errno=0 state=error: sslv3 alert 
certificate unknown'. Failing over to the next PuppetDB server_url in the 
'server_urls' list

openssl s_client -quiet ... shows:
---
depth=1 CN = Puppet CA: puppetmaster.XXX
verify return:1
depth=0 CN = puppet-db.XXX
verify return:1
139863914905664:error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert 
certificate unknown:../ssl/record/rec_layer_s3.c:1407:SSL alert number 46
---

(The same s_client call works with a jetty downgrade to 9.4.14-1, so the 
client certificate arguments should be good.)

---
Installed jetty and puppet packages:
ii  libjetty9-extra-java  9.4.15-1 all  Java 
servlet engine and webserver -- extra libraries
ii  libjetty9-java9.4.15-1 all  Java 
servlet engine and webserver -- core libraries
ii  libtrapperkeeper-webserver-jetty9-clojure 1.7.0-2  all  
trapperkeeper webserver service
ii  libpuppetlabs-http-client-clojure 0.9.0-1  all  Clojure 
wrapper around libhttpasyncclient-java
ii  libpuppetlabs-i18n-clojure0.8.0-1  all  Clojure 
i18n library
ii  libpuppetlabs-ring-middleware-clojure 1.0.0-2  all  common 
Ring middleware for Puppet projects
ii  puppet5.5.10-1 all  
configuration management system
ii  puppetdb  6.2.0-3  all  Puppet 
data warehouse
---

cheers,
Stefan

-- 
Stefan BühlerMail/xmpp: stefan.bueh...@tik.uni-stuttgart.de
Netze und Kommunikationssysteme der Universität Stuttgart (NKS)
https://www.tik.uni-stuttgart.de/Telefon: +49 711 685 60854

Bug#917347: Obsolete build dependency on libssl1.0-dev

[Stefan Bühler]

Hi,

On 12/26/18 1:01 PM, Moritz Muehlenhoff wrote:
> Source: lighttpd
> Severity: normal
> 
> Your package uses "libssl-dev | libssl1.0-dev" as a build dependency
> on OpenSSL. openssl1.0 is scheduled for removal, the alternate build
> dependency can now be removed.

Please keep in mind that some of the alternate build dependencies are
needed for building on oldstable and stable; we'd like to keep the
upstream package as close as possible to the debian one, and we are
building for older dists too.

That said it actually looks like libssl-dev is available for oldstable
and stable too.

cheers,
Stefan

Bug#913742: ip6tables-save produces broken syntax, unable to load them

[Stefan Bühler]

Package: iptables
Version: 1.8.1-2
Severity: grave
Tags: security

Reproduce with:

# ip6tables -A INPUT ! -s ::1
# ip6tables-save  | ip6tables-restore
Bad argument `!-s'
Error occurred at line: 6
Try `ip6tables-restore -h' or 'ip6tables-restore --help' for more information.

# ip6tables-save  
# Generated by xtables-save v1.8.1 on Wed Nov 14 16:42:42 2018
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT  !-s ::1/128 
COMMIT
# Completed on Wed Nov 14 16:42:42 2018

It should export "! -s", i.e. one space after "!", and one space less 
before "!"

Systems trying to load previously saved rules on boot will not be able 
to load those rules, and may be either unreachable (if they set a strict 
policy before) or completely open.

-- 
Stefan BühlerMail/xmpp: stefan.bueh...@tik.uni-stuttgart.de
Netze und Kommunikationssysteme der Universität Stuttgart (NKS)
https://www.tik.uni-stuttgart.de/Telefon: +49 711 685 60854

Bug#912358: lighttpd FTCBFS: unsatisfiable Build-Depends

[Stefan Bühler]

Hi,

On 10/30/2018 09:33 PM, Helmut Grohne wrote:
> On Tue, Oct 30, 2018 at 08:57:04PM +0100, Stefan Bühler wrote:
>>> lighttpd fails to cross build from source. The first problem is
>>> satisfying Build-Depends. Two dependencies are problematic: perl and
>>> libcgi-pm-perl. Turns out the latter is unnecessary (removing it does
>>> not influence the build result).
>>
>> Did you even *try* to find out why it is there? See #789856.
> 
> Yes, I did. The bug said, it'll fail hard once we get perl 5.22. We're
> at 5.26 and it doesn't fail. This suggests that the reason is obsolete.
> 
> I also tried to find uses of the module in the lighttpd source, but to
> no avail. In particular, the tests from #789856 no longer use it. Looks
> like an upstream change made the dependency obsolete and nobody noticed.

I'm sorry, you're right.

Upstream removed this dependency in:
https://git.lighttpd.net/lighttpd/lighttpd1.4.git/commit/?id=d147673d401996fcfb7e41c9419d319f93ac398d

Next time just tell from the beginning you already investigated it and 
what you found, so I won't embarrass myself :)
(I basically assumed your cross-build didn't need it because, as you 
also pointed out, only the tests ever needed it.)

cheers,
Stefan

Bug#912358: lighttpd FTCBFS: unsatisfiable Build-Depends

[Stefan Bühler]

Hi.

On 10/30/2018 06:02 PM, Helmut Grohne wrote:
> Source: lighttpd
> Version: 1.4.49-1.1
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> lighttpd fails to cross build from source. The first problem is
> satisfying Build-Depends. Two dependencies are problematic: perl and
> libcgi-pm-perl. Turns out the latter is unnecessary (removing it does
> not influence the build result).

Did you even *try* to find out why it is there? See #789856.

In other words: bad idea.

> And perl needs to be run, but not
> linked, so it gets annotated :native.

Sounds plausible.

> Then it uses the wrong pkg-config
> and fails finding libxml2.pc. After fixing that as well, lighttpd cross
> builds successfully. Please consider applying the attached patch.

Already fixed upstream (since 1.4.50), see
https://git.lighttpd.net/lighttpd/lighttpd1.4.git/commit/configure.ac?id=fefc82153a0260635807ae427943d6fed3238809

cheers,
Stefan

Bug#904741: lighttpd: create-mime.assign.pl skips mime types with capital letters

[Stefan Bühler]

Hi,

this was fixed upstream (in 1.4.36) a long time ago, see:

  
https://github.com/lighttpd/lighttpd1.4/commit/8db141a1b30e5808679e1f341c6ca914be91bed8

We imported the script from debian and extended it heavily.

The debian package is still using the original debian one.

cheers,
Stefan

On 07/27/2018 02:16 PM, chrysn wrote:
> Package: lighttpd
> Version: 1.4.49-1.1
> Severity: normal
> Tags: patch
> 
> The create-mime.assign.pl script can only read mime types without
> capital letters from /etc/mime.types, thus reporting files like .ts or
> .m3u8 as application/octet-stream instead of video/MP2T and
> application/x-mpegURL, respectively.
> 
> The attached patch fixes the issue by accepting capital letters in;
> [^\s] would be an alternative depending on the precise definition of the
> mime.types file.
> 
> Best regards, and thank you for maintaining this package
> chrysn

Bug#893516: postfix: check shouldn't complain about outdated chroot if it isn't used

[Stefan Bühler]

Package: postfix
Version: 3.1.8-0+deb9u1

Hi,

postfix-script (`service postfix check`) checks for outdated chroot,
even if the chroot isn't used.

But /usr/lib/postfix/configure-instance.sh only updates the chroot if it
is used.

Please either always update the chroot or skip the warnings if it isn't.

cheers,
Stefan

Bug#883870: warning: Negative repeat count does nothing

[Stefan Bühler]

Package: libtext-quoted-perl
Version: 2.09-1

Hi,

rt shows warnings like these in the log:

Negative repeat count does nothing at /usr/share/perl5/Text/Quoted.pm line 244.

Upstream bug is: https://rt.cpan.org/Public/Bug/Display.html?id=111986
- seems dead to me.

Attached patch silences the warning by ensuring the count is at least 
zero.

cheers,
Stefan
Description: Fix "Negative repeat count does nothing"

---
Bug: https://rt.cpan.org/Public/Bug/Display.html?id=111986

--- libtext-quoted-perl-2.09.orig/lib/Text/Quoted.pm
+++ libtext-quoted-perl-2.09/lib/Text/Quoted.pm
@@ -241,6 +241,7 @@ sub _classify {
 else {
 my $extraspace =
   length( $line->{raw} ) - length( $line->{text} ) - $firstfrom;
+$extraspace = 0 if $extraspace < 0;
 $paras[-1]->{text} .= "\n" . q{ } x $extraspace . $line->{text};
 $paras[-1]->{raw} .= "\n" . $line->{raw};
 }

Bug#881329: systemd service

[Stefan Bühler]

Hi again,

I had to add

RestartPreventExitStatus=1

in [Service], because on certain failures (e.g. broken permissions in
the lock directory) mailmanctl forks and exits (which systemd considers
a successful start), and then the fork exits with status code 1.
Because it was started "successfully", systemd will trigger a restart
without limit...

It would be better if mailmanctl supported a flag to not fork mailmanctl
itself, but just run in the foreground (no need to close std{in,out,err}
either).  systemd (and other supervising init systems) can handle that
way better.

cheers,
Stefan

Bug#881329: systemd service

[Stefan Bühler]

Package: mailman
Version: 1:2.1.23-1+deb9u1

Hi,

it would be nice if the mailman package offered a real systemd service;
that way it could be automatically restarted on crashes (e.g.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505638), and
`systemctl list-units --failed` would complain properly when it isn't
working.

For this I suggest these two files:

/usr/lib/tmpfiles.d/mailman.conf
---
# path  mode uid  gid
d /run/mailman  0755 list list
d /run/lock/mailman 2775 root list
---

(dh_installinit should create these automatically in .postinst when
systemd is active)

/lib/systemd/system/mailman.service
---
[Unit]
Description=Mailman Master Queue Runner
After=network.target

[Service]
Type=forking
PIDFile=/var/run/mailman/mailman.pid
ExecStart=/usr/lib/mailman/bin/mailmanctl -s start
ExecStop=/usr/lib/mailman/bin/mailmanctl stop
ExecReload=/usr/lib/mailman/bin/mailmanctl restart
Restart=always
RestartSec=3s

[Install]
WantedBy=multi-user.target
Alias=mailman-qrunner.service
---

mailmanctl checks for the existence of the site list on start itself, I
don't see any need to keep/clone this logic.

In [Unit] one could add:
---
ConditionFileIsExecutable=/usr/bin/python
---
to replicate the check from the init script.

cheers,
Stefan

Bug#879496: New upstream release 1.4.46 available

[Stefan Bühler]

Hi again,

On 10/22/2017 12:15 PM, Stefan Bühler wrote:
> [...]
> 
> Build service doesn't provide the source gpg signature yet,
> so to download the source package use:
> 
>wget -O lighttpd_1.4.46.orig.tar.xz.asc 
> https://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-1.4.46.tar.xz.asc
>dget -ud 
> https://download.opensuse.org/repositories/home:/stbuehler:/lighttpd-1.4.x/Debian_Next/lighttpd_1.4.46-0.1.dsc
> 
> 
> * I included the gpg signature in the upload for now (but this
>   breaks Ubuntu 14.04, dpkg-dev-1.17.5ubuntu5 doesn't like the
>   "unknown" file)

reprepro can't handle the signature either ("No section and no priority
for 'lighttpd', skipping."), so I dropped it.

Bug#879496: New upstream release 1.4.46 available

[Stefan Bühler]

Package: lighttpd
Version: 1.4.45-1

Hi,

we just released 1.4.46.

In


https://build.opensuse.org/package/show/home:stbuehler:lighttpd-1.4.x/lighttpd

I provide an updated package; as always our goal is to build
on older distributions too, while sticking to the official
package as close as possible.

Build service doesn't provide the source gpg signature yet,
so to download the source package use:

   wget -O lighttpd_1.4.46.orig.tar.xz.asc 
https://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-1.4.46.tar.xz.asc
   dget -ud 
https://download.opensuse.org/repositories/home:/stbuehler:/lighttpd-1.4.x/Debian_Next/lighttpd_1.4.46-0.1.dsc


* I included the gpg signature in the upload for now (but this
  breaks Ubuntu 14.04, dpkg-dev-1.17.5ubuntu5 doesn't like the
  "unknown" file)
* Some new modules; some of those got their own package.  The
  descriptions might need some work.
* Updated var/www/cgi-bin/ in lighttpd.lintian-overrides.  You
  might want to rethink that (#763618, #837696), policy is
  clear on this imho:

https://www.debian.org/doc/debian-policy/#web-servers-and-applications

  > [...]
  > 1. Cgi-bin executable files are installed in the directory
  >/usr/lib/cgi-bin
  > [...]

Bug#878432: mailman broken held requests due to log problems

[Stefan Bühler]

Package: mailman
Version: 1:2.1.23-1+deb9u1

Hi,

my /var/log/mailman directory had mode "drwxr-sr-x" (owned by 
root:list); not all log files exist.

When a new request came in that mailman tried to held back, it couldn't 
create the log file "vette" and crashed with:

---
Oct 13 16:27:23 2017 (1579) Uncaught runner exception: [Errno 9] Bad file 
descriptor
Oct 13 16:27:23 2017 (1579) Traceback (most recent call last):
  File "/var/lib/mailman/Mailman/Queue/Runner.py", line 119, in _oneloop
self._onefile(msg, msgdata)
  File "/var/lib/mailman/Mailman/Queue/Runner.py", line 190, in _onefile
keepqueued = self._dispose(mlist, msg, msgdata)
  File "/var/lib/mailman/Mailman/Queue/IncomingRunner.py", line 130, in _dispose
more = self._dopipeline(mlist, msg, msgdata, pipeline)
  File "/var/lib/mailman/Mailman/Queue/IncomingRunner.py", line 153, in 
_dopipeline
sys.modules[modname].process(mlist, msg, msgdata)
  File "/var/lib/mailman/Mailman/Handlers/Moderate.py", line 131, in process
Hold.hold_for_approval(mlist, msg, msgdata, Hold.NonMemberPost)
  File "/var/lib/mailman/Mailman/Handlers/Hold.py", line 298, in 
hold_for_approval
listname, sender, message_id, reason)
  File "/var/lib/mailman/Mailman/Logging/Syslog.py", line 43, in write
self.write_ex(kind, msg, args, kws)
  File "/var/lib/mailman/Mailman/Logging/Syslog.py", line 52, in write_ex
logf = self._logfiles[kind] = StampedLogger(kind)
  File "/var/lib/mailman/Mailman/Logging/StampedLogger.py", line 52, in __init__
Logger.__init__(self, category, nofail, immediate)
  File "/var/lib/mailman/Mailman/Logging/Logger.py", line 50, in __init__
self.__get_f()
  File "/var/lib/mailman/Mailman/Logging/Logger.py", line 76, in __get_f
_logexc(self, e)
  File "/var/lib/mailman/Mailman/Logging/Utils.py", line 22, in _logexc
sys.__stderr__.write('Logging error: %s\n' % logger)
IOError: [Errno 9] Bad file descriptor

Oct 13 16:27:23 2017 (1579) SHUNTING: [...]
---

(I had to strace the qrunner to see the actual problem.)

Reinstalling the package didn't fix the permission.  I don't know why the
directory had the permissions, but I'm guessing it comes from upgrading
from an older version.

The mode in the debian package itself is looking good ("drwxrws---"), and 
after correcting it mailman seems to work fine (apart from some shunted 
files which probably should get cleaned up).

Maybe this should get fixed in postinst (after checking dpkg-statoverride
of course).

cheers,
Stefan

Bug#877870: lighttpd: "reload" action breaks further actions

[Stefan Bühler]

Hi,

(upstream) 1.4.46 will contain an updated unit file which includes a 
reload action, see


https://git.lighttpd.net/lighttpd/lighttpd1.4.git/commit/?h=0ae6bab4a97f12a0c93200df36ac1741696eeed5

for details.

(Afaics the debian packages installs the upstream unit file).

On 10/06/2017 03:53 PM, Andreas Hasenack wrote:
> Package: lighttpd
> Version: 1.4.45-1
> Severity: normal
> 
> Dear Maintainer,
> 
> After you issue a "service lighttpd reload" (or call /etc/init.d/lighttpd
> directly with the same action), all further actions stop working.
> 
> This happens because the "reload" action is not defined in the systemd
> service file, so the code in /etc/init.d/lighttpd is used. That code in
> turn restarts the service. When you later run status/stop/start/restart,
> these are done via systemd and it thinks the service is dead because the
> PID changed.
> 
> For example, starting with a running lighttpd:
> root@sid-lighttpd-reload-1721635:~# ps fxaw
>   PID TTY  STAT   TIME COMMAND
> (...)
> 17184 ?Ss 0:00 /usr/sbin/lighttpd -D -f
> /etc/lighttpd/lighttpd.conf
> root@sid-lighttpd-reload-1721635:~# service lighttpd status
> ● lighttpd.service - Lighttpd Daemon
>Loaded: loaded (/lib/systemd/system/lighttpd.service; enabled; vendor
> preset: enabled)
>Active: active (running) since Fri 2017-10-06 13:48:53 UTC; 4s ago
> (...)
> 
> Let's reload:
> root@sid-lighttpd-reload-1721635:~# service lighttpd reload
> [ ok ] Reloading web server configuration: lighttpd.
> 
> Status now is dead:
> root@sid-lighttpd-reload-1721635:~# service lighttpd status
> ● lighttpd.service - Lighttpd Daemon
>Loaded: loaded (/lib/systemd/system/lighttpd.service; enabled; vendor
> preset: enabled)
>Active: inactive (dead) since Fri 2017-10-06 13:49:08 UTC; 2s ago
>   Process: 17184 ExecStart=/usr/sbin/lighttpd -D -f
> /etc/lighttpd/lighttpd.conf (code=exited, status=0/SUCCESS)
>   Process: 17177 ExecStartPre=/usr/sbin/lighttpd -tt -f
> /etc/lighttpd/lighttpd.conf (code=exited, status=0/SUCCESS)
>  Main PID: 17184 (code=exited, status=0/SUCCESS)
> 
> But it's still running, albeit a new copy:
> root@sid-lighttpd-reload-1721635:~# ps fxaw
>   PID TTY  STAT   TIME COMMAND
> (...)
> 17231 ?S  0:00 /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf
> 
> "start" will fail now, for example:
> root@sid-lighttpd-reload-1721635:~# service lighttpd status
> ● lighttpd.service - Lighttpd Daemon
>Loaded: loaded (/lib/systemd/system/lighttpd.service; enabled; vendor
> preset: enabled)
>Active: failed (Result: exit-code) since Fri 2017-10-06 13:51:25 UTC;
> 836ms ago
>   Process: 17391 ExecStart=/usr/sbin/lighttpd -D -f
> /etc/lighttpd/lighttpd.conf (code=exited, status=255)
>   Process: 17384 ExecStartPre=/usr/sbin/lighttpd -tt -f
> /etc/lighttpd/lighttpd.conf (code=exited, status=0/SUCCESS)
>  Main PID: 17391 (code=exited, status=255)
> 
> Oct 06 13:51:25 sid-lighttpd-reload-1721635 systemd[1]: lighttpd.service:
> Unit entered failed state.
> Oct 06 13:51:25 sid-lighttpd-reload-1721635 systemd[1]: lighttpd.service:
> Failed with result 'exit-code'.
> 
> journalctl shows the reason:
> Oct 06 13:51:24 sid-lighttpd-reload-1721635 lighttpd[17377]: 2017-10-06
> 13:51:24: (network.c.464) can't bind to port:  80 Address already in use
> 
> Managing this service via systemd or sysv is now effectively broken.
> 

Bug#838473: lighttpd: Not reliably stoppable using systemd service file

[Stefan Bühler]

Hi,

On 09/21/2016 12:22 PM, Lukas Martini wrote:
> Package: lighttpd
> Version: 1.4.35-4+deb8u1
> Severity: normal
> 
> When running 'systemctl stop lighttpd', sometimes the command will seemingly
> complete successfully, but doesn't actually stop lighttpd. Similarly, after
> 'systemctl restart lighttpd' the same instance will just continue running
> (as the old one isn't stopped and systemd's attempt to start lighttpd
> again obviously fails as the ports are in use).
> 
> I haven't properly debugged this issue in any way, but I've seen it across
> various servers using lighttpd. My first guess for the cause would be 
> that no pidfile is specified in the systemd service and systemd is left 
> guessing
> for the main task, but I could be wrong.

On receiving the first signal lighttpd will stop accepting new requests
and try to close pending ones; connections in keep-alive "wait" mode
should get closed immediately, but active connections might take a while.

When sending a second signal lighttpd should drop all connections and
exit immediately.

systemd shouldn't need the pid file, as it should start lighttpd in "no
detach/daemonize" mode (using the "-D" argument).

A "systemctl status lighttpd.service" output is probably the minimum to
even start debugging - I see no reason to keep this bug open without any
data in it.

cheers,
Stefan

Bug#877039: ":80" is appended to socket file name

[Stefan Bühler]

Hi Jonathan,

On 09/28/2017 01:23 AM, Jonathan Krebs wrote:
> Package: lighttpd
> Version: 1.4.45-1
> 
> If the server is bound to a socket in file system, three characters :80 are 
> appended to the file path, breaking my reverse proxy setup.
> Minimal example:
> 
> jonny@heron:/var/tmp/ltest$ lighttpd -D -f config &
> [1] 30888
> jonny@heron:/var/tmp/ltest$ 2017-09-28 00:26:22: (log.c.217) server started 
> 
> jonny@heron:/var/tmp/ltest$ ls
> config  lighty.pid  lighty.sock:80
> 
> [...]
> 
> I think the source lines appending the port are src/network.c,
> buffer_copy_buffer(b, srv->srvconf.bindhost);
> buffer_append_string_len(b, CONST_STR_LEN(":"));
> buffer_append_int(b, srv->srvconf.port);

I think you are right about that - removing the buffer_append_* lines 
should fix it (and it shouldn't even break anything since 1.4.40).

> I remember my setup to work some time ago (jessie or something older)

I doubt that - these lines have been there for a long time (basically as 
far back as the svn history goes; svn revision 30 is the first we see in 
git).  $SERVER["socket"] should have been working fine though.

I think the upstream fix will be something like this (won't apply in 
1.4.45):


https://git.lighttpd.net/lighttpd/lighttpd1.4.git/commit/src/network.c?h=personal/stbuehler/fix-server.bind-unix-path

cheers,
Stefan

Bug#876553: fixed in weechat 1.9.1-1

[Stefan Bühler]

Hi,

are there any plans to fix this in stable (stretch) too?

I disagree with the "Minor issue; requires a malicious IRC server"
comment on https://security-tracker.debian.org/tracker/CVE-2017-14727
(even upstream classified it as "high severity"), and it seems the patch
is easy to backport (no conflicts, compiles just fine).

cheers,
Stefan

Bug#870069: orig-tarball-missing-upstream-signature error breaks rebuilding existing packages and more

[Stefan Bühler]

Hi,

On 09/03/2017 06:20 AM, Paul Hardy wrote:
> On Sat, Sep 2, 2017 at 1:41 PM, Chris Lamb  wrote:
>> ...
>> See #870722. This was fixed in 4th August in:
>>
>>   
>> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=126157380dc0eba302f3d476b1cffc13f968c207
> 
> That is great.  The next lintian release should be able to close this
> bug then, unless Stefan disagrees.

Downgrading to W: was all I ever asked for :)

Thanks!

Stefan

Bug#860055: Inquiry about packaging progress

[Stefan Bühler]

Hi again,

On 08/31/2017 12:17 AM, Christoph Biedl wrote:
> Christoph Biedl wrote...
> 
>> * The build failure on i386 (also seen on armhf) and probably
>>   all other 32bit archs needs to be fixed.
> [...]
This is fixed upstream now:
  https://github.com/dino/dino/commit/dc26841b9e

I updated my package for this new snapshot, and it seems to build
(32-bit too) and run (tested 64-bit) ok.

There is also this:
https://build.opensuse.org/package/show/network:messaging:xmpp:dino/dino
(https://download.opensuse.org/repositories/network:/messaging:/xmpp:/dino/Debian_9.0/)

Upstream seems to be involved with this package, but:
- They reuse the "dino" name (which is still used in oldstable - can it
  be reused already? should it be reused?)
- There is a dev package, but no lib package; that is probably a bad
  idea
- A dev package requires IMHO a commitment to stable ABI (and SONAME
  bumps), and given that there isn't even a release yet I wouldn't rely
  on that.
- The platform independent files are not in a separate package.
- The magic "_service"-link to automatically update on each commit seems
  to package git-submodules directly (so they don't need the symlink
  hack I had to use in debian/rules)

Imho unresolved:

a) libsignal-protocol-c should be packaged separately (#840366)
b) I didn't check the source for any other inlined (re)sources which
   might already be packaged separately, and I didn't check the licenses
   either.  Did someone else check?
c) There are 3 shared libraries provided by the package, which the
   plugins link against, so they can't be linked statically.  But they
   are in the standard shared library directory.

   I don't think upstream is ready to provide a stable API yet, so a
   separate dev and lib package imho doesn't make sense (otherwise you'd
   have to so-bump on every release).

   What is the correct way to package these shared libraries in the
   meantime?  Append the package version to the binary basename?

   One day dev and lib package could be provided, is it possible to
   split the package then without so-bump with the current names?

   I went with renaming the "qlite" and "xmpp-vala" shared libraries to
   "dino-qlite" and "dino-xmpp-vala" for now, so they at least live in
   their own namespace (and this might be a good idea even in the long
   run - maybe ask upstream to do the same?).
d) lintian:
   W: dino-xmpp-client: desktop-mime-but-no-exec-code 
usr/share/applications/dino.desktop
e) "dino" vs "dino-xmpp-client"?

cheers,
Stefan

Bug#860055: Inquiry about packaging progress

[Stefan Bühler]

Hi Christoph,

On 08/30/2017 07:27 PM, Christoph Biedl wrote:
> Stefan Bühler wrote...
> 
>> This ITP (#860055) is owned by Dominik George.
> 
> Ups, I indeed mis-directed Marcus here.
> 
>> I only wanted to give dino a short try, and preferred to have a package
>> for this.  My package probably violates the debian policy in many ways,
>> so it is not ready to be uploaded - I just posted a link in case it
>> helps anyone else doing similar work.
> 
> While I am willing to give it a look, the opensuse developers
> unfortunately spent a lot of time making web content as inaccessible as
> possible. In other words, I'd need a working download link, I get either
> 401 or just html. Is there *anywhere* an URL I can just feed to dget?

Yes, the .dsc files in:

  https://download.opensuse.org/repositories/home:/stbuehler/Debian_9.0/

work for me with dget.

cheers,
Stefan

Bug#860055: Inquiry about packaging progress

[Stefan Bühler]

Hi Marcus,

On 08/29/2017 09:58 PM, Marcus Poller wrote:
> Dear Stefan,
> 
> gentle ping? What's the status of your packaging work? I'ld love to use this 
> package.

This ITP (#860055) is owned by Dominik George.

I only wanted to give dino a short try, and preferred to have a package
for this.  My package probably violates the debian policy in many ways,
so it is not ready to be uploaded - I just posted a link in case it
helps anyone else doing similar work.

cheers,
Stefan

Bug#870069: orig-tarball-missing-upstream-signature error breaks rebuilding existing packages and more

[Stefan Bühler]

Package: lintian
Version: 2.5.52

Hi,

I think "error" is a rather unfortunate choice for the severity level of
"orig-tarball-missing-upstream-signature".

* I have some (existing) packages uploaded on build.opensuse.org, and
  they now fail to build for "Debian_Next" (buster).  I'd rather avoid
  modifying the upstream debian package just for this.

* I also generate snapshot builds automatically.  These are (on purpose)
  not signed with the "upstream key" - because they are automatically
  generated.

  I want to stay as close as possible to the debian package, and this
  error makes this a lot harder.

I like the check, but would prefer to see it downgraded to a warning.

I already had to enable lintian manually for my build.opensuse.org
projects (I was told they disabled it because it broke too many builds
[1]); I'd prefer to keep it enabled at least for my projects.

cheers,
Stefan

[1]: https://build.opensuse.org/project/prjconf/Debian:8.0
 https://build.opensuse.org/project/prjconf/Debian:9.0
 https://build.opensuse.org/project/prjconf/Debian:Next

Bug#863981: check_ping uses IPv6 with -4

[Stefan Bühler]

Hi Jan,

On 07/11/2017 12:29 PM, Jan Wagner wrote:
> Dear Stefan,
> 
> Am 11.07.17 um 11:07 schrieb Stefan Bühler:
>> You didn't get the issue.  I know very well how to call check_ping with
>> -4 - I can do that with my local config.  But check_ping -4 DOES NOT
>> call "ping -4" - it just calls "ping".  The -4 option does *NOTHING*. It
>> basically is the same as not passing "-6".
> 
> just adding "-4" to the "ping-command" in debian/rules will solve this
> problem but cause others.
> 
> <- snip ->
> Depends: inetutils-ping (>= 2:1.9-1~) [kfreebsd-any hurd-any],
>  iputils-ping [linux-any],
> <- snap ->
> 
> inetutils-ping and older iputils-ping (when backporting) doesn't support
> "ping -4". So this is something that has to be discovered at buildtime I
> think.

That is a problem of course.

Maybe adding a separate "ping4-command" compile time string is an option.

cheers,
Stefan

Bug#863981: check_ping uses IPv6 with -4

[Stefan Bühler]

Hi Jan,

On 07/11/2017 09:12 AM, Jan Wagner wrote:
> Hi Stefan,
> 
> thanks for bringing this to our attention.
> 
> Am 02.06.2017 um 18:39 schrieb Stefan Bühler:
>> check_ping doesn't forward the "-4" option to ping, and ping prefers
>> IPv6 now (i.e. probably whatever is configured through gai.ping).
>>
>> Giving upstream only allows configuring "ping-command" and
>> "ping6-command" (there is no explicit "ping4-command") I suggest adding
>> "-4" to the "ping-command" in debian/rules in the meantime.
> 
> I guess you have checked /etc/nagios-plugins/config/ping.cfg? There are
> explicit commands ending on "_4" which are using "-4" in its command and
> so forcing IPv4 tests.

You didn't get the issue.  I know very well how to call check_ping with
-4 - I can do that with my local config.  But check_ping -4 DOES NOT
call "ping -4" - it just calls "ping".  The -4 option does *NOTHING*. It
basically is the same as not passing "-6".

Also there is no package providing /etc/nagios-plugins/config/ping.cfg.
Maybe you meant /usr/share/monitoring-plugins/templates-basic/ping.cfg ?
But not really relevant at all.

cheers,
Stefan

Bug#867016: fails to handle filenames longer than 199 bytes

[Stefan Bühler]

Package: cruft-ng
Version: 0.4.4

Hi,

I have some local packages which use filenames longer than 200 bytes; it
would be nice if cruft-ng would handle theses in a sane way.

Changing SIZEBUF to 4096 in dpkg_popen.cc:70 should fix it.

cheers,
Stefan

Bug#866387: custom filters for missing files

[Stefan Bühler]

Hi,

On 06/29/2017 02:11 PM, Alexandre Detiste wrote:
> Hi,
> 
> When I took over cruft, I realized support for "filters-miss/" has never
> been fully implemented; so it hasn't been re-implemented in cruft-ng:
> 
> See here: nothing
>   https://sources.debian.net/src/cruft/0.9.12/filters-miss/
> 
>> it seems empty directories sometimes get missing in dpkg.  Not sure yet
>> whether this is a bug and if so, in which package.
> 
>> It would be nice to have a way to at least manually ignore these.
> 
> libglib2.0-0 is still using deprecated CDBS build system;
> a wild guess is that witching to modern Debhelper would
> make this problem disapear.

So you think debhelper would add postinst code to make sure those
directories are present? Because I see no other way the build system
would affect the outcome.

> This is likely more globaly usefull than implemeting manual
> filtering of missing files in cruft/cruft-ng

I found more use cases in the meantime...

- /etc/python2.7/sitecustomize.py doesn't get created on
  upgrade/reinstall
- the glib problem/bug sometimes also triggers with
  /usr/share/glib-2.0/schemas
- sometimes I explicitly don't want a config file to be present
  (signalled by renaming it to FOO.dpkg-dist). For example init scripts
  when I only want the binary, not the service. Or the many exim config
  snippets you don't want to activate.

cheers,
Stefan

Bug#866387: custom filters for missing files

[Stefan Bühler]

Package: cruft-ng
Version: 0.4.4+b1
Severity: whishlist

Hi,

it seems empty directories sometimes get missing in dpkg.  Not sure yet
whether this is a bug and if so, in which package.

# cruft-ng
cruft report: Thu 29 Jun 2017 11:40:30 AM UTC
 missing: dpkg 
/usr/lib/x86_64-linux-gnu/gio
/usr/lib/x86_64-linux-gnu/gio/modules
[...]

They should be part of libglib2.0-0:

# dpkg -L libglib2.0-0:amd64 | grep /usr/lib/x86_64-linux-gnu/gio
/usr/lib/x86_64-linux-gnu/gio
/usr/lib/x86_64-linux-gnu/gio/modules

But no other files are registered in the path:

# dpkg -S '/usr/lib/x86_64-linux-gnu/gio*'
libglib2.0-0:amd64: /usr/lib/x86_64-linux-gnu/gio/modules
libglib2.0-0:amd64: /usr/lib/x86_64-linux-gnu/gio

Reinstalling the package did not help.

It would be nice to have a way to at least manually ignore these.

cheers,
Stefan

Bug#866362: dash.preinst uses bash

[Stefan Bühler]

Package: dash
Version: 0.5.8-2.4

Hi,

the dash.preinst script starts with:

#!/bin/bash

Is there any reason for this madness? :)
If there is a reason it might be worth documenting it in the script; at
a first glance the script doesn't look like it is using bashisms to me.

As bash Pre-Depends on dash you cannot actually install bash before dash...

cheers,
Stefan

Bug#865421: Purging old postgres stops all instances

[Stefan Bühler]

Package: postgresql-client-common
Version: 181

Hi,

I installed postgresql-9.6, upgraded the cluster (dropping the new empty
one, pg_upgradecluster, dropping the old one), and then purged
postgresql-9.4, and suddenly my 9.6 cluster is down (probably triggers
with simple remove too).

The postgresql-9.4 (and 9.6) prerm script calls "stop_version $VERSION"
from /usr/share/postgresql-common/maintscripts-functions, which stops
postgresql ("all clusters") if:

[ -x /etc/init.d/postgresql ] && [ ! -x /etc/init.d/postgresql-$1 ]

I only have /etc/init.d/postgresql, but no /etc/init.d/postgresql-*.
This probably got lost with systemd.

cheers,
Stefan

Bug#714726: wrong (as in: release-specific) "Suite:" entry in backports Release file

[Stefan Bühler]

Hi,

On Tue, 6 Jun 2017 13:33:03 +0200 Stefan Bühler wrote:
> Hi,
> 
> On Sun, 26 Apr 2015 22:01:03 +0200 Stefano Zacchiroli <z...@debian.org>
> wrote:
> > Heya,
> > 
> > On Tue, Jul 02, 2013 at 10:30:40AM +0200, Stefano Zacchiroli wrote:
> > >   ./wheezy-backports/Release:Suite: wheezy-backports
> > >   ./wheezy-backports/Release:Codename: wheezy-backports
> > > 
> > > as you can see from the last 2 lines, both Suite and Codename are set
> > > to "wheezy-backports" whereas, to be consistent with the rest, the
> > > suite should be something like "stable-backports".
> > 
> > JFTR, it looks like this bug has been propagated to the just released
> > suite Jessie. Currently,
> > http://ftp.debian.org/debian/dists/jessie-backports/Release reads:
> > 
> >   Suite: jessie-backports
> >   Codename: jessie-backports
> > 
> > To cope with this, I've just hard-coded yet another release name in
> > sources.d.n configuration, to make sure that the new backports suite is
> > included.
> > 
> > It would be nice to fix this now for jessie+1.
> 
> Didn't work out so far, stretch is affected by this as well:
> 
> $ curl -s http://ftp.debian.org/debian/dists/stretch-backports/Release
> Origin: Debian Backports
> Label: Debian Backports
> Suite: stretch-backports
> Codename: stretch-backports
> [...]
> 
> Maybe this could still be fixed in time? I guess right now "Suite"
> should read "testing-backports", hoping it becomes "stable-backports" on
> release.

Still broken after the stretch release.  Maybe this time just fix it
although it is already released (right now there is nothing in it yet
anyway)?

As a workaround if someone wants to pin:

Pin: release o=Debian Backports,a=stable-backports

They should pin instead or additionally:

Pin: release o=Debian Backports,n=stretch-backports

Or (if you don't mix oldstable / stable backports sources):

Pin: release o=Debian Backports

Pinning a=stretch-backports ("a=" instead of "n="!) might work now, but
breaks if this bug gets fixed.

cheers,
Stefan

Bug#714726: wrong (as in: release-specific) "Suite:" entry in backports Release file

[Stefan Bühler]

Hi,

On Sun, 26 Apr 2015 22:01:03 +0200 Stefano Zacchiroli 
wrote:
> Heya,
> 
> On Tue, Jul 02, 2013 at 10:30:40AM +0200, Stefano Zacchiroli wrote:
> >   ./wheezy-backports/Release:Suite: wheezy-backports
> >   ./wheezy-backports/Release:Codename: wheezy-backports
> > 
> > as you can see from the last 2 lines, both Suite and Codename are set
> > to "wheezy-backports" whereas, to be consistent with the rest, the
> > suite should be something like "stable-backports".
> 
> JFTR, it looks like this bug has been propagated to the just released
> suite Jessie. Currently,
> http://ftp.debian.org/debian/dists/jessie-backports/Release reads:
> 
>   Suite: jessie-backports
>   Codename: jessie-backports
> 
> To cope with this, I've just hard-coded yet another release name in
> sources.d.n configuration, to make sure that the new backports suite is
> included.
> 
> It would be nice to fix this now for jessie+1.

Didn't work out so far, stretch is affected by this as well:

$ curl -s http://ftp.debian.org/debian/dists/stretch-backports/Release
Origin: Debian Backports
Label: Debian Backports
Suite: stretch-backports
Codename: stretch-backports
[...]

Maybe this could still be fixed in time? I guess right now "Suite"
should read "testing-backports", hoping it becomes "stable-backports" on
release.

cheers,
Stefan

Bug#863981: check_ping uses IPv6 with -4

[Stefan Bühler]

Package: monitoring-plugins-basic
Version: 2.2-3

Hi,

check_ping doesn't forward the "-4" option to ping, and ping prefers
IPv6 now (i.e. probably whatever is configured through gai.ping).

Giving upstream only allows configuring "ping-command" and
"ping6-command" (there is no explicit "ping4-command") I suggest adding
"-4" to the "ping-command" in debian/rules in the meantime.

cheers,
Stefan

Bug#863221: [pkg-gnupg-maint] Bug#863221: dirmngr doesn't reload resolv.conf

[Stefan Bühler]

Hi,

On 05/24/2017 02:14 PM, Werner Koch wrote:
> Hi!
> 
> When you switch the laptop connection you should flush dirmngr anyway
> and thus I do not consider the need to do this just for the resolver.
> 
>  gpgconf --reload dirmngr
> 
> in the ifup script should do that job.  Note that gpgconf won't start a
> component on --reload or --kill if it is not yet started.

1) How would I install an if-up.d hook without being root?
2) The dirmngr package should work out of the box, i.e. install the
   required hooks.
3) There are many network managers.  I'd consider hooking only ifupdown
   not sufficient.
4) Calling "gpgconf --reload dirmngr" as root doesn't reload my user
   dirmngr.
5) I see no documentation regarding the need for such hook.  The debian
   manpage only says (regarding SIGHUP):

>> This  signal  flushes  all internally cached CRLs as well as any
>> cached certificates.  Then the certificate cache is reinitialized as
>> on startup.  Options are re-read  from  the  configuration  file.

   I don't see why it would be necessary to reload CRLs and
   certificates on network connection changes from this comment.


Also I think this way (adding a hook in a global configuration to reload
user space components) is a very bad design.

How about simply reloading everything when /etc/resolv.conf or friends
were touched?  This also won't cover every scenario (e.g. running a
local resolver and never changing resolv.conf), but it'd be a start.

You could also try to monitor netlink messages for new default routes to
detect network changes, but this is obviously more platform specific
than stat()ing resolv.conf.

cheers,
Stefan

Bug#863221: dirmngr doesn't reload resolv.conf

[Stefan Bühler]

Package: dirmngr
Version: 2.1.18-6

Hi,

dirmngr doesn't reload /etc/resolv.conf but is a long-living process.

For laptop users resolv.conf might change more than once a day, and
having to remember or even knowing you have to kill/SIGHUP dirmngr is
not helping the gpg usecase...

When using `dirmngr --server --standard-resolver` it stat()s resolv.conf
every time and picks up new nameservers.

(Tested with `WKD_GET --submission-address ...` commands, the error
shown by dirmngr is `ERR 219 Server indicated a failure `.)

cheers,
Stefan

Bug#839575: hangs waiting for openssl

[Stefan Bühler]

Hi,

tinyca hangs due to a regression in openssl, fixed in:


https://github.com/openssl/openssl/commit/888adbe064556ff5ab2f1d16a223b0548696614c

The tinyca code quality is still very low - very close to unacceptable
for something handling private keys and crypto.

* it builds strings to execute with /bin/sh -c "...", and quotes 
  filenames using \"$filename\" in perl.  It should pass the command
  and arguments as list instead - it's not that complicated.
* trying to respond to the openssl interactive mode seems a very bad
  idea.
* when I close tinyca (working on an existing setup) perl crashes with 
  a segfault (no idea who to blame for this, see attached 
  tinyca-perl-valgrind.txt)

cheers,
Stefan
==28880== Invalid read of size 8
==28880==at 0x68C9678: ??? (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.3)
==28880==by 0x68D2BDB: g_signal_emit_valist (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.3)
==28880==by 0x68D2FBE: g_signal_emit (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.3)
==28880==by 0xB4CEA5F: ??? (in 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.31)
==28880==by 0x68BCC04: g_object_unref (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.3)
==28880==by 0x68DF3EF: g_value_unset (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.3)
==28880==by 0x68D2C11: g_signal_emit_valist (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.3)
==28880==by 0x68D2FBE: g_signal_emit (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.3)
==28880==by 0xB5C74F4: ??? (in 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.31)
==28880==by 0x68BCC04: g_object_unref (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.3)
==28880==by 0x666EF99: ??? (in 
/usr/lib/x86_64-linux-gnu/perl5/5.24/auto/Glib/Glib.so)
==28880==by 0x1DC0BF: Perl_pp_entersub (in /usr/bin/perl)
==28880==  Address 0xffeffebc8 is on thread 1's stack
==28880==  2280 bytes below stack pointer
==28880== 
==28880== Invalid read of size 8
==28880==at 0x68C9670: ??? (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.3)
==28880==by 0x68D2BDB: g_signal_emit_valist (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.3)
==28880==by 0x68D2FBE: g_signal_emit (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.3)
==28880==by 0xB4CEA5F: ??? (in 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.31)
==28880==by 0x68BCC04: g_object_unref (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.3)
==28880==by 0x68DF3EF: g_value_unset (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.3)
==28880==by 0x68D2C11: g_signal_emit_valist (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.3)
==28880==by 0x68D2FBE: g_signal_emit (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.3)
==28880==by 0xB5C74F4: ??? (in 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.31)
==28880==by 0x68BCC04: g_object_unref (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.3)
==28880==by 0x666EF99: ??? (in 
/usr/lib/x86_64-linux-gnu/perl5/5.24/auto/Glib/Glib.so)
==28880==by 0x1DC0BF: Perl_pp_entersub (in /usr/bin/perl)
==28880==  Address 0xffeffebc0 is on thread 1's stack
==28880==  2288 bytes below stack pointer
==28880== 
==28880== Conditional jump or move depends on uninitialised value(s)
==28880==at 0x68C967C: ??? (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.3)
==28880==by 0x68D2BDB: g_signal_emit_valist (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.3)
==28880==by 0x68D2FBE: g_signal_emit (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.3)
==28880==by 0xB4CEA5F: ??? (in 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.31)
==28880==by 0x68BCC04: g_object_unref (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.3)
==28880==by 0x68DF3EF: g_value_unset (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.3)
==28880==by 0x68D2C11: g_signal_emit_valist (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.3)
==28880==by 0x68D2FBE: g_signal_emit (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.3)
==28880==by 0xB5C74F4: ??? (in 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.31)
==28880==by 0x68BCC04: g_object_unref (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.3)
==28880==by 0x666EF99: ??? (in 
/usr/lib/x86_64-linux-gnu/perl5/5.24/auto/Glib/Glib.so)
==28880==by 0x1DC0BF: Perl_pp_entersub (in /usr/bin/perl)
==28880== 
==28880== Conditional jump or move depends on uninitialised value(s)
==28880==at 0x68C9676: ??? (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.3)
==28880==by 0x68D2BDB: g_signal_emit_valist (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.3)
==28880==by 0x68D2FBE: g_signal_emit (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.3)
==28880==by 0xB4CEA5F: ??? (in 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.31)
==28880==by 0x68BCC04: 

Bug#860055: ITP: dino -- modern XMPP client

[Stefan Bühler]

Hi,

I gave packaging dino a try:

https://build.opensuse.org/package/show/home:stbuehler/dino

* "dino" is already used as package name. I went for "dino-xmpp-client" 
  instead.
* I bundled libsignal-protocol-c as a separate tar ball. 
  Longterm #840366 should be used instead ofc.
* It fails to build on 32-bit in gpgme due to (missing) largefile 
  flags. Not sure how to handle this - gpgme says one should use 
  -D_FILE_OFFSET_BITS=64.
* Tarballs created with "git pack-dist" in the dino checkout (including
  submodules!), and the following in .git/config:


[alias]
pack-dist = "!sh -c 'git archive --format=tar.xz --prefix=dino/ HEAD -o 
\"../dino-xmpp-client_$(git log --date=format:%Y%m%d -1 
--pretty=format:%ad-g%h).orig.tar.xz\"; git -C 
plugins/signal-protocol/libsignal-protocol-c archive --format=tar.xz 
--prefix=libsignal-protocol-c/ HEAD -o \"../../../../dino-xmpp-client_$(git log 
--date=format:%Y%m%d -1 
--pretty=format:%ad-g%h).orig-libsignal-protocol-c.tar.xz\"'"


Hope this helps :)

cheers,
Stefan

Bug#862398: [pkg-gnupg-maint] Bug#862398: build wks client and server tools

[Stefan Bühler]

Hi dkg,

On 05/15/2017 10:04 PM, Daniel Kahn Gillmor wrote:
> Hi Stefan--
> 
> On Fri 2017-05-12 12:37:03 +0200, Stefan Bühler wrote:
>> it would be nice to build and have packages for the gpg-wks-* tools.
>>
>> It seems there was already done some work in
>>
>> https://anonscm.debian.org/git/pkg-gnupg/gnupg2.git/log/?h=dev/wks
>>
>> I rebased that commit to the experimental branch,
> 
> thanks for this work!  
> 
>> modified some texts and added man pages.
> 
> It'd be great to get these manpages upstream.

There are a lot of manpages in debian/* - so it looks to me like
upstream isn't really interested in maintaining them.  If upstream isn't
maintaining them, it might be easier to keep them in debian.

Does upstream know about these at least? I'm not against getting them
upstream, I'm just not sure whether it is worth my time.

>> Upstream install gpg-wks-client to /usr/lib/gnupg/, but I moved it in
>> the package to /usr/bin - I get that it was designed to be a backend
>> tool for MUAs, but right now I guess most people installing it will have
>> to use it manually.
> 
> I'm not so sure about diverging from upstream in our first introduction
> of these tools in debian.  If we do this, we're effectively committing
> to this divergence forever (someone's going to write scripts that use
> /usr/bin/gpg-wks-* and then get upset when we change it).  and it means
> that anyone who writes docs will have to have a different "how to do
> this on debian" section from "how to do this on fedora" or whatever.
> 
> would you object to using your packaging but shipping in the
> upstream-approved location?  or is it worth convincing upstream to ship
> these tools in /usr/bin instead?

I don't have any other (convincing) arguments, so I reverted the
location to the upstream path.

Now that I actually got it running I added some more infos to the
manpages too.

See attached updated patches, as previously my own changes in:

0001-wks-fix-debian-provide-man-pages-improve-texts.patch

The complete patch (squashed with the dev/wks commit) is:

0001-create-WKS-server-and-client-packages.patch

cheers,
Stefan
From 30dd3225cbbc9e408645b2be17e434dfb87a8daa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Sandro=20Knau=C3=9F?= <he...@debian.org>
Date: Thu, 27 Oct 2016 19:16:14 +0200
Subject: [PATCH 1/1] Create WKS server and client packages

---
 debian/control   |  45 ++
 debian/gnupg-wks-client.install  |   1 +
 debian/gnupg-wks-client.manpages |   1 +
 debian/gnupg-wks-server.install  |   1 +
 debian/gnupg-wks-server.manpages |   1 +
 debian/gpg-wks-client.1  | 178 ++
 debian/gpg-wks-server.1  | 180 +++
 debian/rules |   1 +
 8 files changed, 408 insertions(+)
 create mode 100644 debian/gnupg-wks-client.install
 create mode 100644 debian/gnupg-wks-client.manpages
 create mode 100644 debian/gnupg-wks-server.install
 create mode 100644 debian/gnupg-wks-server.manpages
 create mode 100644 debian/gpg-wks-client.1
 create mode 100644 debian/gpg-wks-server.1

diff --git a/debian/control b/debian/control
index ac0b07907..2b9360477 100644
--- a/debian/control
+++ b/debian/control
@@ -72,6 +72,51 @@ Description: GNU privacy guard - cryptographic agent
  provides a passphrase cache, which is used by pre-2.1 versions of
  GnuPG for OpenPGP operations.
 
+Package: gnupg-wks-server
+Architecture: any
+Multi-Arch: foreign
+Depends:
+ gnupg (= ${binary:Version}),
+ ${misc:Depends},
+ ${shlibs:Depends},
+Description: GNU privacy guard - Web Key Service server
+ GnuPG is GNU's tool for secure communication and data storage.
+ It can be used to encrypt data and to create digital signatures.
+ It includes an advanced key management facility and is compliant
+ with the proposed OpenPGP Internet standard as described in RFC4880.
+ .
+ This package provides the GnuPG server for the Web Key Service
+ protocol.
+ .
+ A Web Key Service is a service that allows users to upload keys per
+ mail to be verified over https as described in
+ https://tools.ietf.org/html/draft-koch-openpgp-webkey-service
+ .
+ For more information see: https://wiki.gnupg.org/WKS
+
+Package: gnupg-wks-client
+Architecture: any
+Multi-Arch: foreign
+Depends:
+ dirmngr (= ${binary:Version}),
+ gnupg (= ${binary:Version}),
+ ${misc:Depends},
+ ${shlibs:Depends},
+Description: GNU privacy guard - Web Key Service client
+ GnuPG is GNU's tool for secure communication and data storage.
+ It can be used to encrypt data and to create digital signatures.
+ It includes an advanced key management facility and is compliant
+ with the proposed OpenPGP Internet standard as described in RFC4880.
+ .
+ This package provides the GnuPG client for the Web Key Service
+ protocol.
+ .
+ A Web Key Service is a se

Bug#803259: support for deprecated openssl features

[Stefan Bühler]

Hi,

I think a separate openssl-insecure package with an (possibly statically
linked) "/usr/bin/openssl-insecure" binary should be safe enough that
people don't "accidentally" use it.

If you would want to really make sure it isn't abused you'd put it
somewhere in /usr/lib/openssl-insecure/.

Building it from the same source as the standard openssl binary is the
higher risk in my opinion: what if some of the insecure build options
suddenly get applied to the main build?

Also upstream might remove some of the deprecated/broken features from
the code completely, in which case testssl.sh probably needs to learn to
use multiple binaries.

JFYI: I think the testssl.sh upstream openssl binary also has some other
patches, e.g. enabling IPv6.

cheers,
Stefan

Bug#862398: build wks client and server tools

[Stefan Bühler]

Package: gnupg2
Version: 2.1.18-8
Severity: wishlist
Tags: patch

Hi,

it would be nice to build and have packages for the gpg-wks-* tools.

It seems there was already done some work in

https://anonscm.debian.org/git/pkg-gnupg/gnupg2.git/log/?h=dev/wks

I rebased that commit to the experimental branch, fixed some file names,
modified some texts and added man pages.

Upstream install gpg-wks-client to /usr/lib/gnupg/, but I moved it in
the package to /usr/bin - I get that it was designed to be a backend
tool for MUAs, but right now I guess most people installing it will have
to use it manually.

I builds fine for me (I didn't test it completely yet though).

My own changes are in:

0001-wks-fix-debian-provide-man-pages-improve-texts.patch

The complete patch (squashed with the dev/wks commit) is:

0001-create-WKS-server-and-client-packages.patch

cheers,
Stefan
From b0f3c201e648980f90bce6c9ab5e47f9b199a985 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20B=C3=BChler?= 
Date: Fri, 12 May 2017 12:22:39 +0200
Subject: [PATCH 1/1] create WKS server and client packages
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- install gpg-wks-client into /usr/bin (upstream installs in
  /usr/lib/gnupg/ which I consider not "convenient" for users).

Based on work by Sandro Knauß .
---
 debian/control   | 45 +
 debian/gnupg-wks-client.install  |  1 +
 debian/gnupg-wks-client.manpages |  1 +
 debian/gnupg-wks-server.install  |  1 +
 debian/gnupg-wks-server.manpages |  1 +
 debian/gpg-wks-client.1  | 86 
 debian/gpg-wks-server.1  | 80 +
 debian/rules |  1 +
 8 files changed, 216 insertions(+)
 create mode 100644 debian/gnupg-wks-client.install
 create mode 100644 debian/gnupg-wks-client.manpages
 create mode 100644 debian/gnupg-wks-server.install
 create mode 100644 debian/gnupg-wks-server.manpages
 create mode 100644 debian/gpg-wks-client.1
 create mode 100644 debian/gpg-wks-server.1

diff --git a/debian/control b/debian/control
index ac0b07907..2b9360477 100644
--- a/debian/control
+++ b/debian/control
@@ -72,6 +72,51 @@ Description: GNU privacy guard - cryptographic agent
  provides a passphrase cache, which is used by pre-2.1 versions of
  GnuPG for OpenPGP operations.
 
+Package: gnupg-wks-server
+Architecture: any
+Multi-Arch: foreign
+Depends:
+ gnupg (= ${binary:Version}),
+ ${misc:Depends},
+ ${shlibs:Depends},
+Description: GNU privacy guard - Web Key Service server
+ GnuPG is GNU's tool for secure communication and data storage.
+ It can be used to encrypt data and to create digital signatures.
+ It includes an advanced key management facility and is compliant
+ with the proposed OpenPGP Internet standard as described in RFC4880.
+ .
+ This package provides the GnuPG server for the Web Key Service
+ protocol.
+ .
+ A Web Key Service is a service that allows users to upload keys per
+ mail to be verified over https as described in
+ https://tools.ietf.org/html/draft-koch-openpgp-webkey-service
+ .
+ For more information see: https://wiki.gnupg.org/WKS
+
+Package: gnupg-wks-client
+Architecture: any
+Multi-Arch: foreign
+Depends:
+ dirmngr (= ${binary:Version}),
+ gnupg (= ${binary:Version}),
+ ${misc:Depends},
+ ${shlibs:Depends},
+Description: GNU privacy guard - Web Key Service client
+ GnuPG is GNU's tool for secure communication and data storage.
+ It can be used to encrypt data and to create digital signatures.
+ It includes an advanced key management facility and is compliant
+ with the proposed OpenPGP Internet standard as described in RFC4880.
+ .
+ This package provides the GnuPG client for the Web Key Service
+ protocol.
+ .
+ A Web Key Service is a service that allows users to upload keys per
+ mail to be verified over https as described in
+ https://tools.ietf.org/html/draft-koch-openpgp-webkey-service
+ .
+ For more information see: https://wiki.gnupg.org/WKS
+
 Package: scdaemon
 Architecture: any
 Multi-Arch: foreign
diff --git a/debian/gnupg-wks-client.install b/debian/gnupg-wks-client.install
new file mode 100644
index 0..3ec2ebcaa
--- /dev/null
+++ b/debian/gnupg-wks-client.install
@@ -0,0 +1 @@
+debian/tmp/usr/lib/gnupg/gpg-wks-client /usr/bin/
diff --git a/debian/gnupg-wks-client.manpages b/debian/gnupg-wks-client.manpages
new file mode 100644
index 0..d2edd3e69
--- /dev/null
+++ b/debian/gnupg-wks-client.manpages
@@ -0,0 +1 @@
+debian/gpg-wks-client.1
diff --git a/debian/gnupg-wks-server.install b/debian/gnupg-wks-server.install
new file mode 100644
index 0..c18c2e7fd
--- /dev/null
+++ b/debian/gnupg-wks-server.install
@@ -0,0 +1 @@
+debian/tmp/usr/bin/gpg-wks-server
diff --git a/debian/gnupg-wks-server.manpages b/debian/gnupg-wks-server.manpages
new file mode 100644
index 0..5bd206c91
--- /dev/null
+++ 

Bug#862236: Xen jessie testing

[Stefan Bühler]

On Thu, 11 May 2017 11:00:30 +0100 Ian Jackson
 wrote:
> [...]
> 
> The only place this seems to be used is to prepend it to
> the LD_LIBRARY_PATH in force during execution of the hotplug scripts.
> 
> This is inherited from upstream, where it is needed (I think) so that
> in non-packaged builds of Xen, on non-Debian systems, the Xen
> libraries in /usr/local are found when trying to execute the Xen tools
> inside the hotplug scripts.
> 
> Our dynamic linker is clever enough to ignore irrelevant files, so I
> think this is largely harmless.  Of course the noise in /etc ought to
> be got rid of.

[...reordered...]

> I think such a change is buster material.  For now, I suggest that I
> continue to build security updates for jessie on i386 as I am able to
> conveniently test that.
> [...]
> Obviously, feel free to try to convince me
> that this is RC for stretch.  I wouldn't want to let this slide if
> it's going to cause real trouble.

You are probably right: if it would have broken something, you'd have
gotten more reports by now.  So your conclusion sounds fine to me.

> I think this should be fixed by not dropping this setting (and
> probably the consequent LD_LIBRARY_PATH too).  Ideally via some kind
> of upstream knob but if not by a Debian patch.

> If I need to do another update to stretch (eg, a security update)
> before its release, I will simply drop this line from this file.
> 
> Does that plan seem good ?

Yes.

Thanks for looking into this!

cheers,
Stefan

Bug#862236: xen-utils-common hotplugpath.sh has architecture dependent bits

[Stefan Bühler]

Package: xen-utils-common
Version: 4.4.1-9+deb8u9
Severity: serious

Hi,

xen-utils-common contains /etc/xen/scripts/hotplugpath.sh, which
contains the architecture dependent path LIBDIR.

I just noticed because my etckeeper told me:

---
diff --git a/xen/scripts/hotplugpath.sh b/xen/scripts/hotplugpath.sh
--- a/xen/scripts/hotplugpath.sh
+++ b/xen/scripts/hotplugpath.sh
@@ -1,7 +1,7 @@
 SBINDIR="/usr/sbin"
 BINDIR="/usr/bin"
 LIBEXEC="/usr/lib/xen-common/bin"
-LIBDIR="/usr/lib/x86_64-linux-gnu"
+LIBDIR="/usr/lib/i386-linux-gnu"
 SHAREDIR="/usr/share"
 PRIVATE_BINDIR="/usr/lib/xen-common/bin"
 XENFIRMWAREDIR="/usr/lib/xen-common/boot"
---

And I'm pretty sure I'm on amd64/x86_64 :)

I hope I picked an appropriate severity level.  If nothing needs the
LIBDIR (which I don't know) it probably should be dropped, otherwise
this update is going to break something.

cheers,
Stefan

Bug#861313: fixed in linux 3.16.43-2

[Stefan Bühler]

Hi,

the update indeed fixes the issue. Thanks!

Cheers,
Stefan

On 04/30/2017 01:36 PM, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:linux package:
> 
> #861313: kernel BUG with kvm
> 
> It has been closed by Ben Hutchings .

Bug#861313: kernel BUG with kvm

[Stefan Bühler]

Package: linux-image-3.16.0-4-amd64
Version: 3.16.43-1
Severity: serious

Hi,

upgrading to 3.16.43-1 led to a "kernel BUG" after kvm virtual machines
started. Downgrading to 3.16.39-1+deb8u2 fixed the issue.

The "BUG" lines in short (see attached file for full log):

---
Apr 27 11:11:42 audria kernel: BUG: Bad page state in process qemu-system-x86  
pfn:7e4d00
Apr 27 11:11:42 audria kernel: BUG: Bad page state in process qemu-system-x86  
pfn:7e4cfe
Apr 27 11:11:42 audria kernel: BUG: Bad page state in process qemu-system-x86  
pfn:7e4cfc
Apr 27 11:11:42 audria kernel: BUG: Bad page state in process qemu-system-x86  
pfn:7e4cf8
Apr 27 11:11:42 audria kernel: BUG: Bad page state in process qemu-system-x86  
pfn:7e4cf0
Apr 27 11:11:42 audria kernel: BUG: Bad page state in process qemu-system-x86  
pfn:7e4ce0
Apr 27 11:11:42 audria kernel: BUG: Bad page state in process qemu-system-x86  
pfn:7e4cc0
Apr 27 11:11:42 audria kernel: BUG: Bad page state in process qemu-system-x86  
pfn:7e4c80
Apr 27 11:11:42 audria kernel: BUG: unable to handle kernel NULL pointer 
dereference at 0003
Apr 27 11:11:42 audria kernel: kernel BUG at 
/build/linux-em8VbH/linux-3.16.43/arch/x86/kernel/traps.c:729!
Apr 27 11:11:42 audria kernel: invalid opcode:  [#2] SMP 
---

Cheers,
Stefan

Apr 27 11:11:40 audria kernel: [ cut here ]
Apr 27 11:11:40 audria kernel: WARNING: CPU: 4 PID: 2684 at 
/build/linux-em8VbH/linux-3.16.43/arch/x86/kvm/mmu.c:615 
mmu_spte_clear_track_bits+0x9c/0x110 [kvm]()
Apr 27 11:11:40 audria kernel: Modules linked in: vhost_net vhost macvtap 
macvlan tun bridge stp llc ip6t_REJECT ip6table_filter ip6_tables xt_comment 
ipt_REJECT xt_LOG xt_limit xt_conntrack iptable_filter xt_nat xt_tcpudp 
iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack 
iptable_mangle ip_tables x_tables zfs(PO) zunicode(PO) zcommon(PO) znvpair(PO) 
spl(O) zavl(PO) x86_pkg_temp_thermal intel_powerclamp intel_rapl coretemp 
sha256_ssse3 sha256_generic dm_crypt kvm_intel kvm crc32_pclmul aesni_intel 
aes_x86_64 lrw gf128mul glue_helper eeepc_wmi asus_wmi sparse_keymap 
ablk_helper rfkill cryptd evdev serio_raw iTCO_wdt iTCO_vendor_support ppdev 
lpc_ich mfd_core tpm_infineon battery tpm_tis shpchp ie31200_edac edac_core 
parport_pc parport tpm video processor button wmi fuse autofs4 ext4 crc16 
mbcache
Apr 27 11:11:40 audria kernel:  jbd2 dm_mod raid1 md_mod sg sd_mod crc_t10dif 
crct10dif_generic ahci crct10dif_pclmul crct10dif_common libahci crc32c_intel 
libata ehci_pci i2c_i801 ehci_hcd xhci_hcd r8169 i2c_core scsi_mod mii usbcore 
usb_common fan thermal thermal_sys
Apr 27 11:11:40 audria kernel: CPU: 4 PID: 2684 Comm: qemu-system-x86 Tainted: 
P   O  3.16.0-4-amd64 #1 Debian 3.16.43-1
Apr 27 11:11:40 audria kernel: Hardware name: System manufacturer System 
Product Name/P8H77-M PRO, BIOS 9002 05/30/2014
Apr 27 11:11:40 audria kernel:   81514201 
 0009
Apr 27 11:11:40 audria kernel:  81068877 0007e4c000f5 
007e4c00 8807f420
Apr 27 11:11:40 audria kernel:  8800 0001 
a03e205c 8807ebece040
Apr 27 11:11:40 audria kernel: Call Trace:
Apr 27 11:11:40 audria kernel:  [] ? dump_stack+0x5d/0x78
Apr 27 11:11:40 audria kernel:  [] ? 
warn_slowpath_common+0x77/0x90
Apr 27 11:11:40 audria kernel:  [] ? 
mmu_spte_clear_track_bits+0x9c/0x110 [kvm]
Apr 27 11:11:40 audria kernel:  [] ? drop_spte+0x17/0xa0 [kvm]
Apr 27 11:11:40 audria kernel:  [] ? 
drop_large_spte.isra.82+0x6c/0xa0 [kvm]
Apr 27 11:11:40 audria kernel:  [] ? 
__direct_map.isra.100+0xb8/0x230 [kvm]
Apr 27 11:11:40 audria kernel:  [] ? 
tdp_page_fault+0x1bc/0x200 [kvm]
Apr 27 11:11:40 audria kernel:  [] ? 
kvm_mmu_page_fault+0x1f/0x130 [kvm]
Apr 27 11:11:40 audria kernel:  [] ? 
vmx_handle_exit+0xb5/0xa30 [kvm_intel]
Apr 27 11:11:40 audria kernel:  [] ? 
reboot_interrupt+0x80/0x80
Apr 27 11:11:40 audria kernel:  [] ? 
vmx_invpcid_supported+0x20/0x20 [kvm_intel]
Apr 27 11:11:40 audria kernel:  [] ? 
kvm_arch_vcpu_ioctl_run+0xc67/0x11a0 [kvm]
Apr 27 11:11:40 audria kernel:  [] ? get_futex_key+0x1df/0x2c0
Apr 27 11:11:40 audria kernel:  [] ? futex_wake+0x6f/0x120
Apr 27 11:11:40 audria kernel:  [] ? 
kvm_arch_vcpu_load+0x46/0x1a0 [kvm]
Apr 27 11:11:40 audria kernel:  [] ? 
kvm_vcpu_ioctl+0x2f1/0x5b0 [kvm]
Apr 27 11:11:40 audria kernel:  [] ? 
put_prev_entity+0x57/0x350
Apr 27 11:11:40 audria kernel:  [] ? set_next_entity+0x56/0x70
Apr 27 11:11:40 audria kernel:  [] ? do_vfs_ioctl+0x2cf/0x4b0
Apr 27 11:11:40 audria kernel:  [] ? SyS_futex+0x6e/0x150
Apr 27 11:11:40 audria kernel:  [] ? SyS_ioctl+0x81/0xa0
Apr 27 11:11:40 audria kernel:  [] ? 
system_call_fast_compare_end+0x10/0x15
Apr 27 11:11:40 audria kernel: ---[ end trace f3debdcfae06e5ef ]---
Apr 27 11:11:41 audria ntpd[2346]: Listen normally on 10 vm_XX 
[fe80::fc54:ff:fe20:1609%5]:123
Apr 27 11:11:41 audria ntpd[2346]: Listen normally on 11 

Bug#857255: lighttpd: mod_scgi: out of bounds read in scgi_demux_response

[Stefan Bühler]

Hi Helmut,

On 03/09/2017 10:06 AM, Helmut Grohne wrote:
> Package: lighttpd
> Version: 1.4.45-1
> Tags: security patch
> 
> While debugging a problem with lighttpd on behalf of my current employer
> Intenta GmbH, I found an out of bounds read.
> 
> http://sources.debian.net/src/lighttpd/1.4.45-1/src/mod_scgi.c/#L1828
> | for (c = hctx->response_header->ptr, cp = 0, used = 
> buffer_string_length(hctx->response_header); used; c++, cp++, used--) {
> | if (*c == ':') in_header = 1;
> | else if (*c == '\n') {
> | if (in_header == 0) {
> | /* got a response without a 
> response header */
> |
> | c = NULL;
> | header_end = 1;
> | break;
> | }
> |
> | if (eol == EOL_UNSET) eol = EOL_N;
> |
> | if (*(c+1) == '\n') {
> | header_end = 1;
> | hlen = cp + 2;
> | break;
> | }
> |
> | } else if (used > 1 && *c == '\r' && *(c+1) == 
> '\n') {
> 
> The loop is constructed such that up to `used` bytes can be read
> starting from `c`. Thus the access to `*c` is ok. However accessing
> `*(c+1)` may be out of bounds. The condition should check for `used > 1`
> before accessing `*(c+1)`. Both the later condition checking for CR LF
> in the excerpt above and an even later condition checking for double CR
> LF do check for sufficient buffer contents. It's only this one
> occurrence that misses the check. In practise, this can result in
> lighttpd sending corrupted responses to its clients when its SCGI reads
> are chunked in a bad way (i.e. they end with '\n').

Since a buffer-API-refactoring some time ago all buffers should be
NUL-terminated.  I.e. if `*c == '\n'` is true `c` must not point to the
last character of the buffer.

If you have reason to believe otherwise please let us know :)

If you managed to trigger this in some older version we'd be interested
to know about it too - some dists are using pretty old versions.

> The following patch fixes the problem:
> --- a/src/mod_scgi.c
> +++ b/src/mod_scgi.c
> @@ -1826,7 +1826,7 @@
> 
>   if (eol == EOL_UNSET) eol = EOL_N;
> 
> - if (*(c+1) == '\n') {
> + if (used > 1 && *(c+1) == '\n') {
>   header_end = 1;
>   hlen = cp + 2;
>   break;

Patch looks fine though.

- Stefan

Bug#849813: zfs-zed.service can't start

[Stefan Bühler]

On Sat, 31 Dec 2016 12:24:20 + Rho YounJae  wrote:
> Package: zfs-zed
> Version: 0.6.5.8-2~bpo8+1
> Severity: minor
> 
> Dear Maintainer,
> 
> zfs-zed.service can't start since there is no /sbin/zed

This bug is also present in testing, and a package with the only 
purpose of running a daemon is unusable if it cannot run the daemon...

The systemd file is generated, and needs to be patched somehow. Or 
moving zed to /usr/sbin needs to be reverted.

Also see:
https://anonscm.debian.org/cgit/pkg-zfsonlinux/zfs.git/tree/etc/systemd/system/zfs-zed.service.in?h=debian/0.6.5.8-2

Bug#846917: fix debian packaging for lighttpd 1.4.43

[Stefan Bühler]

Hi again,

adding "Multi-Arch: foreign" to lighttpd-doc should fix a lintian warning.

To fix the build hardening warnings I added this to the configure call:

CPPFLAGS_FOR_BUILD="$(shell dpkg-buildflags --get CPPFLAGS)" \
CFLAGS_FOR_BUILD="$(shell dpkg-buildflags --get CFLAGS)" \
LDFLAGS_FOR_BUILD="$(shell dpkg-buildflags --get LDFLAGS)" \

There are probably better ways to set them (lemon is build using
*_FOR_BUILD to support proper cross compilation).

Bug#846917: fix debian packaging for lighttpd 1.4.43

[Stefan Bühler]

Package: lighttpd
Version: 1.4.43-1
Severity: serious

Hi,

the debian package for 1.4.43 is in a very sad state (one could say
similar to the upstream release itself...).

See attached patch for what we're using to build packages for
https://debian.lighttpd.net/

- debian stable doesn't know default-libmysqlclient-dev
- add new dependencies
- init script still present, no need for systemd: #846299
- don't recommend php5-cgi - should not get installed automatically imho
- new packages for new modules

Sadly ldap and mysql mod_authn_* modules are required as soon as you
load mod_auth in 1.4.43; this is fixed in git head.

Overall I'd recommend waiting for 1.4.44 or picking some fixes from git
head; there are some quite severe bugs in 1.4.43.

Also we're using the .tar.xz - maybe update the watch file; and https
should work on download.lighttpd.net/ too.

regards,
Stefan
diff -urN lighttpd-1.4.43/debian/control new/debian/control
--- lighttpd-1.4.43/debian/control	2016-11-26 06:09:35.0 +0100
+++ new/debian/control	2016-12-04 10:33:00.249171410 +0100
@@ -18,7 +18,8 @@
  libbz2-dev,
  libattr1-dev,
  libpcre3-dev,
- default-libmysqlclient-dev,
+ libmemcached-dev,
+ default-libmysqlclient-dev | libmysqlclient-dev,
  libfam-dev,
  libldap2-dev,
  libfcgi-dev,
@@ -29,6 +30,7 @@
  libsqlite3-dev,
  libxml2-dev,
  libkrb5-dev,
+ libgeoip-dev,
  perl,
  libcgi-pm-perl,
 Vcs-Git: git://anonscm.debian.org/pkg-lighttpd/lighttpd.git
@@ -41,11 +43,11 @@
 # That's a false positive these days
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}, ${perl:Depends},
- lsb-base (>= 3.0-6), systemd (>= 29.1), mime-support,
+ lsb-base (>= 3.0-6) | systemd (>= 29.1), mime-support,
  libterm-readline-perl-perl
 Provides: httpd, httpd-cgi
-Suggests: openssl, rrdtool, apache2-utils, lighttpd-doc
-Recommends: spawn-fcgi, php5-cgi
+Suggests: openssl, rrdtool, apache2-utils, lighttpd-doc, php5-cgi
+Recommends: spawn-fcgi
 Description: fast webserver with minimal memory footprint
  lighttpd is a small webserver and fast webserver developed with
  security in mind and a lot of features.
@@ -126,3 +128,34 @@
   MKCOL
   DELETE
   PUT
+
+Package: lighttpd-mod-authn-gssapi
+Architecture: any
+Depends: lighttpd (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
+Description: GGSAPI authentication for lighttpd
+ This package contains the authn_gssapi module for lighttpd. With
+ this module, it is possible to perform GSSAPI authentication.
+
+Package: lighttpd-mod-authn-ldap
+Architecture: any
+Depends: lighttpd (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
+Description: LDAP authentication for lighttpd
+ This package contains the authn_ldap module for lighttpd. With
+ this module, it is possible to perform authentication against an LDAP
+ server.
+
+Package: lighttpd-mod-authn-mysql
+Architecture: any
+Depends: lighttpd (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
+Description: MySQL authentication for lighttpd
+ This package contains the authn_mysql module for lighttpd. With
+ this module, it is possible to perform authentication using a MySQL
+ table.
+
+Package: lighttpd-mod-geoip
+Architecture: any
+Depends: lighttpd (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
+Description: GeoIP restrictions for lighttpd
+ This package contains the geoip module for lighttpd. With
+ this module, it is possible to distinguish users based on the location
+ using a GeoIP database.
diff -urN lighttpd-1.4.43/debian/lighttpd.install new/debian/lighttpd.install
--- lighttpd-1.4.43/debian/lighttpd.install	2016-11-26 06:09:35.0 +0100
+++ new/debian/lighttpd.install	2016-12-04 10:31:51.431727218 +0100
@@ -4,8 +4,10 @@
 debian/tmp/usr/lib/lighttpd/mod_accesslog.so
 debian/tmp/usr/lib/lighttpd/mod_alias.so
 debian/tmp/usr/lib/lighttpd/mod_auth.so
+debian/tmp/usr/lib/lighttpd/mod_authn_file.so
 debian/tmp/usr/lib/lighttpd/mod_cgi.so
 debian/tmp/usr/lib/lighttpd/mod_compress.so
+debian/tmp/usr/lib/lighttpd/mod_deflate.so
 debian/tmp/usr/lib/lighttpd/mod_dirlisting.so
 debian/tmp/usr/lib/lighttpd/mod_evasive.so
 debian/tmp/usr/lib/lighttpd/mod_evhost.so
@@ -25,6 +27,7 @@
 debian/tmp/usr/lib/lighttpd/mod_ssi.so
 debian/tmp/usr/lib/lighttpd/mod_staticfile.so
 debian/tmp/usr/lib/lighttpd/mod_status.so
+debian/tmp/usr/lib/lighttpd/mod_uploadprogress.so
 debian/tmp/usr/lib/lighttpd/mod_userdir.so
 debian/tmp/usr/lib/lighttpd/mod_usertrack.so
 debian/lighttpd.conf/etc/lighttpd
diff -urN lighttpd-1.4.43/debian/lighttpd-mod-authn-gssapi.install new/debian/lighttpd-mod-authn-gssapi.install
--- lighttpd-1.4.43/debian/lighttpd-mod-authn-gssapi.install	1970-01-01 01:00:00.0 +0100
+++ new/debian/lighttpd-mod-authn-gssapi.install	2016-10-31 11:31:01.0 +0100
@@ -0,0 +1 @@
+debian/tmp/usr/lib/lighttpd/mod_authn_gssapi.so
diff -urN lighttpd-1.4.43/debian/lighttpd-mod-authn-ldap.install new/debian/lighttpd-mod-authn-ldap.install
--- 

Bug#844496: seccomp "Invalid argument" due to old library version

[Stefan Bühler]

Package: libseccomp
Version: 2.3.1-2

Hi,

pdns.service (from pdns-server in testing) didn't start anymore with
this message:

pdns.service: Failed at step SECCOMP spawning /usr/sbin/pdns_server: Invalid 
argument

Updating libseccomp2 from 2.1.1-1 (stable) to 2.3.1-2 (testing) fixed
it.

systemd 232-3 has a build dependency `libseccomp-dev (>= 2.2.3-3~)`, but
the resulting package only depends on `libseccomp2 (>= 2.1.0)`.

I guess systemd uses a feature from newer libseccomp versions which
wasn't tracked by the symbols file.  Maybe you should consider upgrading
the minimum versions in the symbols file.  (Probably broken in backports
too.)

regards,
Stefan

Bug#844497: seccomp "Invalid argument" due to old library version

[Stefan Bühler]

Package: systemd
Version: 232-3

Hi,

pdns.service (from pdns-server in testing) didn't start anymore with
this message:

pdns.service: Failed at step SECCOMP spawning /usr/sbin/pdns_server: Invalid 
argument

(See http://sources.debian.net/src/pdns/4.0.1-5/pdns/pdns.service.in/
for the service configuration.)

Updating libseccomp2 from 2.1.1-1 (stable) to 2.3.1-2 (testing) fixed
it.

systemd 232-3 has a build dependency `libseccomp-dev (>= 2.2.3-3~)`, but
the resulting package only depends on `libseccomp2 (>= 2.1.0)`.

I filed a bug with libseccomp too, and maybe they'll fix their symbols
file for future builds.

In the meantime I suggest adding an explicit minimum libseccomp2
dependency.  Given the same build dependency in 230-7~bpo8+2 this is
probably broken in jessie-backports too.

regards,
Stefan

Bug#836822: ocsptool --ask output corrupted

[Stefan Bühler]

Package: gnutls-bin
Version: 3.3.8-6+deb8u3

The output file containing the DER-encoded OCSP response starts with a
newline; ocsptool itself can't read the file anymore, failing with:

importing response: ASN1 parser: Error in TAG.

This was fixed upstream in commit e95d7d1a (first released with 3.5.0):

https://gitlab.com/gnutls/gnutls/commit/e95d7d1aca6f5e078f354c22b85d961ded8e16a1

with commit message:

> ocsptool: Allow saving responses even if verification fails
>
> In addition do not enter a spurious newline to responses.

Somehow the more important thing was not the subject :(

As this never worked before I'm not assigning any severity.

Not sure how to tell the bug tracker that stretch/sid are not
affected :)

Bug#836371: ocsptool --ask segfault

[Stefan Bühler]

Package: gnutls-bin
Version: 3.5.3-3
Severity: important

Hi,

the "STARTTLS-fix" makes ocsptool segfault as it tries to use a NULL
session.

I think the following upstream commit tries to fix it, but did not test
it:


https://gitlab.com/gnutls/gnutls/commit/4d8e1f716794bf7ca267091bb2017dfd73770762

I could provide a backtrace if needed, but it really crashes everytime
you have it send a request (i.e. --ask).

Bug#835342: curl or git clone commands throws "gnutls_handshake() failed" on https targets

[Stefan Bühler]

Hi Marcelo,

On Fri, 26 Aug 2016 10:30:51 -0400 "marcelomen...@gmail.com"
 wrote:
> 2016-08-25 13:25 GMT-04:00 Andreas Metzler :
> > On 2016-08-24 "marcelomen...@gmail.com" 
> > wrote:
> >> Package: libgnutls30
> >> Version: 3.5.3-2
> >> Severity: important
> >> Tags: upstream
> >
> >> Dear Maintainer,
> >
> >> Trying to git clone a github repo using libgnutls30 3.5.3-2 throw
> >> the following error:
> >
> >> fatal: unable to access 'https://github.com/xxx/yyy/':
> >> gnutls_handshake() failed: Public key signature verification has
> >> failed.
> >
> >> Same happens for curl:
> >
> >> curl https://duckduckgo.com
> >> curl: (35) gnutls_handshake() failed: Public key signature
> >> verification has failed.
> >
> > Hello,
> > Are you able to reproduce either of these errors with gnutls-cli?
> 
> First, let me say I'm behind a proxy server.

Does the proxy happen to intercept TLS, i.e. is it a local CA and
creates certificates on demand, which might fail the verification?

Perhaps you could get a pcap with tcpdump of the connection(s) from
curl to the proxy?

tcpdump -i eno1 -w curl-to-proxy.pcap 'host  and port 
'

> Both versions of gnutls-bin (3.5.3-3 and the old 3.5.2-3) have the
> same behavior:
> 
> gnutls-cli -V --port 443 duckduckgo.com
> Processed 173 CA certificate(s).
> Resolving 'duckduckgo.com:443'...
> Connecting to '107.21.1.61:443'...
> Connecting to '184.72.106.52:443'...
> Connecting to '184.72.115.86:443'...
> 
> and stay there for some quit some time until I ctrl+c

I don't think gnutls-cli supports a proxy directly; you'd probably
have to use some LD_PRELOAD proxy wrapper (e.g. tsocks or similar).

Bug#821787: cleanup libusb when open fails

[Stefan Bühler]

Package: libccid
Version: 1.4.22-1
Tags: patch
Severity: important

Hi,

after suspend/resume pcscd burns a core:

---
[pid 23458] poll([{fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 2, 4294967295) 
= 1 ([{fd=5, revents=POLLIN}])
[pid 23458] recvmsg(11, 0x7f0332553d80, 0) = -1 EAGAIN (Resource temporarily 
unavailable)
[pid 23458] poll([{fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 2, 4294967295) 
= 1 ([{fd=5, revents=POLLIN}])
[pid 23458] recvmsg(11, 0x7f0332553d80, 0) = -1 EAGAIN (Resource temporarily 
unavailable)
---

Some rounds of debugging and reading source lead me to a bug in ccid:
after initializing a certain reader failed pcscd unloads ccid, which
unloads libusb without proper cleanup.

This leads to various race conditions if libusb gets loaded again
later, and might crash pcscd in other cases.

---
Apr 19 10:08:13 $hostname systemd[1]: Started PC/SC Smart Card Daemon.
Apr 19 10:08:13 $hostname pcscd[10047]:  
ifdhandler.c:144:CreateChannelByNameOrChannel() failed
Apr 19 10:08:13 $hostname pcscd[10047]: 0036 
readerfactory.c:1097:RFInitializeReader() Open Port 0x20 Failed 
(usb:0a5c/5800:libudev:0:/dev/bus/usb/004/003)
Apr 19 10:08:13 $hostname pcscd[10047]: 0004 
readerfactory.c:372:RFAddReader() Broadcom Corp 5880 [Broadcom USH] 
(0123456789ABCD) init failed.
---

See attached patch for a fix.

- Stefan
Description: cleanup libusb when open fails
 When OpenUSBByName fails it needs to call close_libusb_if_needed to
 cleanup the libusb context. Otherwise variouses resources (memory, file
 descriptors) leak and the linux_udev_event_thread_main thread keeps
 running when libccid gets dlclosed(). This results in very ugly race
 conditions if the library gets loaded again and
 linux_udev_event_thread_main gets started a second time.
 .
 This might resolve a number of issues involving pcscs crashing or
 burning 100% CPU: debian #749584, debian #718473, ubuntu #1296288
Author: Stefan Bühler 
Last-Update: 2016-04-19
--- ccid-1.4.22.orig/src/ccid_usb.c
+++ ccid-1.4.22/src/ccid_usb.c
@@ -724,6 +724,9 @@ end:
 			goto again_libusb;
 		}
 #endif
+
+		if (ctx) close_libusb_if_needed();
+
 		if (claim_failed)
 			return STATUS_COMM_ERROR;
 		DEBUG_INFO1("Device not found?");
@@ -739,6 +742,8 @@ end2:
 	libusb_free_device_list(devs, 1);
 
 end1:
+	if (ctx) close_libusb_if_needed();
+
 	/* free bundle list */
 	bundleRelease();
 


pgp2xvSFgZ4Nu.pgp
Description: OpenPGP digital signature

Bug#815148: sympa fails to send encrypted messages: Unable to send message to list

[Stefan Bühler]

Hi,

while my first patch fixes the syntax error, the logic in that function
is still completely flawed: it will return an error if there is more
than one subscriber when it has to re-encrypt the message.

Please see attached patch for a fix which actually can handle more than
one subscriber; but it will ignore errors as long as it can enqueue the
mail to at least one subscriber successfully.

I have been delivering some emails with that patch (about 20
subscribers) and so far it seems to be working fine.

regards,
Stefan
--- /a/usr/share/sympa/lib/mail.pm	2015-01-16 00:00:00.0 +
+++ /b/usr/share/sympa/lib/mail.pm	2016-02-23 10:56:51.286472269 +
@@ -602,14 +602,17 @@
 my $msg;
 
 if ($encrypt eq 'smime_crypted') {
-# encrypt message for each rcpt and send the message
+	my $result_all;
+	# encrypt message for each rcpt and send the message
 	# this MUST be moved to the bulk mailer. This way, merge will be applied after the SMIME encryption is applied ! This is a bug !
 	foreach my $unique_rcpt (@{$rcpt}) {
-	my $email = lc(@{$unique_rcpt}[0]);
-	if (($email !~ /@/) || ($#{@$unique_rcpt} != 0)) {
-		do_log('err',"incorrect call for encrypt with incorrect number of recipient"); 
+	  foreach my $single_rcpt (@{$unique_rcpt}) {
+	my $email = lc($single_rcpt);
+	if ($email !~ /@/) {
+		do_log('err',"incorrect call for encrypt with incorrect number of recipient (email: %s)", $email);
+		#do_log('err',"incorrect call for encrypt with incorrect number of recipient"); 
 		# internal check, if encryption is on packet should be unique and shoud contain only one rcpt 
-		return undef;
+			next; # return undef;
 	}
 	my $encrypted_msg_as_string;
 	if ($encrypted_msg_as_string = ::smime_encrypt ($msg_header, $msg_body, $email)){
@@ -622,13 +625,15 @@
 			 'delivery_date' =>  $delivery_date,
 			 'use_bulk' => $use_bulk,
 			 'tag_as_last' => $tag_as_last);
-		return $result;
+		$result_all = ($result_all || $result); # return $result;
 	}else{
 		Log::do_log('err','Unable to encrypt message to list %s for recipient %s',$listname,$email);
-		return undef;
+		next; # return undef;
 	}
-	$tag_as_last = 0;
+	# $tag_as_last = 0;
+	  }
 	}
+	return $result_all;
 }else{
 	$msg = $msg_header->as_string . "\n" . $msg_body;   
 	if ($msg) {

Bug#815148: sympa fails to send encrypted messages: Unable to send message to list

[Stefan Bühler]

Package: sympa
Version: 6.1.23~dfsg-2

Hi,

sympa fails to send encrypted messages due to a bug in mail.pm:609; you
should not dereference array-references in $#{...}, it takes the
reference directly (according to my tests. I couldn't find official
documentation on it, just an example in
http://perldoc.perl.org/perlref.html#Postfix-Dereference-Syntax)

The error is hidden by the eval in sympa.pl.in:2016; the logging in
line 2022 should probably log $@ as well.

When logging $@ as well I get:

err main::DoMessage() sympa::DoMessage(): Unable to send message to list 
mylist: Can't use string ("1") as an ARRAY ref while "strict refs" in use at 
/usr/share/sympa/lib/mail.pm line 609.

Regards,
Stefan
--- src/lib/mail.pm.bak	2016-02-19 12:18:52.747140435 +0100
+++ src/lib/mail.pm	2016-02-19 12:19:00.123037994 +0100
@@ -606,7 +606,7 @@
 	# this MUST be moved to the bulk mailer. This way, merge will be applied after the SMIME encryption is applied ! This is a bug !
 	foreach my $unique_rcpt (@{$rcpt}) {
 	my $email = lc(@{$unique_rcpt}[0]);
-	if (($email !~ /@/) || ($#{@$unique_rcpt} != 0)) {
+	if (($email !~ /@/) || ($#{$unique_rcpt} != 0)) {
 		do_log('err',"incorrect call for encrypt with incorrect number of recipient"); 
 		# internal check, if encryption is on packet should be unique and shoud contain only one rcpt 
 		return undef;

Bug#815138: sympa-archiver loops with encrypted messages

[Stefan Bühler]

Package: sympa
Version: 6.1.23~dfsg-2

Hi,

when trying to archive an encrypted messages, sympa will try to "clean"
the message, but as it doesn't lookup the list context in Message->new
(due to $noxsympato = 1) it doesn't pass the list to
tools::smime_decrypt - which then tries to use the keys for a global
list "sympa" (without vhost).

As the archiver keeps trying to handle failed messages, it will try
forever to handle the message.

There are two options here imho: either Message->new needs to lookup
the list context (or take it as parameter instead of $noxsympato) and
decrypts mails for the archive, or Message->new must not try to
decrypt mails for the archive.

See patch for the latter option.

Regards,
Stefan

syslog snippet:
---
notice Archiving listn...@example.com.someid for list listn...@example.com
err tools::smime_find_keys() unable to opendir /var/lib/sympa/list_data/sympa: 
No such file or directory
err tools::smime_decrypt() Unable to decrypt message : missing certificate file
err Archive::clean_archived_message() Unable to create a Message object with 
file /var/lib/sympa/wwsarchive/listn...@example.com/2016-02/arctxt/1
err main::mail2arc() Could not clean message, ignoring message
---
--- Message.pm	2016-02-19 10:46:14.971013121 +0100
+++ Message.pm	2016-02-19 10:46:40.194243252 +0100
@@ -274,7 +274,7 @@
 }
 
 ## S/MIME
-if ($Conf::Conf{'openssl'}) {
+if ($Conf::Conf{'openssl'} && !(defined $noxsympato)) {
 
 	## Decrypt messages
 	if (($hdr->get('Content-Type') =~ /application\/(x-)?pkcs7-mime/i) &&

Bug#813000: apt complains about corrupted index files even after multiple updates

[Stefan Bühler]

Hi,

On Sat, 30 Jan 2016 15:03:27 +0100
Julian Andres Klode <j...@debian.org> wrote:

> On 30 January 2016 at 13:42, Stefan Bühler <stbueh...@web.de> wrote:
> > [...]
> > ==890== Conditional jump or move depends on uninitialised value(s)
> > ==890==at 0x4F4D8A0: pkgCache::ReMap(bool const&)
> > (in /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0.0)> >
> > [...]
> > I managed to track down the code (pkgCache::ReMap+0x2d0) in gdbs
> > disassembly to pkgcache.cc:199:
> >   if (hash != HeaderP->CacheFileSize)  
> 
> That's not an issue, it's expected. We mmap() the memory, and then
> hash the entire memory we mapped, as that's what we are writing to the
> disk. It does not matter that there are uninitialized values in there,
> we just want to check that if we have written it to a file and read it
> back, that it's the same.

That is sad; I can see now that it should work, but it would be nice if
this could be fixed one day.

> > Disabling lz4 seems to fix the issue (but not the valgrind report):
> >
> >   echo 'APT::Compressor::lz4::Cost "5000";'
> > > /etc/apt/apt.conf.d/disable-lz4 rm /var/lib/apt/lists/*.lz4
> >   apt-get update  
> 
> OK. Not sure how that happens.

I might add that the docker/debootstrap combo sets (among others) the
following options by default:

Acquire::GzipIndexes "true";
Acquire::CompressionTypes::Order:: "gz";

I think in fileutl.cc Lz4FileFdPrivate::InternalOpen() needs to reset
next_to_load = APT_BUFFER_SIZE, as otherwise a Seek() after reaching
end of file won't read anything anymore due to next_to_load == 0.

Would this bug explain the issue we are seeing here?

Kind regards,
Stefan

Bug#813000: apt complains about corrupted index files even after multiple updates

[Stefan Bühler]

Hi,

On Thu, 28 Jan 2016 12:53:18 + Rohan Garg 
wrote:
> Package: apt
> Version: 1.2.1
> Severity: important
> 
> Dear Maintainer,
> 
> It seems that after the 1.2.1 update apt fails to install packages
> even after multiple 'apt update' calls.
> 
> I constantly see this error on the console output :
> 
> E: The package index files are corrupted. No Filename: field for
> package libpopt0.

I can confirm similar problems. The affected package varies from time
to time, sometimes it doesn't fail at the "Filename: " but claims a
downloaded file has wrong file size or even downloads completely
unrelated packages.

All this happens when I try to install many packages at once in a fresh
docker environment (created with debootstrap).

I got some valgrind backtraces:

First issue (patch to fix it attached):

==890== Mismatched free() / delete / delete []
==890==at 0x4C2B30B: operator delete(void*) (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==890==by 0x4EDCA0A: DirectFileFdPrivate::~DirectFileFdPrivate() (in 
/usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0.0)
[...]
==890==  Address 0x709bb00 is 0 bytes inside a block of size 4,096 alloc'd
==890==at 0x4C2A8CF: operator new[](unsigned long) (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==890==by 0x4EDD6AB: FileFdPrivate::FileFdPrivate(FileFd*) (in 
/usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0.0)
[...]

Second issue (with some offsets between):

0x4E36000: /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0.0
 +0x1175d0: pkgCache::ReMap
==890== Conditional jump or move depends on uninitialised value(s)
==890==at 0x4F4D8A0: pkgCache::ReMap(bool const&) (in 
/usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0.0)
 at pkgCache::ReMap+0x2d0 (0x1178a0)
==890==by 0x4F55467: pkgCacheGenerator::pkgCacheGenerator(DynamicMMap*, 
OpProgress*) (in /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0.0)
==890==by 0x4F575EF: pkgCacheGenerator::MakeStatusCache(pkgSourceList&, 
OpProgress*, MMap**, pkgCache**, bool) (in 
/usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0.0)
==890==by 0x4EBA907: pkgCacheFile::BuildCaches(OpProgress*, bool) (in 
/usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0.0)
==890==by 0x4EC0742: 
APT::CacheSetHelper::PackageFromPackageName(APT::PackageContainerInterface*, 
pkgCacheFile&, std::__cxx11::basic_string) (in /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0.0)
==890==by 0x4EC0D40: 
APT::CacheSetHelper::PackageFrom(APT::CacheSetHelper::PkgSelector, 
APT::PackageContainerInterface*, pkgCacheFile&, 
std::__cxx11::basic_string 
const&) (in /usr/lib/x86_64-linux-gnu/libapt-pkg.so
.5.0.0)
==890==by 0x4EBD749: 
APT::CacheSetHelper::PackageFromString(APT::PackageContainerInterface*, 
pkgCacheFile&, std::__cxx11::basic_string const&) (in 
/usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0.0)
==890==by 0x4EBED3B: 
APT::VersionContainerInterface::FromString(APT::VersionContainerInterface*, 
pkgCacheFile&, std::__cxx11::basic_string, APT::CacheSetHelper::VerSelector, APT::CacheSetHelper&, 
bool) (in /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0.0)
==890==by 0x4EBFC07: 
APT::VersionContainerInterface::FromCommandLine(APT::VersionContainerInterface*,
 pkgCacheFile&, char const**, APT::CacheSetHelper::VerSelector, 
APT::CacheSetHelper&) (in /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0.0)
==890==by 0x51E071A: ShowPackage(CommandLine&) (in 
/usr/lib/x86_64-linux-gnu/libapt-private.so.0.0.0)
==890==by 0x4ECE5A5: CommandLine::DispatchArg(CommandLine::Dispatch const*, 
bool) (in /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0.0)
==890==by 0x51BFEE2: DispatchCommandLine(CommandLine&, 
std::vector 
const&) (in /usr/lib/x86_64-linux-gnu/libapt-private.so.0.0.0)

I managed to track down the code (pkgCache::ReMap+0x2d0) in gdbs
disassembly to pkgcache.cc:199:
  if (hash != HeaderP->CacheFileSize)

Disabling lz4 seems to fix the issue (but not the valgrind report):

  echo 'APT::Compressor::lz4::Cost "5000";' > /etc/apt/apt.conf.d/disable-lz4
  rm /var/lib/apt/lists/*.lz4
  apt-get update

Kind regards,
Stefan
>From 6ca05ab3df0644ae168c71591a1812b4bb0e96fc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20B=C3=BChler?= 
Date: Sat, 30 Jan 2016 12:06:02 +0100
Subject: [PATCH 1/1] fix "Mismatched free() / delete / delete []" in
 simple_buffer

---
 apt-pkg/contrib/fileutl.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/apt-pkg/contrib/fileutl.cc b/apt-pkg/contrib/fileutl.cc
index a48447b..4347c55 100644
--- a/apt-pkg/contrib/fileutl.cc
+++ b/apt-pkg/contrib/fileutl.cc
@@ -935,7 +935,7 @@ struct APT_HIDDEN simple_buffer {			/*{{{*/
   reset(4096);
}
~simple_buffer() {
-  delete buffer;
+  delete[] buffer;
}
 
const char *get() const { return buffer + 

Bug#801994: hosts stuck in refresh

[Stefan Bühler]

Hi,

I just took a look at the source and found the problem; see the
attached patch.

regards,
Stefan
Description: fix hosts stuck in refresh
 G_FILE_MONITOR_SEND_MOVED might trigger G_FILE_MONITOR_EVENT_MOVED instead
 of G_FILE_MONITOR_EVENT_DELETED + G_FILE_MONITOR_EVENT_CREATED, and MOVED
 is not handled by stats_changed().
Author: Stefan Bühler 
Bug-Debian: https://bugs.debian.org/801994
--- apt-dater-1.0.2+git20150804.orig/src/stats.c
+++ apt-dater-1.0.2+git20150804/src/stats.c
@@ -64,7 +64,7 @@ stats_changed(GFileMonitor *monitor,
 
 void stats_initialize(HostNode *n) {
   GFile *path = g_file_new_for_path(n->statsfile);
-  n->mon_stats = g_file_monitor(path, G_FILE_MONITOR_SEND_MOVED, NULL, NULL);
+  n->mon_stats = g_file_monitor(path, G_FILE_MONITOR_NONE, NULL, NULL);
   g_object_unref(path);
 
   g_signal_connect(n->mon_stats, "changed", G_CALLBACK(stats_changed), n);

Bug#801994: hosts stuck in refresh

[Stefan Bühler]

Hi,

On Mon, 26 Oct 2015 17:51:25 +0100
Patrick Matthäi <pmatth...@debian.org> wrote:

> Am 16.10.2015 um 20:23 schrieb Stefan Bühler:
> > Package: apt-dater
> > Version: 1.0.2+git20150804-1
> > 
> > Hi,
> > 
> > every host I refresh stays in refresh forever, until i force close
> > apt-dater and restart. after a restart it seems to have the correct
> > package states.
> > 
> > On the server I saw "/usr/bin/perl /usr/bin/apt-dater-host refresh"
> > running at first, and then it finished.
> >   
> 
> What processes are running on the machine where you have invoked
> apt-dater itself? Do you have got this problem everytime?
> 

It have this problem at home, at work, everytime, not a single refresh
succeeds. Although I usually use "aptitude" as DPKGTOOL I just tried
one host with "apt-get", but it doesn't change anything.

When I start the refresh I see this for every host:

/bin/sh /usr/lib/x86_64-linux-gnu/apt-dater/cmd
 \_ /usr/bin/ssh -t -n -o BatchMode=yes -o ConnectTimeout=5 -l root $hostname 
apt-dater-host refresh

After a while they finish, but nothing happens in the apt-dater ui.
Please note that these processes do not appear as children of apt-dater
in "ps aufx".

I ran one of the ssh commands directly, and the remote end isn't happy
about the "-t" flag (first output line: "Pseudo-terminal will not be
allocated because stdin is not a terminal."). Apart from that the
output looks fine afaict. To get rid of the "-t" flag I need to
explicitly set opt-cmd-flags="" (which doesn't fix the problem either).

I tracked the end of one refresh with strace, and it successfully read
the status from a pipe, wrote it into ".stat.new" file, closed it, renamed it 
into
".stat", and unlocked and closed the ".stat.lck" file.
During all that and after the unlock inotify triggers events in the
second thread, and it seems to try to wakeup the first thread:

(5 is the [eventfd] of the second thread it seems, 7 is inotify, 3 and 6 are 
[eventfd]s too)

[pid 24033] flock(26, LOCK_UN)  = 0
[pid 24033] close(26)   = 0
[pid 24033] write(3, "\1\0\0\0\0\0\0\0", 8) = 8
[pid 24033] brk(0x1b21000)  = 0x1b21000
[pid 24033] poll([{fd=3, events=POLLIN}], 1, 0) = 1 ([{fd=3, revents=POLLIN}])
[pid 24033] select(1, [0], NULL, NULL, {0, 20} 

First thread just ignored the POLLIN event on fd 3... wtf?

[pid 24034] <... poll resumed> )= 0 (Timeout)
[pid 24034] read(5, 0x7f18aa20cd00, 16) = -1 EAGAIN (Resource temporarily 
unavailable)
[pid 24034] write(5, "\1\0\0\0\0\0\0\0", 8) = 8
[pid 24034] read(7, "\2\0\0\0\2\0\0\0\0\0\0\0 \0\0\0"..., 4096) = 240
[pid 24034] write(3, "\1\0\0\0\0\0\0\0", 8) = 8
[pid 24034] write(5, "\1\0\0\0\0\0\0\0", 8) = 8
[pid 24034] write(5, "\1\0\0\0\0\0\0\0", 8) = 8
[pid 24034] poll([{fd=5, events=POLLIN}, {fd=7, events=POLLIN}], 2, 4294967295) 
= 1 ([{fd=5, revents=POLLIN}])
[pid 24034] poll([{fd=5, events=POLLIN}, {fd=7, events=POLLIN}], 2, 4294967295) 
= 1 ([{fd=5, revents=POLLIN}])
[pid 24034] read(5, "\3\0\0\0\0\0\0\0", 16) = 8
[pid 24034] poll([{fd=5, events=POLLIN}, {fd=7, events=POLLIN}], 2, 4294967295 

[pid 24033] <... select resumed> )  = 0 (Timeout)
[pid 24033] rt_sigaction(SIGTSTP, {SIG_IGN, [], SA_RESTORER|SA_RESTART, 
0x7f18afb5d8d0}, {0x7f18aed9d4c0, [], SA_RESTORER|SA_RESTART, 0x7f18afb5d8d0}, 
8) = 0
[pid 24033] select(1, [0], NULL, NULL, {0, 0}) = 0 (Timeout)
[pid 24033] select(1, [0], NULL, NULL, {0, 0}) = 0 (Timeout)
[pid 24033] rt_sigaction(SIGTSTP, {0x7f18aed9d4c0, [], SA_RESTORER|SA_RESTART, 
0x7f18afb5d8d0}, NULL, 8) = 0
[pid 24033] poll([{fd=3, events=POLLIN}], 1, 0) = 1 ([{fd=3, revents=POLLIN}])

First thread really didn't want to handle it, now it finally does.

[pid 24033] read(3, "\4\0\0\0\0\0\0\0", 16) = 8
[pid 24033] poll([{fd=3, events=POLLIN}], 1, 0) = 0 (Timeout)
[pid 24033] read(3, 0x7ffd85173f30, 16) = -1 EAGAIN (Resource temporarily 
unavailable)
[pid 24033] select(1, [0], NULL, NULL, {0, 20}) = 0 (Timeout)

It looks like the first thread tries to handle multiple event loops at
the same time.. select, poll, ... WTF?

Anyway, I hope this helps.

regards,
Stefan


pgpVzucnGyCjA.pgp
Description: OpenPGP digital signature

Bug#802680: Acknowledgement (lighttpd: server.error-handler-404 broken, returns status code 200)

[Stefan Bühler]

Hi,

On Thu, 22 Oct 2015 18:23:22 +0100
Jonathan Dowland  wrote:

> The relevant upstream docs say
> 
> "You can use a dynamic or static page for the handler. If you use a
> static page, the server will return a 404 HTTP status code with the
> content of your static page."
> 
> http://redmine.lighttpd.net/projects/1/wiki/Server_error-handler-404Details
> 
> I hope I am reading this wrong, but this would suggest this was known
> behaviour?
> 
> http://redmine.lighttpd.net/issues/2456

The docs and the behavior are certainly not optimal, but as
lighttpd-1.4.x is a "stable" branch we try to keep semantic changes to
a minimum.

Please use url.rewrite-if-not-file instead; if you have a scenario that
is not covered by url.rewrite-if-not-file you could also have a look
at mod_magnet.

regards,
Stefan

Bug#801994: hosts stuck in refresh

[Stefan Bühler]

Package: apt-dater
Version: 1.0.2+git20150804-1

Hi,

every host I refresh stays in refresh forever, until i force close
apt-dater and restart. after a restart it seems to have the correct
package states.

On the server I saw "/usr/bin/perl /usr/bin/apt-dater-host refresh"
running at first, and then it finished.

Bug#797917: clang should use the new CXX11_ABI

[Stefan Bühler]

Control: forwarded -1 https://llvm.org/bugs/show_bug.cgi?id=23529
Control: found -1 clang-3.4/1:3.4.2-15
Control: found -1 clang-3.6/1:3.6.2-1
Control: found -1 clang-3.7/1:3.7-2
Control: found -1 clang-3.8/1:3.8~svn247576-1

Hi,

I've been trying to fix this, see the upstream bug report and
http://reviews.llvm.org/D12834

Some clarifications:

The dual ABI in libstdc++ is *enabled*, so linking libstdc++ should
work fine with clang++ -D_GLIBCXX_USE_CXX11_ABI=0

The problem is with other c++ libraries which provide interfaces based
on the new libstdc++ ABI (for example by using std::string). I don't
think there is any library apart from libstdc++ out there providing
dual ABI (and I don't think it is trivial to add, as you need separate
translation units afaik); instead they are now all build against the
new ABI.

The main source of incompatibilities is:
- functions returning an "abi_tag"ged type, like ``std::string
  getName()``
- global variables with "abi_tag"ged type (global as in "needs a
  symbols visible in all translation units". static variables in inline
  functions might not trigger a linker error, but are broken anyway)

regards,
Stefan

PS: g++-4.9 doesn't work either.

Bug#792140: phabricator postinst should respect dpkg-statoverride

[Stefan Bühler]

Hi,

On Sun, 12 Jul 2015 00:37:31 +0200 Stefan Bühler
stbueh...@lighttpd.net wrote:
 Package: phabricator
 Version: 0~git20150613-1
 
 phabricator postinst should respect dpkg-statoverride (and not just
 chown stuff); users should have the choice to run php for phabricate
 as a separate user phabricator-php instead of www-data.

This is really annoying. Please don't touch existing stuff; for now,
this seems to be the list of things I need to fix after an update:

chown root:phabricator-php /var/lib/phabricator/local.json
chown -R phabricator:phabricator-php /var/lib/phabricator/phd_storage 
/var/lib/phabricator/repositories/* /var/lib/phabricator/.ssh/
usermod -g phabricator-php phabricator

Also postinst replaces https:// with http:// in phabricator.base-uri in
my local.json - this might even deserve a CVE.
(it calls /usr/share/phabricator/bin/config set phabricator.base-uri 
http://$domain_name/)


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#792136: phabricator conflicts with php5-mysqlnd

[Stefan Bühler]

Package: phabricator
Version: 0~git20150613-1

phabricator depends on php-mysql | php5-mysqli; php5-mysqlnd should be
allowed too, unless it actually doesn't work with it.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#792140: phabricator postinst should respect dpkg-statoverride

[Stefan Bühler]

Package: phabricator
Version: 0~git20150613-1

phabricator postinst should respect dpkg-statoverride (and not just
chown stuff); users should have the choice to run php for phabricate as
a separate user phabricator-php instead of www-data.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#789856: lighttpd: FTBFS with perl 5.22: test failures

[Stefan Bühler]

Hi Dominic,

perl-modules-5.22 doesn't include the CGI module, formerly
libcgi-pm-perl, which apparently gets replaced by perl-modules 5.20.2-6.

As soon as you fix perl-modules-5.22 it should work again.

(Also I couldn't even install libcgi-pm-perl with perl 5.22, needed to
go for cpan to actually see that nothing was wrong with the 404.pl
script in lighttpd...)

On Wed, 24 Jun 2015 22:54:42 +0100
Dominic Hargreaves d...@earth.li wrote:

 Source: lighttpd
 Version: 1.4.35-4
 Severity: important
 User: debian-p...@lists.debian.org
 Usertags: perl-5.22-transition
 Tags: sid stretch
 
 This package FTBFS with perl 5.22 (currently in experimental):
 
 # 
 # body failed: expected 'found here
 # ', got ''
 
 #   Failed test '404 handler = dynamic(200)'
 #   at ./core-404-handler.t line 45.
 # 
 # status failed: expected '302', got '200'
 
 #   Failed test '404 handler = dynamic(302)'
 #   at ./core-404-handler.t line 52.
 # 
 # status failed: expected '404', got '200'
 
 #   Failed test '404 handler = dynamic(404)'
 #   at ./core-404-handler.t line 59.
 # 
 # body failed: expected 'found here
 # ', got ''
 
 #   Failed test '404 handler = dynamic(nostatus)'
 #   at ./core-404-handler.t line 66.
 # 
 # status failed: expected '404', got '200'
 
 #   Failed test '404 generated by CGI should stay 404'
 #   at ./core-404-handler.t line 73.
 # Looks like you failed 5 tests of 8.
 ./core-404-handler.t .. 
 Dubious, test returned 5 (wstat 1280, 0x500)
 Failed 5/8 subtests 
 
 ...
 
 Test Summary Report
 ---
 ./core-404-handler.t (Wstat: 1280 Tests: 8 Failed: 5)
   Failed tests:  3-7
   Non-zero exit status: 5
 Files=24, Tests=367,  9 wallclock secs ( 0.15 usr  0.15 sys +  2.70
 cusr  1.92 csys =  4.92 CPU) Result: FAIL
 
 This bug will become release critical nearer the time of the perl 5.22
 migration, expected during the (northern hemisphere) summer.
 
 Cheers,
 Dominic.
 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#765379: gcc-4.7 should not ship with jessie

[Stefan Bühler]

Hi,

this was a bad one; gcc-4.9-base from jessie breaks gcc-4.7-base from
wheezy, so you had to update gcc-4.7-base to jessie/unstable for a
stable/testing mix as soon as some package required gcc-4.9-base from
testing.

For now using gcc-4.7-base from unstable seems to work; wheezy/jessie
mix is broken otherwise.

regards,
Stefan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774644: lighttpd: fails to start (with no message given) when fastcgi-php module is enabled

[Stefan Bühler]

On Mon, 05 Jan 2015 12:39:42 -0500
David Z unimportantdav...@gmail.com wrote:

 Package: lighttpd
 Version: 1.4.31-4+deb7u3
 Severity: important
 
 A simple dependency fix, lighttpd package should simply add a
 dependency for php5-cgi

No. I don't think you understand what dependencies are for.

There are probably thousands of issues like that; if you start
configuring features you might require additional dependencies
(sometimes listed as Recommended or Suggested packages, but
certainly not as hard dependencies).

While it might be nice to have better messages (like
lighttpd-enable-mod telling about the missing dependency, or the
lighttpd startup showing issues), this is imho a configuration problem
users have to be able to deal with, and certainly not of severity
important.

regards,
Stefan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#765806: Some patches to get cgit special stuff working in debian

[Stefan Bühler]

Package: cgit
Version: 0.10.2.git2.0.1-3

Hi,

thanks for packaging.

I have some old patches from my own packaging efforts
(https://build.opensuse.org/package/show/home:stbuehler/cgit):

* 0001-assume-highlight-version-3-in-filter-script.patch
  this one is important and should be straight forward
* 0002-configure-cgit-make-options.patch
  just for your information; I didn't look how you build it, but
  perhaps it is useful to you.
* 0004-add-highlighting-rules-to-cgit.css.patch
  perhaps this could be checked if it still matches the current
  highlight output
* 0005-Force-man2html-groff-to-use-UTF-8-as-input-encoding.patch
  UTF-8 is my own preference, not absolutely necessary
* 0006-Use-debian-binary-name-rst2html.patch
  somehow obvious :)

0003 got fixed upstream, that is why I left it out :)

regards,
StefanFrom: =?UTF-8?q?Stefan=20B=C3=BChler?= stbueh...@web.de
Date: Fri, 10 May 2013 09:53:00 +0200
Subject: assume highlight version 3 in filter script

---
 filters/syntax-highlighting.sh |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/filters/syntax-highlighting.sh b/filters/syntax-highlighting.sh
index 24f6bb4..2ff2032 100755
--- a/filters/syntax-highlighting.sh
+++ b/filters/syntax-highlighting.sh
@@ -53,7 +53,7 @@ EXTENSION=${BASENAME##*.}
 # found (for example) on EPEL 6.
 #
 # This is for version 2
-exec highlight --force -f -I -X -S $EXTENSION 2/dev/null
+#exec highlight --force -f -I -X -S $EXTENSION 2/dev/null
 
 # This is for version 3
-#exec highlight --force -f -I -O xhtml -S $EXTENSION 2/dev/null
+exec highlight --force -f -I -O xhtml -S $EXTENSION 2/dev/null
From: =?UTF-8?q?Stefan=20B=C3=BChler?= stbueh...@web.de
Date: Fri, 10 May 2013 10:55:14 +0200
Subject: configure cgit make options

---
 cgit.conf |9 +
 1 file changed, 9 insertions(+)
 create mode 100644 cgit.conf

diff --git a/cgit.conf b/cgit.conf
new file mode 100644
index 000..cf9463c
--- /dev/null
+++ b/cgit.conf
@@ -0,0 +1,9 @@
+CGIT_SCRIPT_PATH=/usr/lib/cgi-bin
+CGIT_DATA_PATH=/usr/share/cgit
+V=1
+NO_OPENSSL=1
+SHA1_HEADER=block-sha1/sha1.h
+
+export V
+export NO_OPENSSL
+export SHA1_HEADER
From: =?UTF-8?q?Stefan=20B=C3=BChler?= stbueh...@web.de
Date: Wed, 29 May 2013 11:23:53 +0200
Subject: add highlighting rules to cgit.css

---
 cgit.css |   17 +
 1 file changed, 17 insertions(+)

diff --git a/cgit.css b/cgit.css
index d467c66..d3e48c7 100644
--- a/cgit.css
+++ b/cgit.css
@@ -800,3 +800,20 @@ div#cgit table.ssdiff td.space {
 div#cgit table.ssdiff td.space div {
 	min-height: 3em;
 }
+
+/* Style definition file generated by highlight 3.9, http://www.andre-simon.de/ */
+/* Highlighting theme: Kwrite Editor */
+/* adapted for cgit */
+div#cgit table.blob .num { color:#b07e00; }
+div#cgit table.blob .esc { color:#ff00ff; }
+div#cgit table.blob .str { color:#bf0303; }
+div#cgit table.blob .pps { color:#818100; }
+div#cgit table.blob .slc { color:#838183; font-style:italic; }
+div#cgit table.blob .com { color:#838183; font-style:italic; }
+div#cgit table.blob .ppc { color:#008200; }
+div#cgit table.blob .opt { color:#00; }
+div#cgit table.blob .lin { color:#55; }
+div#cgit table.blob .kwa { color:#00; font-weight:bold; }
+div#cgit table.blob .kwb { color:#0057ae; }
+div#cgit table.blob .kwc { color:#00; font-weight:bold; }
+div#cgit table.blob .kwd { color:#010181; }
From: =?UTF-8?q?Stefan=20B=C3=BChler?= stbueh...@web.de
Date: Wed, 29 May 2013 14:33:50 +0200
Subject: Force man2html/groff to use UTF-8 as input encoding

---
 filters/html-converters/man2html |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/filters/html-converters/man2html b/filters/html-converters/man2html
index 1b28437..4975da4 100755
--- a/filters/html-converters/man2html
+++ b/filters/html-converters/man2html
@@ -1,5 +1,5 @@
 #!/bin/sh
 echo div style=\font-family: monospace\
-groff -mandoc -T html -P -r -P -l | egrep -v '(html|head|meta|title|/title|/head|body|/body|/html|!DOCTYPE|http://www.w3.org)'
+groff -mandoc -T html -K UTF-8 -P -r -P -l | egrep -v '(html|head|meta|title|/title|/head|body|/body|/html|!DOCTYPE|http://www.w3.org)'
 echo /div
 
From: =?UTF-8?q?Stefan=20B=C3=BChler?= stbueh...@web.de
Date: Wed, 29 May 2013 14:34:15 +0200
Subject: Use debian binary name rst2html

---
 filters/html-converters/rst2html |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/filters/html-converters/rst2html b/filters/html-converters/rst2html
index c51f5be..a1ba574 100755
--- a/filters/html-converters/rst2html
+++ b/filters/html-converters/rst2html
@@ -1,2 +1,2 @@
 #!/bin/sh
-rst2html.py --template=$(dirname $0)/resources/rst-template.txt
+rst2html --template=$(dirname $0)/resources/rst-template.txt

Bug#765702: lighttpd: Disable SSL 3.0

[Stefan Bühler]

Hi,

On Fri, 17 Oct 2014 14:39:52 +0200
Christian Tacke christian.tacke+debian@cosmokey.com wrote:

 Hi,
 
 looking at CVE-2014-3566 (POODLE) it seems a very good
 idea to finally disable SSL 3.0 by default (secure by
 default). Please test attached patch.

I'd say go with this instead:
http://git.lighttpd.net/lighttpd/lighttpd-1.x.git/commit/?id=084df7e99a8738be79f83e330415a8963280dc4a

You can still add the option in the config example of course, or just
mention its existance there.

regards,
Stefan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758866: Upstream missing / dependency

[Stefan Bühler]

Package: libconstantine-java
Version: 0.7-5

Hi,

the Homepage link (http://github.com/wmeissner/jnr-constants/) is
broken; maybe https://github.com/jnr/jnr-constants is upstream now?

Also is the dependency on default-jre really necessary or would
default-jre-headless do? Because of this jenkins is pulling in all the
X/gl/drm libraries.

regards,
Stefan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org