Bug#1071596: apache2: envvars evaluates string in conditional instead of testing for empty string

[Stefan Fritsch]

Hi Mark,

Am 21.05.24 um 22:30 schrieb Mark Hedges:

Package: apache2
Version: 2.4.59-1~deb12u1
Severity: normal

Dear Maintainer,

`envvars` evaluates string in conditional instead of testing for empty string.

`apachectl` calls `envvars` which shows a syntax error despite working:

  root@nodeo:/etc/letsencrypt# apachectl configtest
  /usr/sbin/apachectl: 6: [: /etc/apache2: unexpected operator
  Syntax OK

If I change this line in `envvars`:

  if [ "${APACHE_CONFDIR}" == "" ]; then
 export APACHE_CONFDIR=/etc/apache2
  fi


This snippet is not in the original file from the apache2 package. 
Compare to 
https://salsa.debian.org/apache-team/apache2/-/blob/master/debian/config-dir/envvars?ref_type=heads


Either you or some package or script has changed the file. If you have 
etckeeper you could dig in the logs.


Cheers,
Stefan



to this:

  if [ -z ${APACHE_CONFDIR} ]; then
 export APACHE_CONFDIR=/etc/apache2
  fi

... then it works.

It's trying to evaluate `/etc/apache2` as a command?  Weird.

PATH seems totally normal.

Mark

-- Package-specific info:

-- System Information:
Debian Release: 12.5
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-21-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apache2 depends on:
ii  apache2-bin2.4.59-1~deb12u1
ii  apache2-data   2.4.59-1~deb12u1
ii  apache2-utils  2.4.59-1~deb12u1
ii  init-system-helpers1.65.2
ii  lsb-base   11.6
ii  media-types10.0.0
ii  perl   5.36.0-7+deb12u1
ii  procps 2:4.0.2-3
ii  sysvinit-utils [lsb-base]  3.06-4

Versions of packages apache2 recommends:
ii  ssl-cert  1.1.2

Versions of packages apache2 suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  chromium [www-browser]   125.0.6422.60-1~deb12u1

Versions of packages apache2-bin depends on:
ii  libapr1  1.7.2-3
ii  libaprutil1  1.6.3-1
ii  libaprutil1-dbd-sqlite3  1.6.3-1
ii  libaprutil1-ldap 1.6.3-1
ii  libbrotli1   1.0.9-2+b6
ii  libc62.36-9+deb12u7
ii  libcrypt11:4.4.33-2
ii  libcurl4 7.88.1-10+deb12u5
ii  libjansson4  2.14-2
ii  libldap-2.5-02.5.13+dfsg-5
ii  liblua5.3-0  5.3.6-2
ii  libnghttp2-141.52.0-1+deb12u1
ii  libpcre2-8-0 10.42-1
ii  libssl3  3.0.11-1~deb12u2
ii  libxml2  2.9.14+dfsg-1.3~deb12u1
ii  perl 5.36.0-7+deb12u1
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages apache2-bin suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  chromium [www-browser]   125.0.6422.60-1~deb12u1

Versions of packages apache2 is related to:
ii  apache2  2.4.59-1~deb12u1
ii  apache2-bin  2.4.59-1~deb12u1

-- Configuration Files:
/etc/apache2/apache2.conf changed:
DefaultRuntimeDir ${APACHE_RUN_DIR}
PidFile ${APACHE_PID_FILE}
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5
User ${APACHE_RUN_USER}
Group ${APACHE_RUN_GROUP}
HostnameLookups Off
ErrorLog ${APACHE_LOG_DIR}/error.log
LogLevel warn
IncludeOptional mods-enabled/*.load
IncludeOptional mods-enabled/*.conf
Include ports.conf

Options FollowSymLinks
AllowOverride None
Require all denied


AllowOverride None
Require all granted


Options Indexes FollowSymLinks
AllowOverride None
Require all granted

AccessFileName .htaccess

Require all denied

LogFormat "%v:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" 
vhost_combined
LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" 
combined
LogFormat "%h %l %u %t \"%r\" %>s %O" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
IncludeOptional conf-enabled/*.conf
IncludeOptional sites-enabled/*.conf

/etc/apache2/envvars changed:
unset HOME
if [ -z "${APACHE_CONFDIR}" ]; then
export APACHE_CONFDIR=/etc/apache2
fi
if [ "${APACHE_CONFDIR##/etc/apache2-}" != "${APACHE_CONFDIR}" ] ; then
SUFFIX="-${APACHE_CONFDIR##/etc/apache2-}"
else
SUFFIX=
fi
export APACHE_RUN_USER=www-data
export APACHE_RUN_GROUP=www-data
export APACHE_PID_FILE=/var/run/apache2$SUFFIX/apache2.pid
export APACHE_RUN_DIR=/var/run/apache2$SUFFIX
export APACHE_LOCK_DIR=/var/lock/apache2$SUFFIX
export APACHE_LOG_DIR=/var/log/apache2$SUFFIX
export LANG=C
export LANG


-- no debconf information

Bug#1067104: server stalls: AH00046: child process 2876749 still did not exit, sending a SIGKILL

[Stefan Fritsch]

Am 18.03.24 um 13:59 schrieb Yaroslav Halchenko:

Package: apache2
Version: 2.4.57-2
Severity: important

Server was working just fine for years and recently started to stall
completely after 3-7 days of functioning normally.  error logs get filled up
first with AH03490 and then eventually with AH00045 messages:

 [Sun Mar 17 02:26:01.353381 2024] [mpm_event:error] [pid 2649373:tid 
139846579189632] AH03490: scoreboard is full, not at MaxRequestWorkers.Increase 
ServerLimit.
 ...
 [Sun Mar 17 22:00:42.201774 2024] [mpm_event:error] [pid 2649373:tid 
139846579189632] AH03490: scoreboard is full, not at MaxRequestWorkers.Increase 
ServerLimit.
 [Sun Mar 17 22:00:42.995574 2024] [mpm_event:error] [pid 2649373:tid 
139846579189632] AH03490: scoreboard is full, not at MaxRequestWorkers.Increase 
ServerLimit.
 [Sun Mar 17 22:00:42.998488 2024] [mpm_event:notice] [pid 2649373:tid 
139846579189632] AH00492: caught SIGWINCH, shutting down gracefully
 [Sun Mar 17 22:00:46.358981 2024] [core:warn] [pid 2649373:tid 
139846579189632] AH00045: child process 2649375 still did not exit, sending a 
SIGTERM
 [Sun Mar 17 22:00:46.359064 2024] [core:warn] [pid 2649373:tid 
139846579189632] AH00045: child process 2649376 still did not exit, sending a 
SIGTERM


Have you tried increasing ServerLimit as the warning suggests?

Apart from that, it is probably the same as 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057126 . mod_wsgi or 
some python script is preventing apache processes from dying and they 
accumulate until the scroeboard is full. Which versions of the wsgi 
related packages are you using?

Bug#1067120: nmu: apache2_2.4.58-1

[Stefan Fritsch]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: apac...@packages.debian.org
Control: affects -1 + src:apache2
User: release.debian@packages.debian.org
Usertags: binnmu

libaprutil1t64 1.6.3-1.1 contains a wrong symbol file, causing a wrong
dependency on libaprutil164 (missing a "t") for packages using the
apr_dbd_init or apr_ldap_init symbols. AFAICS, only apache2 is affected.  

Note that there is already apache2 2.4.58-1+b2 . I am not sure which
version is the correct one in the nmu syntax.

nmu apache2_2.4.58-1 . ANY . unstable . -m "Rebuild with fixed libaprutil1t64 
for #1067035"
dw apache2_2.4.58-1 . ANY . -m "libaprutil1-dev (>= 1.6.3-2)"

Bug#1066821: apr-util: FTBFS on arm{el,hf}: /bin/bash: line 3: 3132384 Segmentation fault LD_LIBRARY_PATH="`echo "../crypto/.libs:../dbm/.libs:../dbd/.libs:../ldap/.libs:$LD_LIBRARY_PATH" | sed -e 's/

[Stefan Fritsch]

Am 18.03.24 um 19:30 schrieb Stefan Fritsch:


Am 13.03.24 um 22:32 schrieb Sebastian Ramacher:

Source: apr-util
Version: 1.6.3-1.1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in 
the past)

X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=apr-util=armhf=1.6.3-1.1=1709086833=0


It looks to me like it tried to use a non 64bit time_t libapr1 during 
build, which does not work because libapr1 changes abi with the time_t 
transition. Adding a versioned build-depends should help. I will check 
later.


Unfortunately, apr-util build-deps are uninstallable on armhf/armel 
right now due to postgres not being built for 64bit time_t. So, there is 
no easy way to test this. I will upload anyway.

Bug#1066821: apr-util: FTBFS on arm{el,hf}: /bin/bash: line 3: 3132384 Segmentation fault LD_LIBRARY_PATH="`echo "../crypto/.libs:../dbm/.libs:../dbd/.libs:../ldap/.libs:$LD_LIBRARY_PATH" | sed -e 's/

[Stefan Fritsch]

Am 13.03.24 um 22:32 schrieb Sebastian Ramacher:

Source: apr-util
Version: 1.6.3-1.1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=apr-util=armhf=1.6.3-1.1=1709086833=0


It looks to me like it tried to use a non 64bit time_t libapr1 during 
build, which does not work because libapr1 changes abi with the time_t 
transition. Adding a versioned build-depends should help. I will check 
later.




testldap:  SUCCESS
testdbd :  SUCCESS
testdate:  SUCCESS
testmemcache:  Error 111 occurred attempting to reach memcached on 
localhost:11211.  Skipping apr_memcache tests...
SUCCESS
testredis   :  Error 111 occurred attempting to reach Redis on 
localhost:6379.  Skipping apr_redis tests...
SUCCESS
testxml :  SUCCESS
testxlate   :  SUCCESS
testrmm :  SUCCESS
testdbm :  BDB1565 DB->put: method not permitted before handle's 
open method
/bin/bash: line 3: 3132384 Segmentation fault  LD_LIBRARY_PATH="`echo 
"../crypto/.libs:../dbm/.libs:../dbd/.libs:../ldap/.libs:$LD_LIBRARY_PATH" | sed -e 
's/::*$//'`" ./$prog -v
Programs failed: testall
make[2]: *** [Makefile:60: check] Error 139

Cheers

Bug#1057126: "AH03490: scoreboard is full" after nightly maintenance

[Stefan Fritsch]

Hi,

Am 30.11.23 um 09:05 schrieb Peter Krefting:

we are experiencing that the Apache httpd locks up, filling the 
error.log with errors after the nightly maintenance (not every night, 
though):


   [Wed Nov 29 00:00:01.922731 2023] [mpm_event:notice] [pid 62346:tid 
139841215223680] AH00489: Apache/2.4.57 (Debian) mod_wsgi/4.9.4 
Python/3.11 configured -- resuming normal operations
   [Wed Nov 29 00:00:01.922790 2023] [core:notice] [pid 62346:tid 
139841215223680] AH00094: Command line: '/usr/sbin/apache2'
   [Wed Nov 29 00:00:03.924683 2023] [mpm_event:error] [pid 62346:tid 
139841215223680] AH03490: scoreboard is full, not at 
MaxRequestWorkers.Increase ServerLimit.
   [Wed Nov 29 00:00:04.925780 2023] [mpm_event:error] [pid 62346:tid 
139841215223680] AH03490: scoreboard is full, not at 
MaxRequestWorkers.Increase ServerLimit.


(etc)

I set up a nightly job to mail me the output of "apachectl status", and 
this is the contents reported at Nov 29 00:00:00, i.e. just before the 
nightly maintenance:


Some processes are in "stopping" state but are not dying. They 
accumulate until the scoreboard is full.


First you should verify with ps if the processes with the PIDs in the 
"(old gen)" lines still exist. If not, it is a bug in apache itself 
(probably in mpm_event).


If they do, one needs to find out why they are not dying. This is likely 
the fault of some module. Third-party modules that do not come with 
apache itself are more likely to be the culprit. Since you are using 
mod_wsgi, that is a likely candidate. Look in the error log for the last 
log lines of the processes with those PIDs. Maybe that gives some hint. 
Or maybe mod_wsgi writes some logs itself, I am not familiar with that one.







   Apache Server Status for localhost (via ::1)

    Server Version: Apache/2.4.57 (Debian) mod_wsgi/4.9.4 Python/3.11
    Server MPM: event
    Server Built: 2023-04-13T03:26:51
  __

    Current Time: Wednesday, 29-Nov-2023 00:00:01 CET
    Restart Time: Tuesday, 21-Nov-2023 08:51:55 CET
    Parent Server Config. Generation: 8
    Parent Server MPM Generation: 7
    Server uptime: 7 days 15 hours 8 minutes 6 seconds
    Server load: 0.01 0.02 0.00
    Total accesses: 34860 - Total Traffic: 717.8 MB - Total Duration:
   2289464

    CPU Usage: u297.08 s30.61 cu.01 cs.07 - .0497% CPU load
    .0529 requests/sec - 1141 B/second - 21.1 kB/request - 65.676
   ms/request

    2 requests currently being processed, 48 idle workers

    Slot PID Stopping Connections Threads Async connections
    total accepting busy idle writing keep-alive closing
    0 62348 yes (old gen) 0 no 0 0 0 0 0
    1 62350 yes (old gen) 0 no 0 0 0 0 0
    2 66497 yes (old gen) 0 no 0 0 0 0 0
    3 66498 yes (old gen) 0 no 0 0 0 0 0
    4 73089 yes (old gen) 0 no 0 0 0 0 0
    5 73090 yes (old gen) 0 no 0 0 0 0 0
    6 79644 yes (old gen) 0 no 0 0 0 0 0
    7 79645 yes (old gen) 0 no 0 0 0 0 0
    8 86126 yes (old gen) 0 no 0 0 0 0 0
    9 86127 yes (old gen) 0 no 0 0 0 0 0
    10 92669 yes (old gen) 0 no 0 0 0 0 0
    11 92670 yes (old gen) 0 no 0 0 0 0 0
    12 99203 yes (old gen) 0 no 0 0 0 0 0
    13 99204 yes (old gen) 0 no 0 0 0 0 0
    14 105761 no 0 yes 0 25 0 0 0
    15 105762 no 0 yes 2 23 0 0 0
    Sum 16 14 0   2 48 0 0 0



.._W
W___

    Scoreboard Key:
    "_" Waiting for Connection, "S" Starting up, "R" Reading Request,
    "W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
    "C" Closing connection, "L" Logging, "G" Gracefully finishing,
    "I" Idle cleanup of worker, "." Open slot with no current process
'/usr/bin/lynx -dump http://localhost:80/server-status' failed.
Maybe you need to install a package providing www-browser or you
need to adjust the APACHE_LYNX variable in /etc/apache2/envvars




Cheers,
Stefan

Bug#1031034: apr: Missing LFS support triggers FTBFS on other packages

[Stefan Fritsch]

It seems a large transition will be needed for 64bit time_t, anyway. And 
glibc enforces _FILE_OFFSET_BITS=64 if _TIME_BITS=64 is set. apr should 
do both transitions at the same time.


It seems there won't be a transition for i386 but the whole point of 
i386 is running old binaries.


https://wiki.debian.org/ReleaseGoals/64bit-time

Bug#1031034: apr: Missing LFS support triggers FTBFS on other packages

[Stefan Fritsch]

Hi Helge,


Am 10.02.23 um 17:24 schrieb Helge Deller:

On 32-bit platforms it's necessary to compile programs and libraries
with Large File Support (LFS) in order to allow them to function 
correctly on

filesystems with > 2GB or 4GB size.
This can be solved by adding "-D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64" to

the CFLAGS variable when compiling.

apr is currently missing this LFS support and as such it triggers
build-from-source errors in other packages like "subversion" or 
"devscripts"

on such 32-bit platforms.



apr sets -D_LARGEFILE_SOURCE but not -D_FILE_OFFSET_BITS=64 . 
Unfortunately, it exposes those flags to programs built with apr via 
apr-1-config and apr-1.pc . And, AFAICS, ino_t and with it apr_ino_t 
would change size if -D_FILE_OFFSET_BITS=64 was added. So this would be 
an ABI break and require a soname bump and a library transition. As we 
are in transition freeze already, I think this has to wait until after 
bookworm release.


Or am I missing something here?

From reading the source, it seems apr uses readdir internally. Maybe 
some problems could also be solved if it used readdir64 and only failed 
if the inode number was requested. Not sure if readdir is the only 
problem, though.


Cheers,
Stefan

Bug#987013: Release goal proposal: Remove Berkeley DB

[Stefan Fritsch]

Apache httpd allows to use DBM file for various purposes. The default 
format is Berkeley DB. This is highly configuration dependent, automatic 
migration by maintainer scripts seems unfeasible. This means that the 
users need time and a tool to migrate their configurations. I have 
opened [1] for this.


Subversion's first repository format uses Berkeley DB. But according to 
[2], new repositories have not used that format as default since 1.2 in 
2005 and the format has been deprecated in 1.8 in 2013. So maybe a note 
in the release notes would be sufficient, here?


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030376
[2] https://en.wikipedia.org/wiki/Apache_Subversion

Bug#1030376: apache2: Deal with future removal of berkeley DB

[Stefan Fritsch]

Package: apache2
Version: 2.4.55-1
Severity: important

It seems db5.3 will go away sooner or later [1], probably after the
bookworm release. Apache httpd supports using auth/authz data from DBM
files with mod_authn_dbm/mod_authz_dbm [2,3] and in a bunch of other
places, at least mod_authn_socache and mod_rewrite.html [4,5].  The
default db format seems to be berkeley db (that's what htdbm/httxt2dbm
create if no dbm type is specified).

The location and use of dbm files are user specific. Therefore an
automatic conversion seems unfeasible. The users will have to convert
their files manually. To make this easier for the users, one should
probably 

- change the default format to something else
- log a big fat deprecation warning whenever berkeley db is used
- provide a conversion tool
- mention the deprecation in README.Debian and the release notes

in bookworm.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987013
[2] https://httpd.apache.org/docs/2.4/en/mod/mod_authn_dbm.html
[3] https://httpd.apache.org/docs/2.4/en/mod/mod_authz_dbm.html
[4] https://httpd.apache.org/docs/2.4/en/mod/mod_authn_socache.html
[5] https://httpd.apache.org/docs/2.4/en/mod/mod_rewrite.html#rewritemap

Bug#1017868: ssl-cert: Needless bash dependency

[Stefan Fritsch]

Hi,

Am 21.08.22 um 21:59 schrieb наб:

The installed make-ssl-cert depends on bash,
but doesn't really need to.


I am sorry, but I don't see any advantage here in switching away from 
bash. The performance advantage of dash over bash is completely 
irrelevant in make-ssl-cert, and bash is essential: yes.




See patch based on current Salsa HEAD, below;
it's shellcheck-clean.

The same could trivially be done for the tests,
since pretty much the only extension shellcheck picks up is local.


local is not a bash extension. Or what do you mean?

I haven't done a thorough review, but this bit is wrong:

  
  ask_via_debconf() {

  RET=""
-if db_settitle make-ssl-cert/title ; then
-   : # OK
-else
+if ! db_settitle make-ssl-cert/title ; then
echo "Debconf failed with error code $? $RET" >&2
echo "Maybe your debconf database is corrupt." >&2
echo "Try re-installing ssl-cert." >&2
  fi


$? will be 0 in the echo and not the return value from debconf.


Cheers,
Stefan

Bug#1010576: akonadi cannot kill mysql due to apparmor rules

[Stefan Fritsch]

Hi,

I have the problem that after suspend/resume, if I shut down the system, 
systemd complains that mysql does not die. I  have wondered, why akonadi 
does not kill mysql and it is because of akonadi's apparmor rules:



Jun 16 11:24:45 k kernel: [ 4096.077336] audit: type=1400 
audit(1655371485.959:102): apparmor="DENIED" operation="signal" 
profile="/usr/bin/akonadiserver" pid=16671 comm="akonadiserver" 
requested_mask="send" denied_mask="send" signal=term peer="unconfined"
Jun 16 11:24:48 k kernel: [ 4099.080389] audit: type=1400 
audit(1655371488.963:103): apparmor="DENIED" operation="signal" 
profile="/usr/bin/akonadiserver" pid=16671 comm="akonadiserver" 
requested_mask="send" denied_mask="send" signal=kill peer="unconfined"


If I set akonadi's profile to complain instead of enforce, akonadi can 
kill mysql ok:


sudo aa-complain /etc/apparmor.d/usr.bin.akonadiserver
sudo systemctl reload apparmor.service


Somehow mysql should be running in the mysqld_akonadi profile but it is 
running in fact unconstrained and therefore akonadiserver is not allowed 
to send a signal to it. Don't know how to fix that, though.


I suspect the fact that mysql hangs after suspend/resume is a different 
bug in mysql.


Cheers,
Stefan

Bug#1000681: linux-image-5.15.0-1-amd64: 5.15 upgrade causes all apps to flicker

[Stefan Fritsch]

On 09.12.21 23:14, Stefan Fritsch wrote:

There is discussion and a fix for this issue at

https://lists.freedesktop.org/archives/nouveau/2021-December/039597.html
https://lists.freedesktop.org/archives/nouveau/2021-December/039609.html



The fix is in 5.15.13

Bug#1000681: linux-image-5.15.0-1-amd64: 5.15 upgrade causes all apps to flicker

[Stefan Fritsch]

There is discussion and a fix for this issue at

https://lists.freedesktop.org/archives/nouveau/2021-December/039597.html
https://lists.freedesktop.org/archives/nouveau/2021-December/039609.html

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

[Stefan Fritsch]

I won't be able to deal with this for at least 1-2 weeks. It would be 
nice if someone could look at it and downgrade or NMU+unblock.


Am 06.06.21 um 13:14 schrieb 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?


I don't know for sure, but I expect that this mode is only used 
manually, not by any postinst script.





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#987156: mod_ssl depends on mod_setenvif while it does not

[Stefan Fritsch]

Am 18.04.21 um 17:10 schrieb MichaIng:
Hence I believe that this module dependency might come from some 
previous use of setenvif directives in the default mod_ssl config, which 
have been removed meanwhile, rendering this dependency as obsolete.


I'm not sure how those dependencies are defined and whether hence it is 
an upstream issue or a distro package issue. In case I'll report it 
upstream as well.


The dependency is declared in /etc/apache2/mods-available/ssl.load and 
is a Debian packaging thing, not relevant to upstream.


I think it has been used for some workarounds for the MS internet 
explorer. It's still in sites-enabled/default-ssl.conf, but it's 
commented out nowadays. If the dependency is removed, the commented out 
section should be removed, too.

Bug#978045: apache2-bin: Immediate exit with "AH00141: Could not initialize random number generator"

[Stefan Fritsch]

Am 27.12.20 um 12:24 schrieb David W:
I think a perfectly valid fix would be to document (in the changelog or 
elsewhere) that this hard requirement was added, in particular because 
(IIUC) using getrandom() instead of one of the other codepaths is the 
choice of the package maintainer. (I.e. this isn't just the result of 
upstream.) Tracking down what broke and why was mostly tricky because it 
wasn't documented, and Googling only turns up results on an unrelated 
Windows issue.


I will add a note to the changelog

Bug#978045: apache2-bin: Immediate exit with "AH00141: Could not initialize random number generator"

[Stefan Fritsch]

reassign 978045 libapr1
found 978045 1.7.0-1
thanks

Am 25.12.20 um 03:18 schrieb David W:
You can see that the associated call/failure is happening inside APR 
here, on

line 216:
https://svn.apache.org/viewvc/apr/apr/trunk/misc/unix/rand.c?revision=1832691=markup#l216 



The issue is that if the library is configured (at build time) to
USE_GETRANDOM, then it assumes that the getrandom() call will be 
available and

if it fails it becomes a fatal error. On my system, I don't have getrandom()
because I'm running an ancient kernel, but others could (more legitimately)
have the option disabled on a recent custom-built kernel.

I think the correct fix is to not use that build-time option, and go back to
using DEV_RANDOM or whatever was being used previously. Alternatively, at
least document that a kernel with getrandom() support is required to use
apache2.

I'm not sure exactly when the packaging on this changed, but I know it was
broken in 2.4.46-1 and I *think* it worked in 2.4.43-1, although I can't 
get a

copy of that to double-check anymore.


This changed in libapr1 1.7, re-assigning to apr. I am not sure about 
the severity, though. According to the man page, getrandom has been 
introduced in linux 3.17. Debian 9 already has 4.9 so you have to have a 
kernel that is from Debian 8 to be affected by this.

Bug#974890: mp3gain: dies on startup, complaining of missing ASan runtime

[Stefan Fritsch]

Am 16.11.20 um 09:44 schrieb Salvatore Bonaccorso:

On Mon, Nov 16, 2020 at 04:14:30AM +0100, Adam Borowski wrote:

Package: mp3gain
Version: 1.6.2-1+b1
Severity: important

Trying to run mp3gain results in:
==23813==ASan runtime does not come first in initial library list;
you should either link runtime to your application or manually
preload it with LD_PRELOAD.


Interestingly, I don't get this message. Same version, also amd64. But I 
saw that message when running mp3gain under valgrind without the LD_PRELOAD.



And indeed, invoking it as:
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.6 mp3gain -p -a *mp3
does the trick.


It looks that back in 2014 this was added to mitigate the stack
buffer overflows from #740268.

But as far I understand, compiling with ASAN was not recommended to be
in general used as hardening measure, there were reports back in 2016
as

https://blog.hboeck.de/archives/879-Safer-use-of-C-code-running-Gentoo-with-Address-Sanitizer.html
https://www.openwall.com/lists/oss-security/2016/02/17/9

That said I do not know if that is still an issue as per today, but
raising this question on topic.


I noticed that too when filing #973932. Some other links said ASAN has 
both false positives and false negatives when used together with 
FORTIFY_SOURCE:


https://github.com/google/sanitizers/issues/247

I agree that mp3gain should disable ASAN when #973932 is fixed.

Bug#973932: mp3gain: CVE-2018-10777, CVE-2019-18359: Crashes with fuzzing PoC

[Stefan Fritsch]

Package: mp3gain
Version: 1.6.2-1+b1
Severity: important
Tags: security, patch
X-Debbugs-Cc: Debian Security Team 

mp3gain 1.6.2 still crashes with AdressSanitizer errors on the PoCs

 mp3gain_poc1
 mp3gain_poc2
 mp3gain_poc5
 mp3gain_CVE-2018-10777

from https://github.com/zjuchenyuan/fuzzpoc.git

SuSe claims to have fixed them with this patch:

https://build.opensuse.org/package/view_file/openSUSE:Maintenance:12304/mp3gain.openSUSE_Leap_15.1_Update/0001-fix-security-bugs.patch?rev=0db47562b2545871d0be3fc88083e0cd

Debian builds mp3gain with asan on amd64 i386 armel armhf powerpc. This
means the other architectures are still vulnerable.

Bug#489625: Maybe fixable with apr 1.7

[Stefan Fritsch]

notforwarded 489625
thanks

Am 29.08.20 um 11:20 schrieb Stefan Fritsch:

According to the changelog, apr 1.7 adds all the --tag parameters to the
libtool invocations. Maybe this allows this to be fixed. 


This is not enough. There are many projects that use apr that don't pass 
the --tag parameter to libtool. Those would have to be changed, too. 
Examples for such projects are apr-util and Apache httpd. And it is not 
enough to patch those projects in Debian, they have to be fixed upstream 
beacaue we want for example the upstream Apache httpd to be buildable 
with Debian's libapr.


So, unless the debian libtool fixes #758317 and works without --tag, 
this bug won't be fixed.

Bug#489625: Maybe fixable with apr 1.7

[Stefan Fritsch]

According to the changelog, apr 1.7 adds all the --tag parameters to the
libtool invocations. Maybe this allows this to be fixed. But I won't
change that in the -1 upload because I want the python builddep fix to
make it to testing without problems.

Bug#898202: ITP: mp3gain

[Stefan Fritsch]

Hi,

I used to maintain mp3gain a long time ago. I have still use for it for
the player in my car and would support you if you want to maintain it. I
am still Debian developer and could sponsor your uploads.

If you are no longer interested, it may make sense to rename the bug
back to RFP.

Cheers,
Stefan

Bug#954311: libgl1-mesa-dri: Makes KDE konsole unusable

[Stefan Fritsch]

Hi Timo,

Am 20.03.20 um 09:55 schrieb Timo Aaltonen:
> Please file it upstream, this is caused by the new 'iris' driver. In the
> meantime, you can force the previous driver with this in a ~/.drirc:
> 
> 
>   
> 
>   
> 
> 
> 
> Or run the app with the driver to verify it actually helps:
> 
> dri_driver=i965 ./app

That did not help. It seems Xorg itself also loads the iris driver and
that causes the drawing errors. But putting the config into /etc/drirc
did help.

Cheers,
Stefan

Bug#947729: Acknowledgement (radicale: broken after upgrade from stretch)

[Stefan Fritsch]

After some more debugging and stracing, I finally got it to work:

Debug logging works if one starts radicale from the command line, not as
a service. Maybe this is due to --daemonize in the init script?

The directory for the converted collection was wrong. The (upper)
collection-root must go inside /var/lib/radicale/collections. This then
looks like this:


/var/lib/radicale/collections/collection-root/
/var/lib/radicale/collections/collection-root/user1
/var/lib/radicale/collections/collection-root/user1/some-hex-guid
/var/lib/radicale/collections/collection-root/collection-root/user1

Yes, there are two levels of 'collection-root' directories.


The whole tree /var/lib/radicale/collections must be owned by the
radicale  user. This caused the 500 internal server error because there
was one .Radicale.lock file owned by root. strace  with -f and -s 200 on
the radicale process gives the error message even if the logging is broken.


The new radicale is more strict on some required attributes, I had to
add some missing FN fields. See https://github.com/Kozea/Radicale/issues/830

I still think that the missing info in NEWS.Debian is a grave bug,
therefore I am not downgrading it.

Cheers,
Stefan

Bug#947729: radicale: broken after upgrade from stretch

[Stefan Fritsch]

Package: radicale
Version: 2.1.11-6
Severity: grave
Justification: renders package unusable

Hi,

I have upgraded my system from stretch. After some head scratching due
to the new disk format, I have installed the package listen in
NEWS.debian, did

 radicale --export-storage /var/tmp/radicale

Then moved /var/tmp/radicale/collection-root to
/var/lib/radicale/collections and did a chown. Is this the correct path?
This should be described much more verbosely in NEWS.Debian, for example
including the exact commands and directory names.

After that and re-installing radicale 2.1.11-6,

  radicale --verify-storage

did run without error. But now, all requests to radicale return a 500
internal server error. radicale does not log any information despite log
level debug:

# journalctl -u radicale

Dec 29 16:04:01 manul systemd[1]: Starting LSB: Radicale CalDAV and
CardDAV server...
Dec 29 16:04:01 manul radicale[16324]: Starting Radicale CalDAV server :
radicale[7f555ae2f740] INFO: Starting Radicale
Dec 29 16:04:01 manul radicale[16324]: [7f555ae2f740] INFO:
Authentication type is 'htpasswd'
Dec 29 16:04:01 manul radicale[16324]: [7f555ae2f740] DEBUG: registered
'apr_md5_crypt' handler: 
Dec 29 16:04:01 manul radicale[16324]: [7f555ae2f740] INFO: Storage type
is 'multifilesystem'
Dec 29 16:04:01 manul radicale[16324]: [7f555ae2f740] INFO: Rights type
is 'owner_only'
Dec 29 16:04:01 manul radicale[16324]: [7f555ae2f740] INFO: Web type is
'internal'
Dec 29 16:04:01 manul radicale[16324]: [7f555ae2f740] INFO: Listening to
'localhost' on port 5232
Dec 29 16:04:01 manul radicale[16324]: .
Dec 29 16:04:01 manul systemd[1]: Started LSB: Radicale CalDAV and
CardDAV server.


How does one make radicale log what is wrong?

BTW, I run radicale behind an apache reverse proxy and did the
x-script-name config changes.

Cheers,
Stefan

-- System Information:
Debian Release: 10.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages radicale depends on:
ii  adduser  3.118
ii  init-system-helpers  1.56+nmu1
ii  lsb-base 10.2019051400
ii  python3  3.7.3-1
ii  python3-radicale 2.1.11-6

Versions of packages radicale recommends:
ii  ssl-cert  1.0.39

Versions of packages radicale suggests:
ii  apache2 2.4.38-3+deb10u3
ii  apache2-utils   2.4.38-3+deb10u3
pn  libapache2-mod-proxy-uwsgi  
pn  python3-bcrypt  
ii  python3-passlib 1.7.1-1
pn  uwsgi   
pn  uwsgi-plugin-python3

-- Configuration Files:
/etc/radicale/config changed:
[server]
hosts = 127.0.0.1:5232
certificate = /etc/ssl/certs/ssl-cert-snakeoil.pem
key = /etc/ssl/private/ssl-cert-snakeoil.key
[encoding]
[auth]
type = htpasswd
htpasswd_encryption = md5
[rights]
type = owner_only
[storage]
[web]
[logging]
config = /etc/radicale/logging
debug = true
[headers]

/etc/radicale/logging changed:
[loggers]
keys = root
[handlers]
keys = console
[formatters]
keys = simple
[logger_root]
level = DEBUG
handlers = console
[handler_console]
class = StreamHandler
args = (sys.stderr,)
formatter = simple
[formatter_simple]
format = [%(thread)x] %(levelname)s: %(message)s


-- no debconf information

Bug#941122: e1000e is slooow for I219-LM

[Stefan Fritsch]

found 941122 4.19.67-2
thanks


We have also seen this with the 4.19 kernel in buster.


Links to Ubuntu bug reports and commits (but I have not verified that
these patches fix the issue):

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1836152
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1836177



commit 17fbc0334e61b81ae25213c220f80c666af3cfb0
Author: Kai-Heng Feng 
Date:   Thu Jul 11 15:16:46 2019 +0800

UBUNTU: SAUCE: e1000e: disable force K1-off feature

BugLink: https://bugs.launchpad.net/bugs/1836152

Forwardport from
http://mails.dpdk.org/archives/dev/2016-November/050658.html

MAC-PHY desync may occur causing misdetection of link up event.
Disabling K1-off feature can work around the problem.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204057

Signed-off-by: Kai-Heng Feng 
(cherry picked from commit 3a818fd5094bd988b371228b12ed33531d727d15

git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git
dev-queue)
Signed-off-by: Kai-Heng Feng 
Signed-off-by: Seth Forshee 

commit 403461fdd2e01e12bfb4a33e58c153e8ae355801
Author: Kai-Heng Feng 
Date:   Thu Jul 11 15:16:45 2019 +0800

UBUNTU: SAUCE: e1000e: add workaround for possible stalled packet

BugLink: https://bugs.launchpad.net/bugs/1836152

Forwardport from
http://mails.dpdk.org/archives/dev/2016-November/050657.html

This works around a possible stalled packet issue, which may occur
due to
clock recovery from the PCH being too slow, when the LAN is
transitioning
from K1 at 1G link speed.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204057

Signed-off-by: Kai-Heng Feng 
(cherry picked from commit 82f7de996433eee486f1acb37ad9047b431ec13d

git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git
dev-queue)
Signed-off-by: Kai-Heng Feng 
Signed-off-by: Seth Forshee 



commit 59653e6497d16f7ac1d9db088f3959f57ee8c3db
Author: Detlev Casanova 
Date:   Sat Jun 22 23:14:37 2019 -0400

e1000e: Make watchdog use delayed work

Use delayed work instead of timers to run the watchdog of the e1000e
driver.

Simplify the code with one less middle function.

Signed-off-by: Detlev Casanova 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 

Bug#936034: DSA-4509-1 regression needs to be fixed in subversion

[Stefan Fritsch]

Attached is the debdiff
diff -u subversion-1.9.5/debian/changelog subversion-1.9.5/debian/changelog
--- subversion-1.9.5/debian/changelog
+++ subversion-1.9.5/debian/changelog
@@ -1,3 +1,11 @@
+subversion (1.9.5-1+deb9u5) stretch-security; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport upstream fix for segfault with new mod_http2 from DSA-4509-1.
+Closes: #936034
+
+ -- Stefan Fritsch   Mon, 30 Sep 2019 09:03:27 +0200
+
 subversion (1.9.5-1+deb9u4) stretch-security; urgency=high
 
   * Backport security fixes from upstream:
diff -u subversion-1.9.5/debian/patches/series 
subversion-1.9.5/debian/patches/series
--- subversion-1.9.5/debian/patches/series
+++ subversion-1.9.5/debian/patches/series
@@ -23,0 +24 @@
+SVN-4782_r_notes
only in patch2:
unchanged:
--- subversion-1.9.5.orig/debian/patches/SVN-4782_r_notes
+++ subversion-1.9.5/debian/patches/SVN-4782_r_notes
@@ -0,0 +1,48 @@
+# http://svn.apache.org/viewvc?view=revision=1845531
+# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936034
+# backport fix for new mod_http2
+
+Index: a/subversion/mod_dav_svn/mod_dav_svn.c
+===
+--- a/subversion/mod_dav_svn/mod_dav_svn.c (revision 1845530)
 a/subversion/mod_dav_svn/mod_dav_svn.c (revision 1845531)
+@@ -1232,7 +1232,7 @@
+ 
+   /* Leave a note to ourselves so that we know not to decline in the
+* map_to_storage hook. */
+-  apr_table_setn(r->notes, NO_MAP_TO_STORAGE_NOTE, (const char*)1);
++  apr_table_setn(r->notes, NO_MAP_TO_STORAGE_NOTE, "1");
+   return OK;
+ }
+ 
+Index: a/subversion/mod_authz_svn/mod_authz_svn.c
+===
+--- a/subversion/mod_authz_svn/mod_authz_svn.c (revision 1845530)
 a/subversion/mod_authz_svn/mod_authz_svn.c (revision 1845531)
+@@ -912,7 +912,7 @@
+ {
+   /* Set the note to force authn regardless of what access_checker_ex
+  hook requires */
+-  apr_table_setn(r->notes, FORCE_AUTHN_NOTE, (const char*)1);
++  apr_table_setn(r->notes, FORCE_AUTHN_NOTE, "1");
+ 
+   /* provide the proper return so the access_checker hook doesn't
+* prevent the code from continuing on to the other auth hooks */
+@@ -978,7 +978,7 @@
+* ap_some_authn_rquired() without triggering an infinite
+* loop since the call will trigger this function to be
+* called again. */
+-  apr_table_setn(r->notes, IN_SOME_AUTHN_NOTE, (const char*)1);
++  apr_table_setn(r->notes, IN_SOME_AUTHN_NOTE, "1");
+   authn_required = ap_some_authn_required(r);
+   apr_table_unset(r->notes, IN_SOME_AUTHN_NOTE);
+   if (authn_required)
+@@ -1021,7 +1021,7 @@
+   status = req_check_access(r, conf, _path, _repos_path);
+   if (status == OK)
+ {
+-  apr_table_setn(r->notes, "authz_svn-anon-ok", (const char*)1);
++  apr_table_setn(r->notes, "authz_svn-anon-ok", "1");
+   log_access_verdict(APLOG_MARK, r, 1, FALSE, repos_path, 
dest_repos_path);
+   return OK;
+ }

Bug#936034: DSA-4509-1 regression needs to be fixed in subversion

[Stefan Fritsch]

reassign 936034 libapache2-mod-svn
found 936034 1.9.0-1
fixed 1.10.4-1
affects 936034 apache2
thanks

DSA-4509-1 for apache2 caused a regression with libapache2-mod-svn that
needs a fix in subversion. In agreement with the security team, I will
upload a fix for this to security.debian.org

Bug#936034: broken http2 in apache2 2.4.25-3+deb9u8 for mod_dav_svn on stretch?

[Stefan Fritsch]

Sorry for the late response.

This is unfortunately a bug in subversion that is now triggered by the
new http2 module. The fix is here
http://svn.apache.org/viewvc?view=revision=1845204 .

I will have to ask how this can be fixed, by DSA or by stable point release.

Am 29.08.19 um 11:55 schrieb Fabien:
> 
> Package: apache2
> Version: 2.4.25-3+deb9u8
> 
> It seems that since the updated version above, my svn server (through
> mod_dav_svn) does not serve contents correctly when using http2:
> 
>   sh> curl --http2 --verbose
> https://scm.cri.ensmp.fr/svn/nlpmake/trunk/makes/setup_pips.sh
>   * ALPN, server accepted to use h2
>   * Using HTTP2, server supports multi-use
>   * Connection state changed (HTTP/2 confirmed)
>   * Copying HTTP/2 data in stream buffer to connection buffer after
> upgrade: len=0
>   * Using Stream ID: 1 (easy handle 0x5576f7c8a3f0)
>   > GET /svn/nlpmake/trunk/makes/setup_pips.sh HTTP/2
>   > Host: scm.cri.ensmp.fr
>   > User-Agent: curl/7.58.0
>   > Accept: */*
>   >
>   * Connection state changed (MAX_CONCURRENT_STREAMS updated)!
>   * Unexpected EOF
>   * Connection #0 to host scm.cri.ensmp.fr left intact
>   curl: (56) Unexpected EOF
> 
> But it works fine with "curl --http1.1 …"
> 
> Also, site works well with http1.1 browsers (eg w3m), but is
> inaccessible with modern http2 compatible browsers (firefox, chrome),
> which is consistent.
> 
> After some investigating, I found:
> 
>  [Thu Aug 29 11:49:14.974371 2019] [core:notice] [pid 19929:tid
> 140177116143680] AH00052: child pid 19972 exit signal Segmentation fault
> (11)
> 
> Last time it worked with http2:
> 
>  10.2.14.177 - - [26/Aug/2019:23:33:01 +0200] "GET
> /svn/nlpmake/trunk/makes/setup_pips.sh HTTP/2.0" 200 11361 "-"
> "curl/7.58.0"
> 
> So it is broken since after that date, which I guess is when the server
> was updated to the above version. It seems that there was no simulaneous
> mod_dav_svn updates, so the issue appeared with apache2 latest update.
> 
> Current workaround is to disactivate http2 module.
> 

Bug#930446: popularity-contest: unable to submit report, impossible to debug

[Stefan Fritsch]

Am 20.06.19 um 13:25 schrieb Bill Allombert:
>> When submission fails, popcon-upload dies with a timeout. There should
>> probably be a randomized sleep to distribute the server load better. I
>> think there could be a lot more popcon submissions if this is done.
> 
> What is the time in /etc/cron.d/popularity-contest ?
> (something like 33 5 * * *)
> 
> Does it work better if you change it to some other time ?
> What cron ae you using


# cat /etc/cron.d/popularity-contest
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
41 4 * * *   roottest -x /etc/cron.daily/popularity-contest &&
/etc/cron.daily/popularity-contest --crond

# dpkg -l *cron*
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
un  anacron  (no description available)
ii  cron   3.0pl1-133   amd64process scheduling daemon
un  cron-daemon  (no description available)



It seems it is run twice, once from /etc/cron.d/popularity-contest and
once from /etc/cron.daily . And the run from cron.d is at a different
time on each host and was successful and did not log anything. But the
second run via run-parts /etc/cron.daily (without --crond) fails because
it is at the same time on all systems. And that produces log spam.

# grep daily /etc/crontab
25 6* * *   roottest -x /usr/sbin/anacron || ( cd / && run-parts
--report /etc/cron.daily )

Maybe the successful run should be remembered somehow?

Bug#930446: popularity-contest: unable to submit report, impossible to debug

[Stefan Fritsch]

Hi Bill,

I have some new info:

When submission fails, popcon-upload dies with a timeout. There should
probably be a randomized sleep to distribute the server load better. I
think there could be a lot more popcon submissions if this is done.

Also, popcon-upload should log errors to syslog.

The fallback to email only happens if "$MODE" = "--crond". But if the
script is called via cron.daily it gets called without parameters and
this never happens. Is this intentional?

Cheers,
Stefan

Bug#902493: SSL Issue

[Stefan Fritsch]

Thank you very much for the testing.

On Fri, 14 Jun 2019, Jean-Louis Dupond wrote:

> We had the test2 version running for some days on a machine.
> But we noticed a quite important issue with it.
> 
> The configuration has a lot of SSL certificates.
> Now when doing a lot of sequential requests, it happens that Apache was
> returning the wrong (default) certificate instead of the certificate of the
> supplied servername.
> This happend on like 1/5 requests.
> 
> Wanted to test Apache 2.4.38 from Buster to see if it worked fine there, but
> was not able to build it on Stretch.
> 
> So better not push this patched version to Stretch :)

Bug#930446: popularity-contest: unable to submit report, impossible to debug

[Stefan Fritsch]

Hmm. After comparing the log files, I think I may have found the issue:

Jun 05 06:25:01 c CRON[8719]: (root) CMD (test -x /usr/sbin/anacron || (
cd / && run-parts --report /etc/cron.daily ))
Jun 05 06:25:05 c runuser[8833]: pam_unix(runuser:session): session
opened for user nobody by (uid=0)
Jun 05 06:25:33 c runuser[8833]: pam_unix(runuser:session): session
closed for user nobody
Jun 05 06:25:34 c popularity-contest[8857]: unable to submit report to
http://popcon.debian.org/cgi-bin/popcon.cgi.
Jun 05 06:25:34 c popularity-contest[8858]: unable to submit report.
Jun 05 06:25:34 c CRON[8718]: pam_unix(cron:session): session closed for
user root

When it fails, it always does between 6:25 and 6:26 which is the time
/etc/cron.daily is run. Maybe the popcon server is overloaded at that
time and the 30s timeout in popcon-upload triggers?

Bug#930446: popularity-contest: unable to submit report, impossible to debug

[Stefan Fritsch]

Am 12.06.19 um 22:52 schrieb Bill Allombert:
> /usr/share/popularity-contest/popcon-upload has an option -d for
> debugging that you could try.

>From the command line, this works without errors:

/usr/share/popularity-contest/popcon-upload -d -u
http://popcon.debian.org/cgi-bin/popcon.cgi -f
/var/log/popularity-contest.new.gpg

I will put some debugging output into the script and wait for cron to
run it again, but there really should be an option in
popularity-contest.conf to enable debugging.


BTW, the use of setsid seems to be wrong, it hides the error code:

# setsid /bin/false ; echo $?
0

You probably want setsid -w . Or why use setsid at all?

Bug#930446: popularity-contest: unable to submit report, impossible to debug

[Stefan Fritsch]

Package: popularity-contest
Version: 1.67
Severity: normal

Dear Maintainer,

on several of my hosts, popularity-contest logs

  unable to submit report to http://popcon.debian.org/cgi-bin/popcon.cgi.
  unable to submit report.

But it does not log why and there is no way that I could find to trigger
the sending from the command line with debug output enabled.

http://popcon.debian.org/cgi-bin/pop is reachable from the host via curl. Also,
according to the documentation it should fall back to email, which it does not
do. It does not log why it does not do that.

Cheers,
Stefan

Relevant parts of /etc/popularity-contest.conf (without MY_HOSTID):

PARTICIPATE="yes"
USEHTTP="yes"
DAY="2"



-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages popularity-contest depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  dpkg   1.19.7

Versions of packages popularity-contest recommends:
ii  cron [cron-daemon] 3.0pl1-133
ii  exim4-daemon-light [mail-transport-agent]  4.92-7
ii  gnupg  2.2.12-1

Versions of packages popularity-contest suggests:
pn  anacron   
pn  tor   
pn  torsocks  

-- debconf information:
* popularity-contest/participate: true
  popularity-contest/submiturls:

Bug#923661: tt-rss: PHP Fatal error: Uncaught PDOException: SQLSTATE[22001]: String data, right truncated

[Stefan Fritsch]

Hi Helmut,

Am 08.05.19 um 19:23 schrieb Helmut Grohne:

Thank you for the detailed analysis. The actual failure we see here is
secondary. It tries to log an error and fails. Changing the
LOG_DESTINATION fixes the secondary error. The primary cause seems to
live in JShrink though and I guess that this commit fixes it:

https://github.com/tedious/JShrink/pull/78/commits/91105810dafedba0390608d7465abd602beb6410

JShrink is a vendored library and is installed to
/usr/share/tt-rss/www/vendor/JShrink/Minifier.php. You can apply the
above commit to a live installation without rebuilding the package.  Can
any of the reporters try applying it and tell whether it fixes tt-rss?


Yes, using the Minifier.php from the above commit fixes the issue (and 
another php warning that appeared in apache error log). In order to test 
it, one needs to delete the files from /var/cache/tt-rss/js/* first, or 
the minifier won't be called again.


Cheers,
Stefan

Bug#928173: apache2: SSLCipherSuite is ignored

[Stefan Fritsch]

On Monday, 29 April 2019 13:22:56 CEST Olaf Zaplinski wrote:
> I have set
> SSLCipherSuite "-ALL ECDHE-ECDSA-CHACHA20-POLY1305
> ECDHE-RSA-CHACHA20-POLY1305 ECDHE-ECDSA-AES256-GCM-SHA384" in
> mods-enabled/ssl.conf
> 
> SSLProtocol is not defined anywhere. SSLCipherSuite is only defined here.
> 
> According to Qualsys SSL labs test, non-defined ciphers are being used, e.g.
> ECDHE-RSA-AES128-GCM-SHA256
> 
> Expectation: only defined three ciphers are being used.


apache2 in stretch still uses openssl 1.0 libs, while the command line utility 
is already 1.1. This makes it difficult to check with "openssl ciphers" what is 
actually happening.

openssl 1.0 does not support the chacha ciphers. But I don't know why apache 
does not complain about the unknown ciphers. Probably that's a bug.

In buster / Debian 10, this seems to work better, because there apache2 links 
against openssl 1.1.

But even there, things are weird. It does not seem possible to select a single 
cipher:

$ openssl ciphers ECDHE-RSA-AES256-GCM-SHA384
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-
RSA-AES256-GCM-SHA384

Bug#927793: dmeventd hangs for > 1 minute during update

[Stefan Fritsch]

Package: dmeventd
Version: 2:1.02.155-2
Severity: important

Dear Maintainer,

I upgraded my system from stretch to buster and the postinstall hung for
a long time. Some log file excerpts:

$ grep dmevent /var/log/dpkg.log
2019-04-20 09:55:47 upgrade dmeventd:amd64 2:1.02.137-2 2:1.02.155-2
2019-04-20 09:55:47 status half-configured dmeventd:amd64 2:1.02.137-2
2019-04-20 09:55:47 status unpacked dmeventd:amd64 2:1.02.137-2
2019-04-20 09:55:47 status half-installed dmeventd:amd64 2:1.02.137-2
2019-04-20 09:55:47 status unpacked dmeventd:amd64 2:1.02.155-2
2019-04-20 10:09:17 configure dmeventd:amd64 2:1.02.155-2 
2019-04-20 10:09:17 status unpacked dmeventd:amd64 2:1.02.155-2
2019-04-20 10:09:17 status half-configured dmeventd:amd64 2:1.02.155-2
2019-04-20 10:10:47 status installed dmeventd:amd64 2:1.02.155-2


# pstree -p 13122
apt(13122)───dpkg(25582)───dmeventd.postin(5015)───systemctl(5038)───systemd-tty-ask(5045)

Apr 20 10:09:17 l systemd[1]: Stopped Monitoring of LVM2 mirrors, snapshots 
etc. using dmeventd or progress polling.
Apr 20 10:10:47 l systemd[1]: dm-event.service: State 'stop-sigterm' timed out. 
Killing.
Apr 20 10:10:47 l systemd[1]: dm-event.service: Killing process 424 (dmeventd) 
with signal SIGKILL.
Apr 20 10:10:47 l systemd[1]: dm-event.service: Main process exited, 
code=killed, status=9/KILL
Apr 20 10:10:47 l systemd[1]: dm-event.service: Failed with result 'timeout'.
Apr 20 10:10:47 l systemd[1]: Stopped Device-mapper event daemon.


From journalctl:
-- Logs begin at Sat 2019-04-20 08:15:12 CEST, end at Sat 2019-04-20 10:16:21 
CEST. --
Apr 20 08:15:12 l dmeventd[424]: dmeventd ready for processing.
Apr 20 08:15:12 l lvm[424]: Monitoring snapshot vgl-kvm--oa--bak--2019--01--10.
Apr 20 10:09:17 l lvm[424]: WARNING: There are still devices being monitored.
Apr 20 10:09:17 l lvm[424]: WARNING: Refusing to exit.
Apr 20 10:09:17 l dmeventd[424]: No longer monitoring snapshot 
vgl-kvm--oa--bak--2019--01--10.
Apr 20 10:10:47 l dmeventd[5075]: dmeventd ready for processing.
Apr 20 10:10:47 l lvm[5075]: Monitoring snapshot vgl-kvm--oa--bak--2019--01--10.


I am not sure about the severity, please adjust as you see fit.

Cheers,
Stefan


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_USER
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dmeventd depends on:
ii  libblkid1 2.33.1-0.1
ii  libc6 2.28-8
ii  libdevmapper-event1.02.1  2:1.02.155-2
ii  libdevmapper1.02.12:1.02.155-2
ii  liblvm2cmd2.032.03.02-2
ii  libselinux1   2.8-1+b1
ii  libudev1  241-3

dmeventd recommends no packages.

dmeventd suggests no packages.

-- no debconf information

Bug#925061: apache2: Cannot disabled old TLS Versions (prior to TLS1.2)

[Stefan Fritsch]

Hi,


On Tue, Mar 19, 2019 at 05:18:49PM +0100, Thomas Knaller wrote:
> Therefore I edited /etc/apache2/mods-enabled/ssl.conf so that it
> states "SSLProtocol TLSv1.2", which should disable all SSLProtocols
> except for TLS1.2, but TLS1.0 und TLS1.1 are still active, as seen
> with nmap:
> 
> # nmap --script ssl-enum-ciphers -p 443 127.0.0.1 | grep TLSv
> |   TLSv1.0:
> |   TLSv1.1:
> |   TLSv1.2:
> 

I could not reproduce this, either with 2.4.25-3+deb9u7 on stretch nor
with 2.4.38-3 on buster. It's not very likely that this was fixed
between 2.4.38-2 and 2.4.38-3, so it's probably something in your
configuration.

Maybe you have another sslprotocol directive somewhere else in the
config? You can check with:

a2enmod info
apache2ctl -t -D DUMP_CONFIG|grep -i ssl
a2dismod info # if it hasn't been enabled before

> On Apache Bugtracker it appears that apache itself does not have that
> problem but it has something to do with the deb-Package for Debian and
> Ubuntu: https://bz.apache.org/bugzilla/show_bug.cgi?id=60739

That report mentions some weird interaction with SSLCipherSuite. Maybe
you have that in another config file?

Cheers,
Stefan

Bug#927693: unblock: apr-util/1.6.1-4

[Stefan Fritsch]

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

Please unblock package apr-util

It fixes an RC bug which broke mariadb support.

Changelog/debdiff is included below.

unblock apr-util/1.6.1-4


Cheers,
Stefan

diff -Nru apr-util-1.6.1/debian/changelog apr-util-1.6.1/debian/changelog
--- apr-util-1.6.1/debian/changelog 2018-09-18 21:14:24.0 +0200
+++ apr-util-1.6.1/debian/changelog 2019-04-21 09:39:02.0 +0200
@@ -1,3 +1,9 @@
+apr-util (1.6.1-4) unstable; urgency=medium
+
+  * Fix libaprutil1-dbd-mysql with mariadb 10.3. Closes: #926400
+
+ -- Stefan Fritsch   Sun, 21 Apr 2019 09:39:02 +0200
+
 apr-util (1.6.1-3) unstable; urgency=medium
 
   [ Stefan Fritsch ]
diff -Nru apr-util-1.6.1/debian/patches/support_mariadb.patch 
apr-util-1.6.1/debian/patches/support_mariadb.patch
--- apr-util-1.6.1/debian/patches/support_mariadb.patch 2018-02-25 
10:59:52.0 +0100
+++ apr-util-1.6.1/debian/patches/support_mariadb.patch 2019-04-21 
08:56:45.0 +0200
@@ -1,46 +1,125 @@
+# patch by Kris Karas fom
+# https://bz.apache.org/bugzilla/attachment.cgi?id=35326=diff
 --- apr-util.orig/build/dbd.m4
 +++ apr-util/build/dbd.m4
-@@ -176,10 +176,15 @@ AC_DEFUN([APU_CHECK_DBD_MYSQL], [
+@@ -163,10 +163,15 @@ AC_DEFUN([APU_CHECK_DBD_MYSQL], [
+   old_cppflags="$CPPFLAGS"
+   old_ldflags="$LDFLAGS"
+ 
++  my_library="mysqlclient"
++
+   AC_ARG_WITH([mysql], APR_HELP_STRING([--with-mysql=DIR], [enable MySQL DBD 
driver]),
+   [
+ if test "$withval" = "yes"; then
+   AC_PATH_PROG([MYSQL_CONFIG],[mysql_config])
++  if test "x$MYSQL_CONFIG" = "x"; then
++AC_PATH_PROG([MYSQL_CONFIG],[mariadb_config])
++  fi
+   if test "x$MYSQL_CONFIG" != 'x'; then
+ mysql_CPPFLAGS="`$MYSQL_CONFIG --include`"
+ mysql_LDFLAGS="`$MYSQL_CONFIG --libs_r | sed -e 's/-l[[^ ]]\+//g'`"
+@@ -174,32 +179,40 @@ AC_DEFUN([APU_CHECK_DBD_MYSQL], [
+ 
+ APR_ADDTO(CPPFLAGS, [$mysql_CPPFLAGS])
  APR_ADDTO(LIBS, [$mysql_LIBS])
++
++  if $MYSQL_CONFIG --libs_r | grep -q mariadb; then
++my_library="mariadb"
++  fi
fi
  
-+  AC_LINK_IFELSE([#include 
-+  int main(int a, char **b) { mysql_init(); return 0; }],
-+ [apu_have_mysql=1], [apu_have_mysql=0])
-+  if test "$apu_have_mysql" = "0"; then
-   AC_CHECK_HEADERS([mysql.h my_global.h my_sys.h],
-AC_CHECK_LIB(mysqlclient, mysql_init, 
[apu_have_mysql=1]),
-[apu_have_mysql=0; break],
-[#include ])
+-  AC_CHECK_HEADERS([mysql.h my_global.h my_sys.h],
+-   AC_CHECK_LIB(mysqlclient, mysql_init, 
[apu_have_mysql=1]),
+-   [apu_have_mysql=0; break],
+-   [#include ])
+-  if test "$apu_have_mysql" = "0"; then
+-AC_CHECK_HEADERS([mysql/mysql.h mysql/my_global.h mysql/my_sys.h],
+- AC_CHECK_LIB(mysqlclient, mysql_init, 
[apu_have_mysql=1]),
+- [apu_have_mysql=0; break],
+- [#include ])
++  AC_CHECK_HEADERS([mysql.h errmsg.h], [apu_have_mysql=1], 
[apu_have_mysql=0; break])
++  if test "$apr_have_mysql" = "0"; then
++  AC_CHECK_HEADERS([mysql/mysql.h mysql/errmsg.h], [apu_have_mysql=1], 
[apu_have_mysql=0; break])
+   fi
+-  if test "$apu_have_mysql" != "0" && test "x$MYSQL_CONFIG" != 'x'; then
+-APR_ADDTO(APRUTIL_PRIV_INCLUDES, [$mysql_CPPFLAGS])
++  if test "$apr_have_mysql" = "1"; then
++  AC_CHECK_HEADERS([my_global.h my_sys.h mysql/my_global.h 
mysql/my_sys.h])
++  AC_CHECK_LIB($my_library, mysql_init,, [apu_have_mysql=0])
++  fi
++  if test "$apu_have_mysql" = "1" && test "x$MYSQL_CONFIG" != 'x'; then
++  APR_ADDTO(APRUTIL_PRIV_INCLUDES, [$mysql_CPPFLAGS])
+   fi
+ elif test "$withval" = "no"; then
+   :
+ else
+   AC_PATH_PROG([MYSQL_CONFIG],[mysql_config],,[$withval/bin])
++  if test "x$MYSQL_CONFIG" = "x"; then
++  AC_PATH_PROG([MYSQL_CONFIG],[mariadb_config],,[$withval/bin])
 +  fi
-   if test "$apu_have_mysql" = "0"; then
- AC_CHECK_HEADERS([mysql/mysql.h mysql/my_global.h mysql/my_sys.h],
-  AC_CHECK_LIB(mysqlclient, mysql_init, 
[apu_have_mysql=1]),
-@@ -207,11 +212,17 @@ AC_DEFUN([APU_CHECK_DBD_MYSQL], [
+   if test "x$MYSQL_CONFIG" != 'x'; then
+-mysql_CPPFLAGS="`$MYSQL_CONFIG --include`"
+-mysql_LDFLAGS="`$MYSQL_CONFIG --libs_r | sed -e 's/-l[[^ ]]\+//g'`"
+-mysql_LIBS=&

Bug#489625: libapr1-dev: please don't ship your own copy of libtool

[Stefan Fritsch]

forwarded 489625 https://bz.apache.org/bugzilla/show_bug.cgi?id=62640
thanks

https://bz.apache.org/bugzilla/show_bug.cgi?id=62640 has some infos and
a patch

Bug#900821: linux-image-4.9.0-6-amd64: apache reads wrong data over cifs filesystems served by samba

[Stefan Fritsch]

Hi,

by default, apache uses mmap, so probably mmap is broken on cifs. An
alternate workaround should be to set EnableMMAP off in the apache
config.

Cheers,
Stefan

Bug#926609: unblock: apache2/2.4.38-3

[Stefan Fritsch]

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

Please unblock package apache2, it fixes various security issues (no
other changes).


Debdiff is attached

unblock apache2/2.4.38-3
diff -Nru apache2-2.4.38/debian/changelog apache2-2.4.38/debian/changelog
--- apache2-2.4.38/debian/changelog 2019-01-31 21:54:05.0 +0100
+++ apache2-2.4.38/debian/changelog 2019-04-07 20:15:40.0 +0200
@@ -1,3 +1,40 @@
+apache2 (2.4.38-3) unstable; urgency=high
+
+  [ Marc Deslauriers ]
+  * SECURITY UPDATE: read-after-free on a string compare in mod_http2
+- debian/patches/CVE-2019-0196.patch: disentangelment of stream and
+  request method in modules/http2/h2_request.c.
+- CVE-2019-0196
+  * SECURITY UPDATE: privilege escalation from modules' scripts
+- debian/patches/CVE-2019-0211.patch: bind the bucket number of each
+  child to its slot number in include/scoreboard.h,
+  server/mpm/event/event.c, server/mpm/prefork/prefork.c,
+  server/mpm/worker/worker.c.
+- CVE-2019-0211
+  * SECURITY UPDATE: mod_ssl access control bypass
+- debian/patches/CVE-2019-0215.patch: restore SSL verify state after
+  PHA failure in TLSv1.3 in modules/ssl/ssl_engine_kernel.c.
+- CVE-2019-0215
+  * SECURITY UPDATE: mod_auth_digest access control bypass
+- debian/patches/CVE-2019-0217.patch: fix a race condition in
+  modules/aaa/mod_auth_digest.c.
+- CVE-2019-0217
+  * SECURITY UPDATE: URL normalization inconsistincy
+- debian/patches/CVE-2019-0220-1.patch: merge consecutive slashes in
+  the path in include/http_core.h, include/httpd.h, server/core.c,
+  server/request.c, server/util.c.
+- debian/patches/CVE-2019-0220-2.patch: fix r->parsed_uri.path safety
+  in server/request.c, server/util.c.
+- debian/patches/CVE-2019-0220-3.patch: maintainer mode fix in
+  server/util.c.
+- CVE-2019-0220
+
+  [ Stefan Fritsch ]
+  * Pull security fixes from 2.4.39 via Ubuntu
+  * CVE-2019-0197: mod_http2: Fix possible crash on late upgrade
+
+ -- Stefan Fritsch   Sun, 07 Apr 2019 20:15:40 +0200
+
 apache2 (2.4.38-2) unstable; urgency=medium
 
   * Disable "reset" test in allowmethods.t (Closes: #921024)
diff -Nru apache2-2.4.38/debian/patches/CVE-2019-0196.patch 
apache2-2.4.38/debian/patches/CVE-2019-0196.patch
--- apache2-2.4.38/debian/patches/CVE-2019-0196.patch   1970-01-01 
01:00:00.0 +0100
+++ apache2-2.4.38/debian/patches/CVE-2019-0196.patch   2019-04-07 
19:37:55.0 +0200
@@ -0,0 +1,27 @@
+From 8de3c6f2a0df79d1476c89ec480a96f9282cea28 Mon Sep 17 00:00:00 2001
+From: Stefan Eissing 
+Date: Tue, 5 Feb 2019 11:52:28 +
+Subject: [PATCH] Merge of r1852986 from trunk:
+
+mod_http2: disentangelment of stream and request method.
+
+
+
+git-svn-id: 
https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1852989 
13f79535-47bb-0310-9956-ffa450edef68
+---
+ modules/http2/h2_request.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/modules/http2/h2_request.c b/modules/http2/h2_request.c
+index 8899c4feb75..5ee88e9679f 100644
+--- a/modules/http2/h2_request.c
 b/modules/http2/h2_request.c
+@@ -266,7 +266,7 @@ request_rec *h2_request_create_rec(const h2_request *req, 
conn_rec *c)
+ 
+ /* Time to populate r with the data we have. */
+ r->request_time = req->request_time;
+-r->method = req->method;
++r->method = apr_pstrdup(r->pool, req->method);
+ /* Provide quick information about the request method as soon as known */
+ r->method_number = ap_method_number_of(r->method);
+ if (r->method_number == M_GET && r->method[0] == 'H') {
diff -Nru apache2-2.4.38/debian/patches/CVE-2019-0197.patch 
apache2-2.4.38/debian/patches/CVE-2019-0197.patch
--- apache2-2.4.38/debian/patches/CVE-2019-0197.patch   1970-01-01 
01:00:00.0 +0100
+++ apache2-2.4.38/debian/patches/CVE-2019-0197.patch   2019-04-07 
19:49:17.0 +0200
@@ -0,0 +1,93 @@
+# https://svn.apache.org/r1855406
+--- apache2.orig/modules/http2/h2_conn.c
 apache2/modules/http2/h2_conn.c
+@@ -305,6 +305,10 @@ conn_rec *h2_slave_create(conn_rec *mast
+ c->notes  = apr_table_make(pool, 5);
+ c->input_filters  = NULL;
+ c->output_filters = NULL;
++c->keepalives = 0;
++#if AP_MODULE_MAGIC_AT_LEAST(20180903, 1)
++c->filter_conn_ctx= NULL;
++#endif
+ c->bucket_alloc   = apr_bucket_alloc_create(pool);
+ c->data_in_input_filters  = 0;
+ c->data_in_output_filters = 0;
+@@ -332,16 +336,15 @@ conn_rec *h2_slave_create(conn_rec *mast
+ ap_set_module_config(c->conn_config, mpm, cfg);
+ }
+ 
+-ap_log_cerror(APLOG_MARK, APLOG_TRACE2, 0, c, 
+-  "h2_stream(%ld-%d): created slave", master->id, slave_id);
++ap_log_cerror(APLOG_MARK, APLOG_TRACE3,

Bug#913823: apache2: dav.load does not check for an already loaded dav_module

[Stefan Fritsch]

On Friday, 1 February 2019 03:49:22 CEST Nye Liu wrote:
> Package: apache2
> Version: 2.4.38-1
> Followup-For: Bug #913823
> 
> Workaround in /etc/apache2/mods-available/dav.load:
> 
> 
> LoadModule dav_module /usr/lib/apache2/modules/mod_dav.so
> 
> 
> Alternately just make dav_fs not depend on dav, it will autoload it.

This does not make sense. There is no functionality in mod_dav_fs that would 
autoload mod_dav. The "# Depends: dav" in dav_fs.load is a hint to a2enmod to 
enable dav.load, too. But this is visible by a symlink in mods-enabled. There 
must be another LoadModule somewhere else in your configuration.

You should probably do

grep -R dav_module /etc/apache2/{*.conf,*-enabled}

to find it. 

Bug#926400: libapr1-dbd-mysql: apache fails to start if dbd with mysql is used

[Stefan Fritsch]

serverity 926400 grave
thanks

On Thu, Apr 04, 2019 at 03:00:19PM +0200, csta...@digitus.itk.ppke.hu wrote:
> AH00526: Syntax error on line 19 of /etc/apache2/sites-enabled/mydomain.conf:
> Can't load driver file apr_dbd_mysql.so
> Action 'start' failed.

> In this current form this might be considered as an release-critical issue 
> for buster.

Yes, I agree this is RC.

There may be a patch in
https://bz.apache.org/bugzilla/show_bug.cgi?id=61517

Bug#884562: Enable CONFIG_SND_SOC_SPDIF for cubietruck spdif

[Stefan Fritsch]

Ping ?

I have opened a merge request 

https://salsa.debian.org/kernel-team/linux/merge_requests/137

Bug#902493: apache2-bin: Event MPM listener thread may get blocked by SSL shutdowns

[Stefan Fritsch]

On Monday, 11 March 2019 09:35:45 CET Sven Hartge wrote:
> This breaks quite fast, resulting in apache2 processes at 100% CPU, doing
> nothing but:

Thanks for the quick feed-back.

Second try with different approach is at

https://people.debian.org/~sf/apache2-mpm-event-902493/2.4.25-3+deb9u7~test2/

I have backported mpm_event from 2.4.28 and reverted one commit that was 
incompatible with 2.4.25. This was quite painless and I am more confident about 
this diff than the first one (even if it's three times the size).

Cheers,
Stefan

sha256 sums:

84b8b11ca6973144a3212fe7b65b12010a3118f0e4549afd70c30da41bffc56d  
apache2_2.4.25-3+deb9u7~test2_amd64.build
1ab44b8d84c5fd30aed5d6453dd6971261ab71872c01b6d3613cd40738652662  
apache2_2.4.25-3+deb9u7~test2_amd64.buildinfo
0a7a1b5b90523761721dfb61acce9fb7deb27449b9f16be69d10b5e2cb2822c3  
apache2_2.4.25-3+deb9u7~test2_amd64.changes
75829bb4280312ce340f49dad1c426b054ca867c611da27493da87b45a24892d  
apache2_2.4.25-3+deb9u7~test2_amd64.deb
9646a9cbe97942ba52077947e97ab573c2c79222c51cc5ca14980b1e9cf5651d  
apache2_2.4.25-3+deb9u7~test2.debian.tar.xz
d8b07337d522b806958865fff5c1f0f3274c0b5e5ebd12d41d4041ea49ab64c7  
apache2_2.4.25-3+deb9u7~test2.dsc
74d43eb1a85304882854d013e4b3270fbb13654e11e94b6ab12feea6574dada5  apache2-
bin_2.4.25-3+deb9u7~test2_amd64.deb
6b61dae59e72adc8282498d344a1c9714bb309fe33be76bb6e4e93e35473faeb  apache2-
data_2.4.25-3+deb9u7~test2_all.deb
778eb1ae5600af495fddbd598402f357560228c3b96eb2ae560e83e037abe244  apache2-
dbg_2.4.25-3+deb9u7~test2_amd64.deb
48073fe04b36539cc7517ae2a9e2d28fd5a74da8d7ce4f03d2ebd85b8787dfa5  apache2-
dev_2.4.25-3+deb9u7~test2_amd64.deb
316f391d37266fffc09ca0d628a208dd46e695bdaafd63018259ad895e4e62bb  apache2-
doc_2.4.25-3+deb9u7~test2_all.deb
ccd85a18e88827a78b60c47c711b1d1a0e04067b5bc135c092aa2374a010202c  apache2-ssl-
dev_2.4.25-3+deb9u7~test2_amd64.deb
839b59f6d3302132c21b5a5342d13d9dc31af4a5f0dee450c79e76bd078ef9fa  apache2-
suexec-custom_2.4.25-3+deb9u7~test2_amd64.deb
cb2da63a2e62a70d4f1e0d463c7e5b47ab37f79e2ff2b2e1fa7bf92f5d3971c4  apache2-
suexec-pristine_2.4.25-3+deb9u7~test2_amd64.deb
200514bc47564931121a8a3c654857ee62d865247c8fcf719fa6fd27508ef19e  apache2-
utils_2.4.25-3+deb9u7~test2_amd64.deb


signature.asc
Description: This is a digitally signed message part.

Bug#902493: apache2-bin: Event MPM listener thread may get blocked by SSL shutdowns

[Stefan Fritsch]

Hi,

I am not comfortable with switching to mpm_worker, either, since this would be 
a significant behavior change.

I have however tried a backport of the patch referenced in the upstream bug 
report and put a build here:

https://people.debian.org/~sf/apache2-mpm-event-902493/2.4.25-3+deb9u7~test1/
(sha256 sums below)

I don't think that I will put this patch into the next point release (9.9), 
but if there are a fair number of people who test this on their systems and 
report back, I may consider it for the 9.10 point release. So, please test 
this and report back after maybe 1-2 weeks.

* if it fixes the bug
* if you have seen any new issues
* on how many systems and how long you have tested it and how much load 
(requests/day) those systems see

Cheers,
Stefan


e1a038b77c952006d1a00ea80b83138e0a949f469798ce9eb14c9b403e2517be  
apache2_2.4.25-3+deb9u7~test1_amd64.build
c353243745bd936392d29b886fe89aeae76ad8afec153a93302bdd6e0e0d48cf  
apache2_2.4.25-3+deb9u7~test1_amd64.buildinfo
68b58ba59aa9cc24ac1ad1e3b515446dc1ac22a99e579d8747931363b1cce04c  
apache2_2.4.25-3+deb9u7~test1_amd64.changes
e7b8d0151f0dc960b21b78b778be7d15d7262344cbcc9b48c4bea2391f7cedcb  
apache2_2.4.25-3+deb9u7~test1_amd64.deb
e59734e7397ab42128f7baceec14386265f0dfa7312ba7d2bf6d0a8d3ae963cf  
apache2_2.4.25-3+deb9u7~test1.debian.tar.xz
bee5f76574ee771778ce592f11bf708ebeb2a34a4cc99c2770647684f026fd1b  
apache2_2.4.25-3+deb9u7~test1.dsc
f87ec2df1c9fee3e6bfde3c8b855a3ddb7ca1ab20ca877bd0e2b6bf3f05c80b2  
apache2_2.4.25.orig.tar.bz2
4a51a890d6056042928d6ec026095b8bdf01f207012fbdfb12eb72228a07bb98  apache2-
bin_2.4.25-3+deb9u7~test1_amd64.deb
cb9116f2c64521530f013676a0617c0d96625227e60948b2e294307c154846b2  apache2-
data_2.4.25-3+deb9u7~test1_all.deb
1c320faf6a36e39a12053d78bad3a0289bcdb70b6befb9171f5d0f04b1096a57  apache2-
dbg_2.4.25-3+deb9u7~test1_amd64.deb
7bfa7628d19b35606bf3c843268c23021685b6f5f138b8b79b581ba489619579  apache2-
dev_2.4.25-3+deb9u7~test1_amd64.deb
d9bb79db08c943b9540e7ce3e0e22331a163a7fcd3df7b761f51d91894c5459e  apache2-
doc_2.4.25-3+deb9u7~test1_all.deb
bebf38cee176889918824b9f34366f1762b940b936e9c6a5c67ffaf32b4f2807  apache2-ssl-
dev_2.4.25-3+deb9u7~test1_amd64.deb
445337a0b77a9ceaab13210831ac8159f60b2b085ed7b262bd718a4eb8e4cb4c  apache2-
suexec-custom_2.4.25-3+deb9u7~test1_amd64.deb
9680bcdda490feccdf1079d7f3406d13e2f8ddfa64eec9d40a921db2e59cc76f  apache2-
suexec-pristine_2.4.25-3+deb9u7~test1_amd64.deb
49a29207e44cdd16383c0d4d7f51ac8357a0fb3d80f284f30afaaf785d2fcd4c  apache2-
utils_2.4.25-3+deb9u7~test1_amd64.deb


signature.asc
Description: This is a digitally signed message part.

Bug#884562: Enable CONFIG_SND_SOC_SPDIF for cubietruck spdif

[Stefan Fritsch]

tags 884562 + patch
thanks

ping?

Is there any reason why this option cannot be enabled? It works for me.

Patch is attached.


Cheers,
Stefancommit ed6bb01ca53088401ddb7e17653e0a9b8bf8d9ee (HEAD -> master)
Author: Stefan Fritsch 
Date:   Sun Mar 3 13:40:49 2019 +0100

spdif

diff --git a/debian/config/armhf/config.armmp-lpae b/debian/config/armhf/config.armmp-lpae
index d5045f1..29673d7 100644
--- a/debian/config/armhf/config.armmp-lpae
+++ b/debian/config/armhf/config.armmp-lpae
@@ -19,3 +19,7 @@ CONFIG_ARM_LPAE=y
 ##
 CONFIG_ARM_SMMU=y
 
+##
+## file: sound/soc/codecs/Kconfig
+##
+CONFIG_SND_SOC_SPDIF=y

Bug#923661: tt-rss: PHP Fatal error: Uncaught PDOException: SQLSTATE[22001]: String data, right truncated

[Stefan Fritsch]

Package: tt-rss
Version: 18.12+dfsg-1
Severity: important

Hi,

after upgrading from 16.8+git20160826+dfsg-3 (which I had run under
Debian stretch), tt-rss fails to display anything after the login page.
There is this error:

[Sun Mar 03 13:15:12.954927 2019] [php7:error] [pid 2055] [client XXX] PHP 
Fatal error:  Uncaught PDOException: SQLSTATE[22001]: String data, right 
truncated: 1406 Data too long for column 'context' at row 1 in 
/usr/share/tt-rss/www/classes/logger/sql.php:18
Stack trace:
#0 /usr/share/tt-rss/www/classes/logger/sql.php(18): 
PDOStatement->execute(Array)
#1 /usr/share/tt-rss/www/classes/logger.php(28): Logger_SQL->log_error(8192, 
'strpos(): Non-s...', 'vendor/JShrink/...', 184, '1. vendor/JShri...')
#2 /usr/share/tt-rss/www/include/errorhandler.php(43): Logger->log_error(8192, 
'strpos(): Non-s...', 'vendor/JShrink/...', 184, '1. vendor/JShri...')
#3 [internal function]: ttrss_error_handler(8192, 'strpos(): Non-s...', 
'vendor/JShrink/...', 184, '1. vendor/JShri...')
#4 /usr/share/tt-rss/www/vendor/JShrink/Minifier.php(184): strpos('(-+{[@', 
false)
#5 /usr/share/tt-rss/www/vendor/JShrink/Minifier.php(144): 
JShrink\\Minifier->loop()
#6 /usr/share/tt-rss/www/vendor/JShrink/Minifier.php(110): 
JShrink\\Minifier->minifyDirectToOutput('/* global dijit...', Array)
#7 /usr/share/tt-rss/www/include/functions.php in 
/usr/share/tt-rss/www/classes/logger/sql.php on line 18, referer: https://XXX


I have then changed LOG_DESTINATION to syslog in config.php and it
worked again. In syslog, I see this message:

php: [tt-rss] E_DEPRECATED (8192) (vendor/JShrink/Minifier.php:184) strpos(): 
Non-string needles will be interpreted as strings in the future. Use an 
explicit chr() call to preserve the current behavior


If no other fix is possible in time for buster release, maybe the default for 
LOG_DESTINATION
could be changed?

Cheers,
Stefan


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

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

Versions of packages tt-rss depends on:
ii  dbconfig-common 2.0.11
ii  dbconfig-mysql  2.0.11
ii  debconf [debconf-2.0]   1.5.70
ii  init-system-helpers 1.56+nmu1
ii  libapache2-mod-php  2:7.3+69
ii  libapache2-mod-php7.3 [libapache2-mod-php]  7.3.2-3
ii  libjs-dojo-core 1.14.2+dfsg1-1
ii  libjs-dojo-dijit1.14.2+dfsg1-1
ii  libjs-scriptaculous 1.9.0-2
ii  lsb-base10.2018112800
ii  php 2:7.3+69
ii  php-cli 2:7.3+69
ii  php-mbstring2:7.3+69
ii  php-mysql   2:7.3+69
ii  php-php-gettext 1.0.12-0.1
ii  php-xml 2:7.3+69
ii  php7.0-cli [php-cli]7.0.33-0+deb9u2
ii  php7.0-json [php-json]  7.0.33-0+deb9u2
ii  php7.0-mbstring [php-mbstring]  7.0.33-0+deb9u2
ii  php7.0-xml [php-xml]7.0.33-0+deb9u2
ii  php7.3 [php]7.3.2-3
ii  php7.3-cli [php-cli]7.3.2-3
ii  php7.3-json [php-json]  7.3.2-3
ii  php7.3-mbstring [php-mbstring]  7.3.2-3
ii  php7.3-xml [php-xml]7.3.2-3
ii  phpqrcode   1.1.4-3

Versions of packages tt-rss recommends:
ii  apache2 [httpd] 2.4.38-2
ii  ca-certificates 20190110
ii  php-curl2:7.3+69
ii  php-gd  2:7.3+69
ii  php-mcrypt  1:7.0+49
ii  php7.0-gd [php-gd]  7.0.33-0+deb9u2
ii  php7.0-mcrypt [php-mcrypt]  7.0.33-0+deb9u2
ii  php7.3-curl [php-curl]  7.3.2-3
ii  php7.3-gd [php-gd]  7.3.2-3

Versions of packages tt-rss suggests:
pn  php-apc   
pn  sphinxsearch  

-- Configuration Files:
/etc/tt-rss/apache.conf changed [not included]
/etc/tt-rss/config.php changed [not included]

-- debconf information:
  tt-rss/pgsql/manualconf:
  tt-rss/internal/reconfiguring: false
  tt-rss/pgsql/authmethod-admin: ident
* tt-rss/dbconfig-reinstall: true
  tt-rss/upgrade-error: abort
* tt-rss/database-type: mysql
* tt-rss/reconfigure-webserver: apache2
* tt-rss/dbconfig-install: true
* tt-rss/db/basepath:
  tt-rss/remote/port:
  tt-rss/dbconfig-remove: true
* tt-rss/passwords-do-not-match:
  tt-rss/pgsql/admin-user: postgres
  tt-rss/remove-error: abort
  tt-rss/remote/newhost:
* tt-rss/db/dbname: ttrss
* tt-rss/dbconfig-upgrade: true
  

Bug#915103: Apache2 HTTP/2 connection problems with Safari clients

[Stefan Fritsch]

On Tuesday, 12 February 2019 16:45:34 CET Philip Iezzi wrote:
> Hi Stefan,
> 
> Confirming again that your patch from Feb 4th fixed the issue. I've got now
> positive feedback from my customers and have upgraded all HTTPS-sites back
> to HTTP/2. Will this patch make it into Debian Stretch?
> 
> Thanks,
> Philip

yes, I intend to have it included in the 9.9 stable point release. 
Unfortunately, it was just a bit too late for the 9.8 which is due today.

Bug#902493: apache2-bin: Event MPM listener thread may get blocked by SSL shutdowns

[Stefan Fritsch]

On Tuesday, 12 February 2019 17:44:39 CET Gedalya wrote:
> On 2/13/19 12:38 AM, Jan Wagner wrote:
> > backports is not meant for fixing things. beside that it would require
> > all rebuilding most of the additional apache modules not shiped by the
> > apache2 source package.
> 
> So we're back to doing nothing at all?
> 
> I'm not at all advocating backports as a solution, rather suggesting that it
> would be _something_ that could be done while the issue is not fixed, for
> whatever reason.
> 
> As for rebuilding other sources packages, yes, but like you said, not only
> is backports not for fixing things, it has been traditionally known to
> break things as well. Packages from backports are indeed sometimes not
> installable to some users.
> 
> In my case I wasn't using any other modules (PHP via fcgi), so apache2, apr
> and apr-util were enough. Again, we're not forcing anyone to use this, nor
> are we saying that this addresses the issue.

I will think about it. It I definitely won't have time in the next 2-3 weeks.

Cheers,
Stefan

Bug#902493: apache2-bin: Event MPM listener thread may get blocked by SSL shutdowns

[Stefan Fritsch]

Between 2.4.25 and the fix for this issue, there were some intrusive 
changes in mpm_evnt. If we did a backport, rhe risk of introducing 
regressions would be quite high. Therefore, and because the next Debian 
stable release is quite near, I don't think it makes sense to backport the 
fix.

Bug#921024: apache2: DEP8 failure with 2.4.38-1: allowmethods.t

[Stefan Fritsch]

On Thursday, 31 January 2019 19:16:06 CET Andreas Hasenack wrote:
> Package: apache2
> Version: 2.4.38-1
> Severity: normal
> 
> Dear Maintainer,
> 
> The updated 2.4.38-1 package for apache2 triggered a DEP8 test failure:
> 
> https://ci.debian.net/packages/a/apache2/unstable/amd64/
> 
> >From https://ci.debian.net/data/autopkgtest/unstable/amd64/a/
apache2/1808954/log.gz:
> ...
> # Failed test 10 in t/modules/allowmethods.t at line 44 fail #10
> t/modules/allowmethods.t 
> Failed 1/10 subtests
> 
> The logs are sparse, to say the best, but this wasn't failing with
> 2.4.37-1. Unfortunately I'm not familiar with this test suite and
> cannot pinpoint which config apache2 was using at that time, nor which
> request failed exactly.
> 
> I was merging 2.4.38-1 into Ubuntu, and hit the same failure there.


At the top of debian/tests/run-test-suite , there is:

# set to "-v t/modules/ext_filter.t ..." to run only a few test, but verbose
TESTS=""

Changing that should give a bit more verbosity.

Also, the test frame work comes from a separate repository [1] and may need to 
be updated for new upstream releases. It's simply dumped into debian/perl-
framework in the debian package. On the other hand, the diff between our 
version and the current upstream version does not look like having to do 
anything with allowmethods.

Another idea is that maybe our perl libs behave differently with redirects. By 
changing /reset to /reset/ in t/modules/allowmethods.t one could avoid the 
redirect done by mod_directory.

I don't have time right now to try any of these. Maybe in the next few days. 
If somebody else has time, go ahead.

Cheers,
Stefan

[1]  https://svn.apache.org/repos/asf/httpd/test/framework/trunk

Bug#915103: Apache2 HTTP/2 connection problems with Safari clients

[Stefan Fritsch]

Hi Philip,

sorry for the late respone, I have been quite busy with other things.

I could find no indication that any other upstream release has the same bug. 
Therefore I hope that adding more fixes from upstream versions up to the 
version from where I took the security fixes (2.4.34 and 2.4.35) should fix the 
issue. That's how I picked the first patch I have sent you. There is one other 
commit that may fit. A new patch is applied (leave out the first patch I sent).

If that does not work we need to find a more targeted approach. You could try 
increasing the http2 log level  and see if there are any log messages that 
appear only when safari gives the error message. You could try a quite high 
log level like

  loglevel http2:trace1

or even trace2.

Cheers,
Stefan
diff --git a/debian/patches/http2-r1832566.diff b/debian/patches/http2-r1832566.diff
new file mode 100644
index 00..7ce7335100
--- /dev/null
+++ b/debian/patches/http2-r1832566.diff
@@ -0,0 +1,43 @@
+--- apache2.orig/modules/http2/h2_conn.c
 apache2/modules/http2/h2_conn.c
+@@ -240,7 +240,19 @@ apr_status_t h2_conn_run(struct h2_ctx *
+  && mpm_state != AP_MPMQ_STOPPING);
+ 
+ if (c->cs) {
+-c->cs->state = CONN_STATE_LINGER;
++switch (session->state) {
++case H2_SESSION_ST_INIT:
++case H2_SESSION_ST_IDLE:
++case H2_SESSION_ST_BUSY:
++case H2_SESSION_ST_WAIT:
++c->cs->state = CONN_STATE_WRITE_COMPLETION;
++break;
++case H2_SESSION_ST_CLEANUP:
++case H2_SESSION_ST_DONE:
++default:
++c->cs->state = CONN_STATE_LINGER;
++break;
++}
+ }
+ 
+ return APR_SUCCESS;
+--- apache2.orig/modules/http2/h2_version.h
 apache2/modules/http2/h2_version.h
+@@ -27,7 +27,7 @@
+  * @macro
+  * Version number of the http2 module as c string
+  */
+-#define MOD_HTTP2_VERSION "1.10.16"
++#define MOD_HTTP2_VERSION "1.10.20"
+ 
+ /**
+  * @macro
+@@ -35,7 +35,7 @@
+  * release. This is a 24 bit number with 8 bits for major number, 8 bits
+  * for minor and 8 bits for patch. Version 1.2.3 becomes 0x010203.
+  */
+-#define MOD_HTTP2_VERSION_NUM 0x010a10
++#define MOD_HTTP2_VERSION_NUM 0x010a14
+ 
+ 
+ #endif /* mod_h2_h2_version_h */
diff --git a/debian/patches/series b/debian/patches/series
index 014d958573..21ff3c5da4 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -30,3 +30,4 @@ mod_http2_mem_usage_32bit.diff
 fcgi_crash.diff
 CVE-2018-1333-mod_http2_DoS.diff
 CVE-2018-11763-mod_http2_DoS-SETTINGS.diff
+http2-r1832566.diff

Bug#914732: lists.debian.org: Request for new mailing list: debian-dug-muc

[Stefan Fritsch]

On Mon, 26 Nov 2018 20:12:24 +0100 Michael Banck  wrote:
> Please create the Debian User Group list debian-dug-muc for the Munich
> local area user group, https://wiki.debian.org/LocalGroups/DebianMuc

seconded.

Cheers,
Stefan

Bug#915103: Apache2 HTTP/2 connection problems with Safari clients

[Stefan Fritsch]

Hi Philip,

On Friday, 14 December 2018 22:49:13 CET Philip Iezzi wrote:
> But the patch from bee2facd9343beda10677b139cd9b2e49e986f01
> (https://salsa.debian.org/apache-team/apache2/commit/bee2facd9343beda10677b
> 139cd9b2e49e986f01) was already applied to latest apache2 package in Debian
> 9.6 (modules/http2/h2_bucket_beam.c). How come this should fix the problem?
> Or did you rather mean this patch is the source of these issues.

Yes, that's the problematic patch, not the fix.

I have some hope that the fix for the issue is this upstream commit:
https://svn.apache.org/viewvc?view=revision=1843468

It would be nice if you could apply the attached patch to the debian source 
package, rebuild it, and check if it fixes the issue. Thanks.

Cheers,
Stefan
diff --git a/debian/patches/http-EOS-handling.diff b/debian/patches/http-EOS-handling.diff
new file mode 100644
index 00..501ab5a7b6
--- /dev/null
+++ b/debian/patches/http-EOS-handling.diff
@@ -0,0 +1,26 @@
+# https://svn.apache.org/viewvc?view=revision=1843468
+# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915103
+--- apache2.orig/modules/http2/h2_session.c
 apache2/modules/http2/h2_session.c
+@@ -1094,6 +1094,10 @@ static ssize_t stream_data_cb(nghttp2_se
+ case APR_SUCCESS:
+ break;
+ 
++case APR_EOF:
++eos = 1;
++break;
++
+ case APR_ECONNRESET:
+ case APR_ECONNABORTED:
+ return NGHTTP2_ERR_CALLBACK_FAILURE;
+--- apache2.orig/modules/http2/h2_stream.c
 apache2/modules/http2/h2_stream.c
+@@ -915,7 +915,7 @@ apr_status_t h2_stream_out_prepare(h2_st
+   (long)*plen, *peos);
+ }
+ else {
+-status = APR_EAGAIN;
++status = (stream->output && h2_beam_is_closed(stream->output))? APR_EOF : APR_EAGAIN;
+ ap_log_cerror(APLOG_MARK, APLOG_TRACE1, 0, c,
+   H2_STRM_MSG(stream, "prepare, no data"));
+ }
diff --git a/debian/patches/series b/debian/patches/series
index 014d958573..93b77b7f35 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -30,3 +30,4 @@ mod_http2_mem_usage_32bit.diff
 fcgi_crash.diff
 CVE-2018-1333-mod_http2_DoS.diff
 CVE-2018-11763-mod_http2_DoS-SETTINGS.diff
+http-EOS-handling.diff

Bug#914297: apache2: getrandom call blocks on first startup, systemd kills with timeout

[Stefan Fritsch]

I have started a thread on debian-devel:

https://lists.debian.org/debian-devel/2018/12/msg00184.html

Please participate.

Cheers,
Stefan

Bug#914297: apache2: getrandom call blocks on first startup, systemd kills with timeout

[Stefan Fritsch]

On Mon, 17 Dec 2018, Michael Biebl wrote:

> Am 17.12.18 um 13:52 schrieb Stefan Fritsch:
> > On Mon, 17 Dec 2018, Michael Biebl wrote:
> >>> It turns out there was a similar bug against openssh which was closed as 
> >>> wontfix [1]. I don't see how apache can do anything about this, either.
> >>
> >> There is. Don't request high-quality randomness during boot unless you
> >> explicitly need it.
> > 
> > That's utterly wrong. We do crypto and need high-quality randomness. There 
> > can be no discussion about this. The system needs to make sure that we 
> > have entropy when we start network daeamons.
> 
> You can't generate entropy out of thin air unfortunately.

But we have good entropy on disk. And it's in the kernel. We just need to 
tell the kernel.

> 
> > The whole point of the getrandom() interface is that it cannot fail and 
> > that its users don't need potentially buggy fallback code. If you break 
> > that assumption, you will introduce security issues in the network daemons 
> > that use weak entropy just in order to not block.
> 
> What I was suggesting is that you don't use getrandom() for places where
> you don't need it.
> Anyway, your anger should not be directed at systemd here.
> It's the wrong recipient.

No, it isn't.

Bug#914297: apache2: getrandom call blocks on first startup, systemd kills with timeout

[Stefan Fritsch]

On Mon, 17 Dec 2018, Michael Biebl wrote:
> > Well, this problem is much more widespread (in terms of software that
> > requests entropy needlessly) than you might think. If you override the
> > unit for something as deterministic as systemd-tmpfiles-setup.service
> > to run it under strace and log the result, you'll see numerous calls
> > to getrandom().
> 
> Incidentally there is
> https://github.com/systemd/systemd/commit/abdcb688a8a82807cb5f864babdba91c859ac5f8
> 
> This patch is not yet in the Debian package.
> 
> I'm well aware that this potentially affects quite a lot of packages,
> but I can only repeat that systemd-random-seed is not the answer here.
> 
> I fear that indeed the only option is to review each and every service
> during boot which requests randomness, unless the change in
> openssl/kernel is reverted.


No, that's wrong. This will introduce security issues in those services.

> I don't think making haveged essential would make sense, as this problem
> manifests typically in containerized or virtualized environments.
> For the later, if using KVM, the best option afaik is to use virtio-rng.
> 
> And yes, at this point I think the only solution is to document this in
> the release notes.

No. This needs discussion on debian-devel, or if there is no consensous, 
the technical committe.

Bug#914297: apache2: getrandom call blocks on first startup, systemd kills with timeout

[Stefan Fritsch]

On Mon, 17 Dec 2018, Michael Biebl wrote:
> > It turns out there was a similar bug against openssh which was closed as 
> > wontfix [1]. I don't see how apache can do anything about this, either.
> 
> There is. Don't request high-quality randomness during boot unless you
> explicitly need it.

That's utterly wrong. We do crypto and need high-quality randomness. There 
can be no discussion about this. The system needs to make sure that we 
have entropy when we start network daeamons.

The whole point of the getrandom() interface is that it cannot fail and 
that its users don't need potentially buggy fallback code. If you break 
that assumption, you will introduce security issues in the network daemons 
that use weak entropy just in order to not block.

Cheers,
Stefan

Bug#914297: apache2: getrandom call blocks on first startup, systemd kills with timeout

[Stefan Fritsch]

reassign 914297 systemd
affects 914297 apache2
thanks

On Saturday, 15 December 2018 02:24:54 CET Alexander E. Patrakov wrote:
> Stefan Fritsch :
> > The rng should be initialized after the seed is loaded from disk.
> 
> This is false according to systemd developers. Its state is changed,
> but it is still not initialized, because they think that the seed
> might come from a gold master image.

That's broken, then.

It turns out there was a similar bug against openssh which was closed as 
wontfix [1]. I don't see how apache can do anything about this, either.

But I disagree with the systemd maintainers that there is nothing that systemd 
can do about this. They should credit the entropy loaded from the seed but 
save a new seed immediately after reading it during startup, to avoid that the 
same seed is used more than once.

A second (but  worse) alternative would be to provide something that waits for 
the RNG to be initialized that other services can depend on.

Cheers,
Stefan

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912087

Bug#914297: apache2: getrandom call blocks on first startup, systemd kills with timeout

[Stefan Fritsch]

On Friday, 14 December 2018 12:43:29 CET Adrian Bunk wrote:
> On Sun, Nov 25, 2018 at 11:35:37PM +0100, Stefan Fritsch wrote:
> >...
> >
> > I don't see why it should take so
> > long for the random number generator to initialize.
> >
> >...
> 
> On embedded systems without hwrng "10 minutes" or "2 hours" are
> real-life observations for the time it takes.
> 
> Note that this became more problematic due to the CVE-2018-1108[1]
> fix (reverted in stretch, but in buster/unstable).

Is systemd-random-seed.service broken there? The rng should be initialized 
after the seed is loaded from disk. Adrian, please send the output of

journalctl -b UNIT=apache2.service + UNIT=systemd-random-seed.service + 
_TRANSPORT=kernel|grep -i -e apache -e random

if apache2 fails to start.

Bug#915103: Apache2 HTTP/2 connection problems with Safari clients

[Stefan Fritsch]

On Friday, 30 November 2018 15:54:07 CET Andreas Ziegler wrote:
> Package: apache2
> Version: 2.4.25-3+deb9u6
> 
> When i load a picture using safari from an apache webserver with HTTP/2
> enabled and repeat that multiple times in a row (F5),
> at least each 3rd request fails with
> "Failed to load resource: The network connection was lost."
> This happens regardless of the device (Mac, iPad) and regardless of the
> ISP or the provider or hardware of the webserver in the datacenter.
> The user experience when surfing on an affected webserver is really bad
> with Safari.

http://svn.apache.org/viewvc?view=revision=1843468 sounds like it 
could be a fix for this issue

Bug#840580: apache2-bin: crashes when issuing a restart while mod_cgid is enabled

[Stefan Fritsch]

On Sunday, 25 November 2018 19:07:56 CET Bernhard Übelacker wrote:
> Dear Maintainer,
> tried to find out the actual location that the backtrace points to.
> 
> Unfortunately I could not make any clue out of the line
> containing /usr/sbin/apache2(+0x29e450).
> 
> But at least, I think, the line containing mod_mpm_prefork.so(+0x4c08)
> translates to function prefork_run in server/mpm/prefork/prefork.c.
> 
> As this is a rather big function, and looks like it is never left while
> the server runs, and there are no local arrays accessed, the stack
> canary may be overwritten by some function called from there.
> But the stack canary is just checked when prefork_run exits.
> 
> Kind regards,
> Bernhard

The  "bt full" gdb command is the important one. Please show its output as 
described in README.backtrace

Bug#914297: apache2: getrandom call blocks on first startup, systemd kills with timeout

[Stefan Fritsch]

How long is the timeout after which it is killed? What is the status of 
systemd-random-seed.service in that case? I don't see why it should take so 
long for the random number generator to initialize. But maybe apache2 needs to 
add a dependency.

Please provide the output of

journalctl -b UNIT=apache2.service + UNIT=systemd-random-seed.service + 
_TRANSPORT=kernel|grep -i -e apache -e random

when apache2 has failed to start.

Bug#910917: RFA: apache2 -- Apache HTTP Server

[Stefan Fritsch]

Hi,

Xavier, yes, please do a join request. If you are looking for work, one thing 
that should be done before buster is enabling http/2 by default (#880993).

Mosab and Jason, are you still interested?

Cheers,
Stefan

On Tuesday, 20 November 2018 10:41:55 CET Xavier wrote:
> Hi all,
> 
> I'm DD, Apache user and maintainer of libapache2-mod-fcgid. I can't
> maintain this package alone since I'm not enough experimented in C but I
> can help (review, tests and upload if needed). So what is the best,
> join-request to apache-team on salsa for Jason, Mosab and me?
> 
> Cheers,
> Xavier

Bug#910917: RFA: apache2 -- Apache HTTP Server

[Stefan Fritsch]

Hi Jason,

sorry for the late response. I forgot to subscribe to the wnpp report and did 
not get your mail.

On Saturday, 20 October 2018 04:50:50 CET Jason Vigil wrote:
> To be honest, I'm not terribly experienced with Apache HTTPD nor Debian
> packaging, but I am fairly experienced as a Debian user and Linux user in
> general. In addition, I am passionate about open source and a quick
> learner. I am interested in contributing to Debian and apache2 looks like
> the most exciting package that is up for adoption right now. Wondering if
> this could be a good avenue for getting involved in Debian. What do you
> think? Reach out to me on IRC??? vigiljt is my user.

In this case I would recommend that you get packaging practice with some 
simpler packages first. Also, in my opinion, it only makes sense to maintain 
if you are actually using apache2 yourself. You could also look for bugs in 
packages you use and care about and try to fix those. If you want to look at 
bugs in apache2, that's fine, too. Maybe the rc-alert tool in the devscripts 
package can help you identify interesting bugs / packages.

Cheers,
Stefan

Bug#910917: RFA: apache2 -- Apache HTTP Server

[Stefan Fritsch]

Hi Mosab,

sorry for the late response. I forgot to subscribe to the wnpp report and did 
not get your mail.

On Thursday, 18 October 2018 10:47:34 CET Mosab Ibrahim wrote:
> I don't have experience with packaging, but I do have experience with using
> Apache HTTP Server, and I am a quick learner.
> 
> Would like to be part of the maintaining team for this package.

The apache2 package is not the ideal package for beginers, but we will see. It 
may still work out well, especially if there are other volunteers that have 
more experience in packaging.

I suggest that you start by looking at some bug reports and try to debug / 
respond / produce patches. There are probably also some bugs that can be 
closed because they concern debian versions that are no longer supported, or  
the submitter did not reply to some questions.  For a start, if you produce a 
patch for a bug, simply send it to the bug or to me. If that works out, I will 
give you commit access to the package repository [1] later on.

You should probably also read at least parts of the new maintainer guide [2].

I also hang around on the IRC channel #apache on oftc [3], but response times 
may not be fast.

Cheers,
Stefan

[1] https://salsa.debian.org/apache-team/apache2
[2] https://www.debian.org/doc/manuals/maint-guide/index.en.html
[3] https://www.oftc.net/


> 
> Cheers,
> Mosab.
> On Sat, 13 Oct 2018 13:29:51 +0200 Stefan Fritsch 
> 
> wrote:
> > Package: wnpp
> > Severity: normal
> > 
> > I am looking for new maintainers for the Apache httpd server (the
> > apache2 package).
> > 
> > The apache2 package has a relatively complex packaging and config
> 
> file
> 
> > handling. There are also a lot of third-party module packages in
> 
> Debian.
> 
> > Therefore, some experience with using Apache httpd and with Debian
> > packaging is highly recommended.
> > 
> > 
> > After more than 11 years of maintaining apache2, my interests have
> > shifted significantly and I no longer have sufficient time and
> > motivation to maintain it properly. Therefore, I am looking for
> 
> someone
> 
> > (or several people) to take over the package. I may stay as a
> > co-maintainer for some time, but I want somebody else to do the
> 
> majority
> 
> > of the work. Therefore, I have chosen RFA and not RFH for the bug
> 
> title.
> 
> > With the exception of some contributions from Ondřej now and then,
> 
> there
> 
> > are no other active people on the apache packaing "team" anymore.
> > 
> > 
> > Cheers,
> > Stefan

Bug#912277: apache2: does not start any more: AH01903: Failed to configure CA certificate chain!

[Stefan Fritsch]

On Sunday, 4 November 2018 18:36:19 CET Thorsten Glaser wrote:
> This is a real WTF. I found https://serverfault.com/a/892300/189656
> and thought “hey, Apache 2 still documents SSLCertificateChainFile,
> plus it’s the proper way to specify the chain given it’s normally
> separate from the certificates, and there’s no warning message about
> that directive, but let’s give it a shot”.

SSLCertificateChainFile still does something, it's not a no-op in the source. 
Maybe you are hitting https://bz.apache.org/bugzilla/show_bug.cgi?id=62880 . 
That would  cause non-deterministic behavior (depending on what went on before 
the SSLCertificateChainFile is encountered).  If you have time, you could try 
the patch attached to that bug. Right now, I don't have time to prepare test 
packages.

Cheers,
Stefan

Bug#912770: stretch-pu: package apache2/2.4.25-3+deb9u6

[Stefan Fritsch]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi,

please review apache2/2.4.25-3+deb9u6 for inclusion into the next
stretch point release. Here is the changelog:

* CVE-2018-1333: mod_http2: Fix DoS by worker exhaustion. Closes: #904106
* CVE-2018-11763: mod_http2: Fix DoS by continuous SETTINGS.
  Closes: #909591
* mod_proxy_fcgi: Fix segfault. Closes: #902906

Debdiff is attached.

Cheers,
Stefan
diff -Nru apache2-2.4.25/debian/changelog apache2-2.4.25/debian/changelog
--- apache2-2.4.25/debian/changelog 2018-06-02 10:01:13.0 +0200
+++ apache2-2.4.25/debian/changelog 2018-11-03 19:46:19.0 +0100
@@ -1,3 +1,12 @@
+apache2 (2.4.25-3+deb9u6) stretch; urgency=medium
+
+  * CVE-2018-1333: mod_http2: Fix DoS by worker exhaustion. Closes: #904106
+  * CVE-2018-11763: mod_http2: Fix DoS by continuous SETTINGS.
+Closes: #909591
+  * mod_proxy_fcgi: Fix segfault. Closes: #902906
+
+ -- Stefan Fritsch   Sat, 03 Nov 2018 19:46:19 +0100
+
 apache2 (2.4.25-3+deb9u5) stretch; urgency=medium
 
   * Upgrade mod_http and mod_proxy_http2 to the versions from 2.4.33. This
diff -Nru 
apache2-2.4.25/debian/patches/CVE-2018-11763-mod_http2_DoS-SETTINGS.diff 
apache2-2.4.25/debian/patches/CVE-2018-11763-mod_http2_DoS-SETTINGS.diff
--- apache2-2.4.25/debian/patches/CVE-2018-11763-mod_http2_DoS-SETTINGS.diff
1970-01-01 01:00:00.0 +0100
+++ apache2-2.4.25/debian/patches/CVE-2018-11763-mod_http2_DoS-SETTINGS.diff
2018-11-03 19:45:38.0 +0100
@@ -0,0 +1,458 @@
+# https://svn.apache.org/viewvc?view=revision=1840757
+# CVE-2018-11763
+--- apache2.orig/modules/http2/h2_session.c
 apache2/modules/http2/h2_session.c
+@@ -235,6 +235,7 @@ static int on_data_chunk_recv_cb(nghttp2
+ stream = h2_session_stream_get(session, stream_id);
+ if (stream) {
+ status = h2_stream_recv_DATA(stream, flags, data, len);
++dispatch_event(session, H2_SESSION_EV_STREAM_CHANGE, 0, "stream data 
rcvd");
+ }
+ else {
+ ap_log_cerror(APLOG_MARK, APLOG_DEBUG, 0, session->c, APLOGNO(03064)
+@@ -317,9 +318,9 @@ static int on_header_cb(nghttp2_session
+ }
+ 
+ /**
+- * nghttp2 session has received a complete frame. Most, it uses
+- * for processing of internal state. HEADER and DATA frames however
+- * we need to handle ourself.
++ * nghttp2 session has received a complete frame. Most are used by nghttp2
++ * for processing of internal state. Some, like HEADER and DATA frames,
++ * we need to act on.
+  */
+ static int on_frame_recv_cb(nghttp2_session *ng2s,
+ const nghttp2_frame *frame,
+@@ -376,6 +377,9 @@ static int on_frame_recv_cb(nghttp2_sess
+   "h2_stream(%ld-%d): WINDOW_UPDATE incr=%d", 
+   session->id, (int)frame->hd.stream_id,
+   frame->window_update.window_size_increment);
++if (nghttp2_session_want_write(session->ngh2)) {
++dispatch_event(session, H2_SESSION_EV_FRAME_RCVD, 0, "window 
update");
++}
+ break;
+ case NGHTTP2_RST_STREAM:
+ ap_log_cerror(APLOG_MARK, APLOG_DEBUG, 0, session->c, 
APLOGNO(03067)
+@@ -402,6 +406,12 @@ static int on_frame_recv_cb(nghttp2_sess
+frame->goaway.error_code, NULL);
+ }
+ break;
++case NGHTTP2_SETTINGS:
++if (APLOGctrace2(session->c)) {
++ap_log_cerror(APLOG_MARK, APLOG_TRACE2, 0, session->c,
++  H2_SSSN_MSG(session, "SETTINGS, len=%ld"), 
(long)frame->hd.length);
++}
++break;
+ default:
+ if (APLOGctrace2(session->c)) {
+ char buffer[256];
+@@ -413,7 +423,40 @@ static int on_frame_recv_cb(nghttp2_sess
+ }
+ break;
+ }
+-return (APR_SUCCESS == rv)? 0 : NGHTTP2_ERR_PROTO;
++
++if (session->state == H2_SESSION_ST_IDLE) {
++/* We received a frame, but session is in state IDLE. That means the 
frame
++ * did not really progress any of the (possibly) open streams. It was 
a meta
++ * frame, e.g. SETTINGS/WINDOW_UPDATE/unknown/etc.
++ * Remember: IDLE means we cannot send because either there are no 
streams open or
++ * all open streams are blocked on exhausted WINDOWs for outgoing 
data.
++ * The more frames we receive that do not change this, the less 
interested we
++ * become in serving this connection. This is expressed in increasing 
"idle_delays".
++ * Eventually, the connection will timeout and we'll close it. */
++session->idle_frames = H2MIN(session->idle_frames + 1, 
session->frames_received);
++ap_log_cerror( APLOG_MARK, APLOG_TRACE2, 0, session->c,
++

Bug#912277: apache2: does not start any more: AH01903: Failed to configure CA certificate chain!

[Stefan Fritsch]

On Monday, 29 October 2018 20:31:54 CET Thorsten Glaser wrote:
> tglase@tglase:~ $ cat /var/log/apache2/error.log
> [Mon Oct 29 20:18:58.090841 2018] [ssl:emerg] [pid 17306] AH01903: Failed to
> configure CA certificate chain!
> [Mon Oct 29 20:18:58.090919 2018] [ssl:emerg] [pid 17306] AH02311: Fatal
> error initialising mod_ssl, exiting.
> See /var/log/apache2/error.log for more information AH00016: Configuration
> Failed

Have you looked into  /var/log/apache2/error.log if there is more information? 
If there is none, try adding loglevel ssl:debug and re-try.

Bug#910917: RFA: apache2 -- Apache HTTP Server

[Stefan Fritsch]

Package: wnpp
Severity: normal

I am looking for new maintainers for the Apache httpd server (the
apache2 package).

The apache2 package has a relatively complex packaging and config file
handling. There are also a lot of third-party module packages in Debian.
Therefore, some experience with using Apache httpd and with Debian
packaging is highly recommended. 


After more than 11 years of maintaining apache2, my interests have
shifted significantly and I no longer have sufficient time and
motivation to maintain it properly. Therefore, I am looking for someone
(or several people) to take over the package. I may stay as a
co-maintainer for some time, but I want somebody else to do the majority
of the work. Therefore, I have chosen RFA and not RFH for the bug title.

With the exception of some contributions from Ondřej now and then, there
are no other active people on the apache packaing "team" anymore.


Cheers,
Stefan

Bug#910914: kmail crashes if akonadi is already running

[Stefan Fritsch]

Package: kmail
Version: 4:18.08.1-1
Severity: important

If I start kmail for the second time after a login, i.e. while akonadi
is already, it crashes.

A workaround is to never close it after login, or do 'akonadictl stop'
before starting it again.

Backtrace is attached.



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

Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kmail depends on:
ii  akonadi-server   4:18.08.1-1
ii  kdepim-runtime   4:18.08.1-1
ii  kio  5.49.0-1
ii  libc62.27-6
ii  libgcc1  1:8.2.0-7
ii  libgpgmepp6  1.11.1-2
ii  libkf5akonadiagentbase5  4:18.08.1-1
ii  libkf5akonadicontact54:18.08.1-1
ii  libkf5akonadicore5abi2   4:18.08.1-1
ii  libkf5akonadimime5   4:18.08.1-2
ii  libkf5akonadisearch-bin  4:18.08.1-1
ii  libkf5akonadisearch-plugins  4:18.08.1-1
ii  libkf5akonadisearchdebug54:18.08.1-1
ii  libkf5akonadisearchpim5  4:18.08.1-1
ii  libkf5akonadiwidgets5abi14:18.08.1-1
ii  libkf5bookmarks5 5.49.0-1
ii  libkf5calendarcore5abi2  4:18.08.1-1
ii  libkf5calendarutils5 4:18.08.1-1
ii  libkf5codecs55.49.0-1
ii  libkf5completion55.49.0-1
ii  libkf5configcore55.49.0-1
ii  libkf5configgui5 5.49.0-1
ii  libkf5configwidgets5 5.49.0-1
ii  libkf5contacts5  4:18.08.1-1
ii  libkf5coreaddons55.49.0-1
ii  libkf5crash5 5.49.0-1
ii  libkf5dbusaddons55.49.0-1
ii  libkf5followupreminder5  4:18.08.1-1
ii  libkf5grantleetheme-plugins  18.08.1-1
ii  libkf5gravatar5abi2  4:18.08.1-1
ii  libkf5guiaddons5 5.49.0-1
ii  libkf5i18n5  5.49.0-1
ii  libkf5iconthemes55.49.0-1
ii  libkf5identitymanagement518.08.1-1
ii  libkf5itemmodels55.49.0-1
ii  libkf5itemviews5 5.49.0-1
ii  libkf5jobwidgets55.49.0-1
ii  libkf5kcmutils5  5.49.0-1
ii  libkf5kiocore5   5.49.0-1
ii  libkf5kiofilewidgets55.49.0-1
ii  libkf5kiowidgets55.49.0-1
ii  libkf5kontactinterface5  18.08.1-1
ii  libkf5ksieveui5  4:18.08.1-1
ii  libkf5libkdepim-plugins  4:18.08.1-1
ii  libkf5libkdepim5 4:18.08.1-1
ii  libkf5libkdepimakonadi5  4:18.08.1-1
ii  libkf5libkleo5   4:18.08.1-1
ii  libkf5mailcommon5abi24:18.08.1-1
ii  libkf5mailtransport5 18.08.1-2
ii  libkf5mailtransportakonadi5  18.08.1-2
ii  libkf5messagecomposer5abi1   4:18.08.1-1
ii  libkf5messagecore5abi1   4:18.08.1-1
ii  libkf5messagelist5abi1   4:18.08.1-1
ii  libkf5messageviewer5abi1 4:18.08.1-1
ii  libkf5mime5abi1  18.08.1-1
ii  libkf5mimetreeparser5abi14:18.08.1-1
ii  libkf5notifications5 5.49.0-1
ii  libkf5notifyconfig5  5.49.0-1
ii  libkf5parts5 5.49.0-1
ii  libkf5pimcommon5abi2 4:18.08.1-1
ii  libkf5pimcommonakonadi5abi1  4:18.08.1-1
ii  libkf5pimtextedit5abi2   18.08.1-1
ii  libkf5sendlater5 4:18.08.1-1
ii  libkf5service-bin5.49.0-1
ii  libkf5service5   5.49.0-1
ii  libkf5sonnetui5  5.49.0-1
ii  libkf5templateparser54:18.08.1-1
ii  libkf5textwidgets5   5.49.0-1
ii  libkf5tnef5  4:18.08.1-1
ii  libkf5wallet-bin 5.49.0-1
ii  libkf5wallet55.49.0-1
ii  libkf5webengineviewer5abi1   4:18.08.1-1
ii  libkf5widgetsaddons5 5.49.0-1
ii  libkf5windowsystem5  5.49.0-1
ii  libkf5xmlgui55.49.0-1
ii  libqgpgme7   1.11.1-2
ii  libqt5core5a 5.11.1+dfsg-9
ii  libqt5dbus5  5.11.1+dfsg-9
ii  libqt5gui5   5.11.1+dfsg-9
ii  libqt5network5   5.11.1+dfsg-9
ii  libqt5widgets5   5.11.1+dfsg-9
ii  libqt5xml5   5.11.1+dfsg-9
ii  libstdc++6   8.2.0-7

Versions of packages kmail recommends:
ii  accountwizard   4:18.08.1-1
ii  gnupg   2.2.10-3
pn  kdepim-addons   
ii  kdepim-themeeditors 4:18.08.1-1
pn  mbox-importer   
ii  pim-data-exporter   4:18.08.1-1
ii  pim-sieve-editor4:18.08.1-1
ii  pinentry-qt [pinentry-x11]  1.1.0-1+b1

Versions of packages kmail suggests:
pn  clamav 
pn  kaddressbook   
pn  kleopatra  
ii  procmail 

Bug#902657: Segfault is caused by libcap-ng0 0.7.9

[Stefan Fritsch]

retitle 902657 graceful/restart results in segfault if libcap-ng0 is loaded
severity 902657 important
block 902657 by 904808
thanks

The problem is caused by  libcap-ng0 0.7.9 . This is usually pulled in by php 
extensions. There is nothing apache can do.

Unfortunately, downgrading to 0.7.7 from stretch is not possible due to 
dependencies.

Bug#904808: libcap-ng0: libcap-ng's use of pthread_atfork causes segfaults

[Stefan Fritsch]

Package: libcap-ng0
Version: 0.7.9-1
Severity: grave
Justification: renders package unusable

Hi,

apache httpd loads and unloads modules during a reload of the server
configuration. This causes the pthread_atfork entry that is installed by
libcap-ng0 to point to code that is no longer in the process, causing a
segfault at the next fork.

See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902657

There is already an upstream bug report about this:

https://github.com/stevegrubb/libcap-ng/issues/5

Since there is no interface to undo a pthread_atfork() call, there is no
way a shared library can call pthread_atfork() in a safe way. libcap-ng0
should not do it.

Cheers,
Stefan

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

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

Versions of packages libcap-ng0 depends on:
ii  libc6  2.27-5

libcap-ng0 recommends no packages.

libcap-ng0 suggests no packages.

-- no debconf information

Bug#902658: apache2: apachectl graceful/restart results in segfault

[Stefan Fritsch]

On Tuesday, 17 July 2018 21:12:48 CEST gregor herrmann wrote:
> On Tue, 17 Jul 2018 20:54:02 +0200, Stefan Fritsch wrote:
> > Can one of you please check how libcap-ng is pulled into the process.
> > Something like this should do the trick (replace XXX with the pid of one
> > of
> > your apache processes, you need to be root to do this) :
> > 
> > pid=XXX; for i in $(awk '{ print $6 }' < /proc/$pid/maps|sort -u|grep /) ;
> > do readelf -d $i|grep libcap && echo $i ; done
> 
> # pid=6855; for i in $(awk '{ print $6 }' < /proc/$pid/maps|sort -u|grep /)
> ; do readelf -d $i|grep libcap && echo $i ; done readelf: Error:
> '/dev/zero' is not an ordinary file
>  0x0001 (NEEDED) Shared library: [libcap-ng.so.0]
> /lib/x86_64-linux-gnu/libaudit.so.1.0.0
>  0x000e (SONAME) Library soname: [libcap-ng.so.0]
> /lib/x86_64-linux-gnu/libcap-ng.so.0.0.0
> readelf: Error: '/SYSV645e': No such file
> readelf: Error: Not an ELF file - it has the wrong magic bytes at the start

Thanks, Gregor. Unfortunately, that is not helpful, yet. Please try again with 
ldd instead of readelf -d.

Bug#902658: apache2: apachectl graceful/restart results in segfault

[Stefan Fritsch]

On Friday, 29 June 2018 10:35:32 CEST mer.at wrote:
> when i do an "apachectl graceful" or "apachectl restart", i get
> segfaults.

I don't think this is a bug in apache, at least not directly.

> if i then do a /etc/init.d/apache2 restart, it works normally
> /etc/init.d/apache2 restart and systemctl restart apache2 do NOT result
> in a segfault.

> Stack trace of thread 20261:
> #0  0x7fa235131677 n/a (libcap-ng.so.0)

Can one of you please check how libcap-ng is pulled into the process. 
Something like this should do the trick (replace XXX with the pid of one of 
your apache processes, you need to be root to do this) :

pid=XXX; for i in $(awk '{ print $6 }' < /proc/$pid/maps|sort -u|grep /) ; do 
readelf -d $i|grep libcap && echo $i ; done

It's not pulled in by mod_fcgid.

Maybe there is a desctructor in libcap-ng that causes the segfault while 
libcap-ng is unloaded during graceful restart. Then it could be possible that 
it crashes or not depending on the load order or exact list of modules.

Bug#903721: apache2-bin: Missing mod_md.so in apache2-bin

[Stefan Fritsch]

On Friday, 13 July 2018 19:33:24 CEST marcelo wrote:
> The mod_md not works in the last version in apache, i understood the mod_md
> now is part of apache, but the mod_md not work, because missing archives,
> for example the archive mod_md.so, i believe the solution is the same apply
> in libapache2-mod-proxy-uwsgi : #894785

Seems to be there:

$ dpkg -s apache2-bin|grep -i version
Version: 2.4.33-3+b1
$ dpkg -L apache2-bin|grep mod_md
/usr/lib/apache2/modules/mod_md.so
$ ls -l /usr/lib/apache2/modules/mod_md.so
-rw-r--r-- 1 root root 219472 Mai 28 19:29 /usr/lib/apache2/modules/mod_md.so

How do you determine that it is missing?

Bug#903958: Apache processes limited to 1000

[Stefan Fritsch]

On Tuesday, 17 July 2018 09:50:08 CEST Thomas Mühlberg wrote:
> Package: apache2 apache2-bin apache2-data apache2-utils
> Version: 2.4.25-3+deb9u5
> 
> After upgrade from version 2.4.25-3+deb9u4 to 2.4.25-3+deb9u5 the Apache
> processes are limited to 1000.
> After rollback to version 2.4.25-3+deb9u4 everything works fine again.
> The configuration will be ignored.
> /etc/apache2/mods-available/mpm_prefork.conf
> 
> 
>   StartServers 10
>   MinSpareServers 10
>   MaxSpareServers 20
>   MaxRequestWorkers 4000
>   ServerLimit 4000
>   MaxConnectionsPerChild 0
> 

That's very weird since nothing outside of http2 has changed. How do you 
determine that the connections are limited to 1000? Are there interesting 
messages in the error log? Are you sure it's not a problem with the client 
(e.g. ulimit -n).

Bug#894713: stretch-pu: apache2/2.4.25-3+deb9u5

[Stefan Fritsch]

On Sunday, 24 June 2018 19:00:22 CEST Adam D. Barratt wrote:
> On Sat, 2018-06-02 at 10:29 +0200, Stefan Fritsch wrote:
> > +apache2 (2.4.25-3+deb9u5) stretch; urgency=medium
> > +
> > +  * This package upgrades mod_http2 to the version from apache2
> > 2.4.33. This
> > +fixes a lot of bugs and some security issues, but it also
> > removes the
> > +support for using HTTP/2 when running with mpm_prefork. HTTP/2
> > support
> > +is only provided when running with mpm_event or mpm_worker.
> > +
> > + -- Stefan Fritsch   Sat, 02 Jun 2018 09:51:46 +0200
> 
> Do we have any idea how common such a configuration is? (Or, indeed,
> how common the use of HTTP/2 with stretch's apache is.)

Unfortunately not. I guess there are still a fair number of mpm_prefork users 
because of mod_php. But I don't know how many enable mod_http2 (it's not 
enabled by default). But I expect that there are extremely few users who 
actually depend on HTTP/2 working. For the vast majority, it's only a nice to 
have feature.

Cheers,
Stefan

Bug#900612: apache2-suexec-pristine: Packaging steps undo setting of setuid bit

[Stefan Fritsch]

On Saturday, 2 June 2018 02:06:10 CEST Jason Perrin wrote:

> This appears to be a problem in the source for this package, on the master
> branch, as well as on separate branches for different distros:
> https://salsa.debian.org/apache-team/apache2/blob/master/debian/rules#L148-1
> 53 I'm not sure how this has worked properly to produce packages, since the
> last change to that section was 6 years ago, so I'm a bit confused on that
> point.


That's weird because it seems all distributed packages in the last 6 years 
have the correct permissions. Do you build the package as root? Usually 
packages are built as non-root user using fakeroot. Maybe fakeroot is not 
being faithful to the real kernel behavior and hides the bug.

Cheers,
Stefan

Bug#894713: stretch-pu: apache2/2.4.25-3+deb9u5

[Stefan Fritsch]

On Sunday, 20 May 2018 18:32:55 CEST Stefan Fritsch wrote:
> As I don't see any other way to fix the open issues, I would still like to
> go ahead. But I will prepare a new package/diff with a NEWS.Debian entry
> that informs about this change.

The new debdiff is attached. the NEWS part is also below.

Cheers,
Stefan

--- apache2-2.4.25/debian/apache2.NEWS  2018-03-30 17:07:14.0 +0200
+++ apache2-2.4.25/debian/apache2.NEWS  2018-06-02 10:01:13.0 +0200
@@ -1,3 +1,12 @@
+apache2 (2.4.25-3+deb9u5) stretch; urgency=medium
+
+  * This package upgrades mod_http2 to the version from apache2 2.4.33. This
+fixes a lot of bugs and some security issues, but it also removes the
+support for using HTTP/2 when running with mpm_prefork. HTTP/2 support
+is only provided when running with mpm_event or mpm_worker.
+
+ -- Stefan Fritsch   Sat, 02 Jun 2018 09:51:46 +0200
diff -Nru apache2-2.4.25/debian/apache2.apache-htcacheclean.init apache2-2.4.25/debian/apache2.apache-htcacheclean.init
--- apache2-2.4.25/debian/apache2.apache-htcacheclean.init	2018-03-31 10:45:18.0 +0200
+++ apache2-2.4.25/debian/apache2.apache-htcacheclean.init	2018-05-13 18:52:55.0 +0200
@@ -30,6 +30,13 @@
 HTCACHECLEAN_PATH="${HTCACHECLEAN_PATH:=/var/cache/apache2$DIR_SUFFIX/mod_cache_disk}"
 HTCACHECLEAN_OPTIONS="${HTCACHECLEAN_OPTIONS:=-n}"
 
+# Read configuration variable file if it is present
+if [ -f /etc/default/apache-htcacheclean$DIR_SUFFIX ] ; then
+   . /etc/default/apache-htcacheclean$DIR_SUFFIX
+elif [ -f /etc/default/apache-htcacheclean ] ; then
+   . /etc/default/apache-htcacheclean
+fi
+
 PIDDIR="/var/run/apache2/$RUN_USER"
 PIDFILE="$PIDDIR/$NAME.pid"
 DAEMON_ARGS="$HTCACHECLEAN_OPTIONS \
diff -Nru apache2-2.4.25/debian/apache2.NEWS apache2-2.4.25/debian/apache2.NEWS
--- apache2-2.4.25/debian/apache2.NEWS	2018-03-30 17:07:14.0 +0200
+++ apache2-2.4.25/debian/apache2.NEWS	2018-06-02 10:01:13.0 +0200
@@ -1,3 +1,12 @@
+apache2 (2.4.25-3+deb9u5) stretch; urgency=medium
+
+  * This package upgrades mod_http2 to the version from apache2 2.4.33. This
+fixes a lot of bugs and some security issues, but it also removes the
+support for using HTTP/2 when running with mpm_prefork. HTTP/2 support
+is only provided when running with mpm_event or mpm_worker.
+
+ -- Stefan Fritsch   Sat, 02 Jun 2018 09:51:46 +0200
+
 apache2 (2.4.10-2) unstable; urgency=low
 
   The default period for which rotated log files are kept has been
diff -Nru apache2-2.4.25/debian/changelog apache2-2.4.25/debian/changelog
--- apache2-2.4.25/debian/changelog	2018-03-31 10:47:16.0 +0200
+++ apache2-2.4.25/debian/changelog	2018-06-02 10:01:13.0 +0200
@@ -1,3 +1,20 @@
+apache2 (2.4.25-3+deb9u5) stretch; urgency=medium
+
+  * Upgrade mod_http and mod_proxy_http2 to the versions from 2.4.33. This
+fixes
+- CVE-2018-1302: mod_http2: Potential crash w/ mod_http2
+- Segfaults in mod_http2 (Closes: #873945)
+- mod_http2 issue with option "Indexes" and directive "HeaderName"
+  (Closes: #850947)
+Unfortunately, this also removes support for http2 when running on
+mpm_prefork.
+  * mod_http2: Avoid high memory usage with large files, causing crashes on
+32bit archs. Closes: #897218
+  * Make the apache-htcacheclean init script actually look into
+    /etc/default/apache-htcacheclean for its config. Closes: #898563
+
+ -- Stefan Fritsch   Sat, 02 Jun 2018 10:01:13 +0200
+
 apache2 (2.4.25-3+deb9u4) stretch-security; urgency=medium
 
   * CVE-2017-15710: mod_authnz_ldap: Out of bound write in mod_authnz_ldap
diff -Nru apache2-2.4.25/debian/patches/CVE-2017-7659.diff apache2-2.4.25/debian/patches/CVE-2017-7659.diff
--- apache2-2.4.25/debian/patches/CVE-2017-7659.diff	2018-03-31 10:45:18.0 +0200
+++ apache2-2.4.25/debian/patches/CVE-2017-7659.diff	1970-01-01 01:00:00.0 +0100
@@ -1,33 +0,0 @@
-#commit 672187c168b94b562d8065e08e2cad5b00cdd0e3
-#Author: Stefan Eissing 
-#Date:   Wed Feb 1 20:40:38 2017 +
-#
-#On the trunk:
-#
-#mod_http2: fix for crash when running out of memory. Initial patch by Robert Swiecki 
-#
-#
-#
-#git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1781304 13f79535-47bb-0310-9956-ffa450edef68
-#
 apache2.orig/modules/http2/h2_stream.c
-+++ apache2/modules/http2/h2_stream.c
-@@ -286,11 +286,13 @@ apr_status_t h2_stream_set_request_rec(h
- return APR_ECONNRESET;
- }
- status = h2_request_rcreate(, stream->pool, r);
--ap_log_rerror(APLOG_MARK, APLOG_DEBUG, status, r, APLOGNO(03058)
--  "h2_request(%d): set_request_rec %s host=%s://%s%s",
--  stream->id, req->method, req->scheme, req->authority, 
--  req->path);
--stream->rtmp = req;
-+if (status == APR_SUCCESS) {
-+ap_log_rerror(APLOG_MARK, APLOG_

Bug#898304: Please Depend on libcurl3 | libcurl4

[Stefan Fritsch]

On Thursday, 10 May 2018 00:21:44 CEST 積丹尼 Dan Jacobson wrote:
> Package: apache2-bin
> Version: 2.4.33-3
> 
> Please Depend on libcurl3 | libcurl4,
> else we cannot upgrade our system.

The dependency is generated automatically depending on which version of 
libcurl is used during compilation. And libcurl4 is not in unstable. I don't 
think there is anything I can do.

Bug#894713: stretch-pu: apache2/2.4.25-3+deb9u5

[Stefan Fritsch]

Hi,

On Sunday, 13 May 2018 19:15:22 CEST Stefan Fritsch wrote:
> On Tuesday, 3 April 2018 14:07:33 CEST Stefan Fritsch wrote:
> > I would like to do an upgrade of apache2 in stretch that upgrades the
> > complete mod_http2 and mod_proxy_http2 modules from the versions from
> > 2.4.25 to the versions from 2.4.33.
> > 
> > The reason is that the fix for CVE-2018-1302 [1] is difficult to
> > backport because it concerns a complex life-time issue of data
> > structures, the relevant code has changed greatly between 2.4.25 and
> > 2.4.33, and I am not familiar with the internals of mod_http2.  There
> > are other random segfaults [2] and other bugs [3] in stretch's mod_http2
> > that are reportedly fixed by newer mod_http2. Therefore, upgrading the
> > whole thing seems like the best solution to me. Do you agree with this
> > approach?
> 
> I have now prepared updated packages. The changelog diff is:


There is one complication: It turns out that in newer versions of apache2, 
mod_http2 does no longer support being used with mpm_prefork but only with 
mpm_worker and mpm_event. If loaded together with mpm_prefork, mod_http2 will 
log a message and refuse to serve HTTP/2, but HTTP/1.x continues to work.

As I don't see any other way to fix the open issues, I would still like to go 
ahead. But I will prepare a new package/diff with a NEWS.Debian entry that 
informs about this change.

Cheers,
Stefan

Bug#894713: stretch-pu: apache2/2.4.25-3+deb9u5

[Stefan Fritsch]

Hi,

On Tuesday, 3 April 2018 14:07:33 CEST Stefan Fritsch wrote:
> I would like to do an upgrade of apache2 in stretch that upgrades the
> complete mod_http2 and mod_proxy_http2 modules from the versions from
> 2.4.25 to the versions from 2.4.33.
> 
> The reason is that the fix for CVE-2018-1302 [1] is difficult to
> backport because it concerns a complex life-time issue of data
> structures, the relevant code has changed greatly between 2.4.25 and
> 2.4.33, and I am not familiar with the internals of mod_http2.  There
> are other random segfaults [2] and other bugs [3] in stretch's mod_http2
> that are reportedly fixed by newer mod_http2. Therefore, upgrading the
> whole thing seems like the best solution to me. Do you agree with this
> approach?

I have now prepared updated packages. The changelog diff is:

apache2 (2.4.25-3+deb9u5) stretch; urgency=medium

  * Upgrade mod_http and mod_proxy_http2 to the versions from 2.4.33. This
fixes
- CVE-2018-1302: mod_http2: Potential crash w/ mod_http2
- Segfaults in mod_http2 (Closes: #873945)
- mod_http2 issue with option "Indexes" and directive "HeaderName"
  (Closes: #850947)
  * mod_http2: Avoid high memory usage with large files, causing crashes on
32bit archs. Closes: #897218
  * Make the apache-htcacheclean init script actually look into
/etc/default/apache-htcacheclean for its config. Closes: #898563

 -- Stefan Fritsch <s...@debian.org>  Sun, 13 May 2018 17:43:20 +0200

A partial debdiff without the mod_http2-upgrade-to-2.4.33.diff file is 
attached. The full debdiff is available at [1] (probably too large for mailing 
lists). The diffstat of the  mod_http2-upgrade-to-2.4.33.diff file is included 
below [2].

Cheers,
Stefan

[1] https://www.sfritsch.de/~stf/apache2_2.4.25-3+deb9u5~test1/
apache2_2.4.25-3+deb9u5.debdiff 

[2]
 configure|2 
 modules/http2/NWGNUmod_http2 |2 
 modules/http2/config2.m4 |   23 
 modules/http2/h2.h   |   46 -
 modules/http2/h2_alt_svc.c   |   13 
 modules/http2/h2_alt_svc.h   |   13 
 modules/http2/h2_bucket_beam.c   |  892 --
 modules/http2/h2_bucket_beam.h   |  147 ++-
 modules/http2/h2_bucket_eoc.c|  110 --
 modules/http2/h2_bucket_eoc.h|   32 
 modules/http2/h2_bucket_eos.c|   18 
 modules/http2/h2_bucket_eos.h|   13 
 modules/http2/h2_config.c|   38 
 modules/http2/h2_config.h|   15 
 modules/http2/h2_conn.c  |  156 ++-
 modules/http2/h2_conn.h  |   16 
 modules/http2/h2_conn_io.c   |  138 +--
 modules/http2/h2_conn_io.h   |   27 
 modules/http2/h2_ctx.c   |   15 
 modules/http2/h2_ctx.h   |   13 
 modules/http2/h2_filter.c|  165 ++--
 modules/http2/h2_filter.h|   26 
 modules/http2/h2_from_h1.c   |   54 -
 modules/http2/h2_from_h1.h   |   13 
 modules/http2/h2_h2.c|   25 
 modules/http2/h2_h2.h|   13 
 modules/http2/h2_headers.c   |   31 
 modules/http2/h2_headers.h   |   19 
 modules/http2/h2_mplx.c  | 1551 
+--
 modules/http2/h2_mplx.h  |   84 --
 modules/http2/h2_ngn_shed.c  |   30 
 modules/http2/h2_ngn_shed.h  |   13 
 modules/http2/h2_private.h   |   13 
 modules/http2/h2_proxy_session.c |   94 +-
 modules/http2/h2_proxy_session.h |   23 
 modules/http2/h2_proxy_util.c|  296 +++
 modules/http2/h2_proxy_util.h|   64 +
 modules/http2/h2_push.c  |   20 
 modules/http2/h2_push.h  |   14 
 modules/http2/h2_request.c   |   34 
 modules/http2/h2_request.h   |   13 
 modules/http2/h2_session.c   | 1432 +---
 modules/http2/h2_session.h   |   76 -
 modules/http2/h2_stream.c| 1208 ++
 modules/http2/h2_stream.h|  179 ++--
 modules/http2/h2_switch.c|   29 
 modules/http2/h2_switch.h|   13 
 modules/http2/h2_task.c  |  250 +++---
 modules/http2/h2_task.h  |   26 
 modules/http2/h2_util.c  | 1017 -
 modules/http2/h2_util.h  |  188 
 modules/http2/h2_version.h   |   33 
 modules/http2/h2_worker.c|  103 --
 modules/http2/h2_worker.h|  135 ---
 modules/http2/h2_workers.c   |  587 ++
 modules/http2/h2_workers.h   |   82 --
 modules/http2/mod_http2.c|   37 
 modules/http2/mod_http2.dep  |  118 --
 modules/http2/mod_http2.dsp  |8 
 modules/http2/mod_http2.h|   13 
 modules/http2/mod_http2.mak  |   18 
 modules/http2/mod_proxy_http2.c  |  208 ++---
 modules/http2/mod_proxy_http2.h  |   13 
 63 files changed, 5534 insertions(+), 4563 deletions(-)


diff -Nru apache2-2.4.25/debian/apache2.apache-htcacheclean.init apache2-2.4.25/debian/apache2.apache-htcacheclean.init
--- apache2-2.4.25/debian/apache2.apache-htc

Bug#884562: Enable CONFIG_SND_SOC_SPDIF for cubietruck spdif

[Stefan Fritsch]

found 884562 4.16.5-1
thanks

Hi,

is there a reason why this has not been enabled or has it just slipped 
through?

Cheers,
Stefan

Bug#898563: apache2: htcacheclean init script does not read /etc/default/apache-htcacheclean

[Stefan Fritsch]

Package: apache2
Version: 2.4.25-3+deb9u4
Severity: normal

While /etc/init.d/apache-htcacheclean contains this comment

# Default values. Edit /etc/default/apache-htcacheclean$DIR_SUFFIX to
# change these

it does not actually read that file. This has been fixed in sid in
2.4.27-4 .

Bug#881725: apache2: reload fails inside (libvirt) lxc container

[Stefan Fritsch]

On Monday, 16 April 2018 21:51:36 CEST Stefan Fritsch wrote:
> So tmpreaper should exclude systemd-private-* files by default. Moritz, do
> you also have some cron job cleaning up stale files in /tmp ?

tmpreaper needs to exclude dirs inside the  systemd-private-* dir, too (there 
is a tmp dir inside). There does not seem to be a recursive mode and

TMPREAPER_PROTECT_EXTRA='/tmp/systemd-private*'

did not help. Probably something like

TMPREAPER_PROTECT_EXTRA='/tmp/systemd-private*/*'

should work better.

Bug#895237: apache2: apachectl does not use systemd for restarts

[Stefan Fritsch]

On Sunday, 15 April 2018 21:50:57 CEST Jan Heitkötter wrote:
> The hooks in Let’s Encrypt’s conffile say “apachectl -k”; the manpage
> does not explain this option. Omitting -k makes things work:

options unknown to apachectl are passed to apache2 and apache2 -k start tells 
apache2 to do a normal start and go into the background. But this means that 
the systemd magic that apachectl does for "apachectl start" is not done for 
"apachectl -k start".

Not sure how to fix this. In general, it is not possible to map all options to 
systemd actions. For example, one could do

apachectl -DSOME_CONFIG_DEFINE -k start

to start apache with some special config options. Even worse, "-k start" is 
the default if no other action option (like -k, -t, -l, -L, ...) is given.

Bug#881725: apache2: reload fails inside (libvirt) lxc container

[Stefan Fritsch]

On Monday, 16 April 2018 20:34:00 CEST Matthew Gabeler-Lee wrote:
> On Sat, 14 Apr 2018, Stefan Fritsch wrote:
> > This seems to be a systemd bug. Changing PrivateTmp from true to false in
> > apache2.service fixes the issue. But even with PrivateTmp it works for
> > some time. It would be interesting what is the trigger to make it fail
> > later on.
> 
> Hmm ... I was having a problem on some systems where tmpreaper, in its
> default configuration, will eventually delete all the directories
> systemd creates to support PrivateTmp, which might explain this...

That seems a likely explanation. I have tmpreaper installed, too. The default 
keep time is 7 days, which explains why the issue does not appear immediately.

So tmpreaper should exclude systemd-private-* files by default. Moritz, do you 
also have some cron job cleaning up stale files in /tmp ?

Bug#895237: apache2: apachectl does not use systemd for restarts

[Stefan Fritsch]

On Thursday, 12 April 2018 11:56:04 CEST Axel Beckert wrote:
> Jan Heitkötter wrote:
> > Default behaviour is do stop/start Apache using apachectl which fails in
> > installations running systemd. Apache will stop, but not start again.

Using apachectl stop / start / restart works fine for me with systemd. The 
issue is somewhere else.

To debug this, error output would be useful. Like what happens when you try to 
start apache again? what does systemctl status apache2.service say afterwards? 
Is there anything in the apache error log? Maybe change apache2ctl to do "set 
-x" at the beginning and show the output.


Harlan Lieberman-Berg wrote:
> Hm, looks like this is actually a bug over in apache-land.  We do the right
> thing for `apachectl start` in terms of wrapping to use systemd, but we
> don't do that during `apachectl restart`.

This is correct behavior: apachectl restart is different from stop+start. 
"apachectl restart" only restarts the child processes, the parent process 
keeps running.
This is different from what init scripts do for "restart", but nobody claims 
that apachectl works the same as init scripts.

But I wonder why certbot needs to do stop+start? Would an "apachectl graceful" 
not be the better option?

> Apache folx, can we potentially just turn restart into a shim that calls
> `apachectl stop` and `apachectl start`?  That will solve the problem with
> the least amount of fuss.

Bug#881725: apache2: reload fails inside (libvirt) lxc container

[Stefan Fritsch]

On Fri, 9 Mar 2018, Moritz Muehlenhoff wrote:

> On Tue, Nov 14, 2017 at 02:46:00PM +, Matthew Gabeler-Lee wrote:
> > Package: apache2
> > Version: 2.4.25-3+deb9u3
> > Severity: normal
> > 
> > When running inside a libvirt-managed lxc os container, the reload command
> > on the systemd unit fails always:
> > 
> > Nov 14 14:38:33 hostname systemd[1]: Reloading The Apache HTTP Server.
> > Nov 14 14:38:33 hostname systemd[11798]: apache2.service: Failed at step 
> > NAMESPACE spawning /usr/sbin/apachectl: No such file or directory
> > Nov 14 14:38:33 hostname systemd[1]: apache2.service: Control process 
> > exited, code=exited status=226
> > Nov 14 14:38:33 hostname systemd[1]: Reload failed for The Apache HTTP 
> > Server.
> > 
> > Restart works normally.
> > 
> > This mostly crops up for me via the logrotate script.
> 
> JFTR, this isn't limited to LXC containers, we've also seen that on baremetal
> stretch installations at the Wikimedia Foundation. Our internal task is
> at https://phabricator.wikimedia.org/T185195, I'll update this bug when/if we
> have additional information.

This seems to be a systemd bug. Changing PrivateTmp from true to false in 
apache2.service fixes the issue. But even with PrivateTmp it works for 
some time. It would be interesting what is the trigger to make it fail 
later on.

Bug#894827: apache2: Apache workers are hanging after reload

[Stefan Fritsch]

Hi Dan,

On Wed, 4 Apr 2018, Dan Benton wrote:

> Package: apache2
> Version: 2.4.10-10+deb8u12
> Severity: normal

Is this a new issue with version 2.4.10-10+deb8u12 (from the security 
update a few days ago) or have you also observed it with the previous 
version 2.4.10-10+deb8u11?

Cheers,
Stefan

> Dear Maintainer,
> 
> I am finding some Apache processes stuck in a gracefully finishing state 
> after an Apache reload. The only way to clear these processes down is to 
> restart Apache or killing the individual processes. The way these 
> processes are being left the stuck thread 100% CPU and eventually 
> crashing the server. I have seen these hung processes stay running for 
> over 12 hours before I manually kill them.
> 
> This seems to only be when the reload catches a large request to my 
> website. Unfortunately I have been unsuccessful to replicate this issue 
> anywhere outside of my production environment.

Bug#894713: stretch-pu: Pre-approval of package apache2/2.4.25-3+deb9u5

[Stefan Fritsch]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi,

I would like to do an upgrade of apache2 in stretch that upgrades the
complete mod_http2 and mod_proxy_http2 modules from the versions from
2.4.25 to the versions from 2.4.33.

The reason is that the fix for CVE-2018-1302 [1] is difficult to
backport because it concerns a complex life-time issue of data
structures, the relevant code has changed greatly between 2.4.25 and
2.4.33, and I am not familiar with the internals of mod_http2.  There
are other random segfaults [2] and other bugs [3] in stretch's mod_http2
that are reportedly fixed by newer mod_http2. Therefore, upgrading the
whole thing seems like the best solution to me. Do you agree with this
approach?

The diff is not reviewable (58 files changed, 5533 insertions, 4182
deletions), but it only touches the http2 modules.

I may also include a few other small bug fixes.  I will prepare the
updated package and send the detailed information after the pending DSA
for some other issues has been released (2.4.25-3+deb9u4).

Cheers,
Stefan

[1] http://httpd.apache.org/security/vulnerabilities_24.html#CVE-2018-1302
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873945
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850947

Bug#889170: apr-util: build failure with new gdbm

[Stefan Fritsch]

On Friday, 2 February 2018 23:32:35 CET Gianfranco Costamagna wrote:
> Hello, before uploading new gdbm in unstable, I tested all the
> reverse-dependencies, except for the packages that were already broken/not
> building.
> 
> This sounds to be the case for this one, and now I don't know how to debug
> this package.

It seems apr-util assumed that gdbm would always reset gdbm_errno if there has 
not been an error and the new gdbm version does not do that any more.

I have fixed that upstream in apr-util:
https://svn.apache.org/viewvc?view=revision=1825312

Bug#881725: apache2: reload fails inside (libvirt) lxc container

[Stefan Fritsch]

Hi Matthew,

I don't know libvirt lxc containers at all, but ...

On Tue, 14 Nov 2017, Matthew Gabeler-Lee wrote:
> Nov 14 14:38:33 hostname systemd[1]: Reloading The Apache HTTP Server.
> Nov 14 14:38:33 hostname systemd[11798]: apache2.service: Failed at step 
> NAMESPACE spawning /usr/sbin/apachectl: No such file or directory

this seems to say that /usr/sbin/apachectl is missing in your container. I 
guess this is a configuration problem in your container config. I don't 
think there is anything that can be done from the apache side.

Cheers,
Stefan

Bug#884562: linux-image-4.9.0-4-armmp-lp: Enable CONFIG_SND_SOC_SPDIF for cubietruck spdif

[Stefan Fritsch]

package: src:linux
version: 4.9.65-3
severity: important

This is a follow-up to #857410 . CONFIG_SND_SOC_SPDIF is also required to make 
spdif work on the cubietruck.

By accident I have not stopped using my self-compiled kernel and did not 
notice that spdif does not actually work with the debian kernel. Sorry.

Cheers,
Stefan

Bug#877715: apache2: apache won't start after reboot when listening on IPv6 address

[Stefan Fritsch]

On Wednesday, 4 October 2017 20:41:38 CEST Tiger!P wrote:
> I tried to add a file /etc/systemd/system/apache2.service.d/after.conf
> with the following content:
> 8<
> [Unit]
> Wants=network-online.target
> After=network.target remote-fs.target nss-lookup.target
> network-online.target
> 8<

Can you check if

systemctl enable ifupdown-wait-online.service

helps? If not, what is the output of 

systemctl status ifupdown-wait-online.service

If it helps, I wonder why network-online.target in Wants is not sufficient.