from:"Ondřej Surý"

Bug#1021771: apache2: Accessing to type-map without .var suffix results 500 and apache2 exits

2022-10-14 Thread Ondřej Surý

> On 14. 10. 2022, at 13:13, Shintaro Sakahara  wrote:
> 
> I created a small example using Docker and put on GitHub so that everyone 
> could
> easily reproduce this problem.

Hi,

could you please actually describe the problem into the bugreport?  While having
a reproducer is certainly nice, it's not enough to see what might be the 
problem.
And you can't expect other people do debug the Docker containers.

Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org

Bug#988029: apache2: Non-unique IDs being generated by mod_unique_id - Fix available

2021-05-03 Thread Ondřej Surý

The patch is wrong. It only adds thread local data and does absolutely nothing 
to prevent id collisions.

It should not be merged here and also should not be merged upstream, but it’s 
beyond my capacity to send the feedback there.

You need something like:

- generate random nonce for each thread, then use https://prng.di.unimi.it/

Ondrej
--
Ondřej Surý  (He/Him)

> On 3. 5. 2021, at 23:33, Atle Solbakken  wrote:
> Package: apache2
> Version: 2.4.38-3+deb10u4
> Severity: normal
> Tags: patch
> 
> Hi
> 
> The current version has a race condition in mod_unique_id causing non-unique 
> IDs to be
> generated (multiple threads are using a counter without any mutex).
> 
> I've encountered the issue in a production situation myself.
> 
> There issue has been fixed upstream.
> 
> https://svn.apache.org/viewvc?view=revision=1887244
> https://svn.apache.org/viewvc?view=revision=1887245
> 
> I've tried to compile the patch on top of the current stable version 2.0.38 
> which seems
> to work. Upstream, the patch is only available from 2.0.47 and it's currently 
> in experimental.
> 
> Maybe it can be applied to 2.0.38 aswell.
> 
> Best regards
> Atle Solbakken
> 
> -- Package-specific info:
> 
> -- System Information:
> Debian Release: 10.9
>  APT prefers stable-updates
>  APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-13-amd64 (SMP w/1 CPU core)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: 
> LC_ALL set to en_US.UTF-8)
> 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.38-3+deb10u4
> ii  apache2-data   2.4.38-3+deb10u4
> ii  apache2-utils  2.4.38-3+deb10u4
> ii  dpkg   1.19.7
> ii  lsb-base   10.2019051400
> ii  mime-support   3.62
> ii  perl   5.28.1-6+deb10u1
> ii  procps 2:3.3.15-2
> 
> Versions of packages apache2 recommends:
> ii  ssl-cert  1.0.39
> 
> Versions of packages apache2 suggests:
> pn  apache2-doc  
> pn  apache2-suexec-pristine | apache2-suexec-custom  
> pn  www-browser  
> 
> Versions of packages apache2-bin depends on:
> ii  libapr1  1.6.5-1+b1
> ii  libaprutil1  1.6.1-4
> ii  libaprutil1-dbd-sqlite3  1.6.1-4
> ii  libaprutil1-ldap 1.6.1-4
> ii  libbrotli1   1.0.7-2+deb10u1
> ii  libc62.28-10
> ii  libcurl4 7.64.0-4+deb10u2
> ii  libjansson4  2.12-1
> ii  libldap-2.4-22.4.47+dfsg-3+deb10u6
> ii  liblua5.2-0  5.2.4-1.1+b2
> ii  libnghttp2-141.36.0-2+deb10u1
> ii  libpcre3 2:8.39-12
> ii  libssl1.11.1.1d-0+deb10u6
> ii  libxml2  2.9.4+dfsg1-7+deb10u1
> ii  perl 5.28.1-6+deb10u1
> ii  zlib1g   1:1.2.11.dfsg-1
> 
> Versions of packages apache2-bin suggests:
> pn  apache2-doc  
> pn  apache2-suexec-pristine | apache2-suexec-custom  
> pn  www-browser  
> 
> Versions of packages apache2 is related to:
> ii  apache2  2.4.38-3+deb10u4
> ii  apache2-bin  2.4.38-3+deb10u4
> 
> -- no debconf information

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

2020-12-26 Thread Ondřej Surý

I believe it’s a reasonable assumption that the kernel matches the Debian 
release. If anybody is running with old kernel or disables getrandom I would 
say they are on their own - also other stuff will break, not only apache2.

Ondrej
--
Ondřej Surý  (He/Him)

> On 27. 12. 2020, at 0:24, Stefan Fritsch  wrote:
> 
> 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
>>  
>> <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.
>

Problems with lbmethod_* modules requiring symbols from proxy

2018-07-25 Thread Ondřej Surý

Hi,

while updating apache2 to 2.4.34, I found out (or rather users found out) that 
lbmethod_bybusyness
module now require symbols from mod_proxy.

Unfortunately, because the modules are loaded in alphabetical order, this 
breaks module loading,
and apache2 ends up with error loading lbmethod_bybusyness due to missing 
symbol.

The possible solutions:

1. Statically compile mod_proxy in -> I was unsuccessful, because moving 
‘proxy’ to static makes
*all* proxy modules including lbmethod_* modules to be compiled statically.  
DOESN’T WORK

2. Moving proxy symlink before lbmethod_* or lbmethod_* symlinks after proxy 
module.  That works
if done manually, but a2enmod and a2query doesn’t have support for priorities.  
Adding such support
would require a substantial work in *perl* - because it must not break existing 
deployments.
I think that in theory, this could be driven by “Depends” field, starting say 
at “20-“ prefix and increasing
the number by 10 on each “Depends:” iteration.  Unfortunately, I don’t have the 
time nor the perl-foo
to do that.

Anyway, I just wanted to warn the other maintainers before the 2.4.34 upload.

Ondrej
--
Ondřej Surý
ond...@isc.org

Re: Bug#877341: libapache2-mod-md: Doesn't seem to work at all: "AH02572: Failed to configure at least one certificate and key" (seems to require a patched version of mod_ssl / apache2)

2017-09-30 Thread Ondřej Surý

Control: clone 877341 -1
Control: reassign -1 src:apache2
Control: retitle -1 apache2: please include mod_md patch in apache2
Control: severity -1 normal
Control: block 877341 by -1

Hi Axel,

you are right and I intended to fill an bug on apache2 to get the patch
included. But I didn't get to it yet. So here we are...

Apache2 maintainers, could you please include:

https://raw.githubusercontent.com/icing/mod_md/v0.9.7/patches/mod_ssl_md-2.4.x-v5.diff

My apache2 ppa has to patch for quite some time and there was no bug report
related to it, so it should be very safe to include (I also checked with
upstream maintainer whether it has any downside, and according to him, it
does not).

Cheers,
Ondrej

On Sat, 30 Sep 2017 at 10:30 Axel Beckert <a...@debian.org> wrote:

Package: libapache2-mod-md
Version: 0.9.0-1
Severity: grave

Dear Ondřej,

I've installed libapache2-mod-md on a machine (Raspberry Pi) running
Debian Unstable where apache2 was already installed.

I've disabled all previous site configurations and wrote a new site
configuration from scratch and only enabled that site:

---8<---
ServerAdmin a...@deuxchevaux.org
ServerName ….deuxchevaux.org
ManagedDomain ….deuxchevaux.org

# Requires libapache2-mod-md ≥ 0.9.4
#MDRequireHttps temporary

DocumentRoot /var/www/html

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined


Protocols h2 h2c http/1.1




Protocols h2 http/1.1

SSLEngine on


--->8---

"apache2ctl configtest" said that everything is fine: "Syntax OK".

Upon "service apache2 restart" I though got the following lines in the
error.log:

---8<---
[Sat Sep 30 18:39:45.407137 2017] [ssl:emerg] [pid 4976:tid 1995292672]
AH02572: Failed to configure at least one certificate and key for ….
deuxchevaux.org:443
[Sat Sep 30 18:39:45.407356 2017] [ssl:emerg] [pid 4976:tid 1995292672] SSL
Library Error: error:02001002:system library:fopen:No such file or
directory (fopen('/etc/apache2/md/domains/….deuxchevaux.org/privkey.pem
','r'))
[Sat Sep 30 18:39:45.407449 2017] [ssl:emerg] [pid 4976:tid 1995292672] SSL
Library Error: error:2006D080:BIO routines:BIO_new_file:no such file
[Sat Sep 30 18:39:45.407621 2017] [ssl:emerg] [pid 4976:tid 1995292672] SSL
Library Error: error:140A80B1:SSL routines:SSL_CTX_check_private_key:no
certificate assigned
[Sat Sep 30 18:39:45.407675 2017] [ssl:emerg] [pid 4976:tid 1995292672]
AH02312: Fatal error initialising mod_ssl, exiting.
AH00016: Configuration Failed
--->8---

According to https://github.com/icing/mod_md/wiki/2.4.x-Installation,
this module needs either Apache 2.5/2.6 (not yet in Debian) or a patched
Apache 2.4, otherwise I'd get the AH02572 error message and an SSL
Library Error. Which I got, see above.

So I checked apache2's changelog.Debian.gz for inclusion of such a patch
but found none. I also checked https://bugs.debian.org/src:apache2 for
an according request to include such a patch, but haven't found any
either.

So I assume that libapache2-mod-md is currently not usable at all with
plain Debian unstable.

-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500,
'buildd-unstable'), (500, 'stable'), (1, 'experimental-debug'), (1,
'buildd-experimental'), (1, 'experimental')
Architecture: armhf (armv7l)

Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C:en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libapache2-mod-md depends on:
ii apache2-bin [apache2-api-20120211] 2.4.27-6
ii libapr1 1.6.2-1
ii libaprutil1 1.6.0-2
ii libc6 2.24-17
ii libcurl3-gnutls 7.55.1-1
ii libjansson4 2.10-1
ii libssl1.1 1.1.0f-5

libapache2-mod-md recommends no packages.

libapache2-mod-md suggests no packages.

-- no debconf information
-- 
Ondřej Surý <ond...@sury.org>

Re: Bug#852776: mariadb-server-10.1: init script doesn't specify it should be started prior to apache2 etc

2017-03-28 Thread Ondřej Surý

Hi Christoph,

that would be systemd target, I think:
https://www.freedesktop.org/software/systemd/man/systemd.target.html

But I guess we can discuss that in the #debian-systemd to get better
understanding whether this is correct solution. I'll take care of it in
upcoming days.

Cheers,
-- 
Ondřej Surý <ond...@sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver
Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro
pečení chleba všeho druhu

On Sun, Mar 26, 2017, at 18:21, Christoph Berg wrote:
> Re: Ondřej Surý 2017-03-26
> <1490536497.4033362.923787296.43821...@webmail.messagingengine.com>
> > I haven't tested it yet, but perhaps we can investigate whether all
> > database packages could "Provide: $database" and all such users could do
> > "Require-Start: $database".
> 
> Makes sense to me. Do we have an idea how that works for systemd
> services files? I'd rather not implement something for sysvinit now
> that doesn't have an systemd equivalent or else it's a regression.
> 
> Christoph
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)

Re: Bug#852776: mariadb-server-10.1: init script doesn't specify it should be started prior to apache2 etc

2017-03-26 Thread Ondřej Surý

Hi Julian,

I understand that apache2 is a usually a "prominent" user of mysql
database, but I am inclined to say, that such dependency would be better
placed in the packages that uses 'mysql', as it would be a tedious to
list all possible dependencies (php-fpm, opendnssec with mysql, etc...)
into the mariadb init script, and it all depends on per-system/per-user
needs.

I haven't tested it yet, but perhaps we can investigate whether all
database packages could "Provide: $database" and all such users could do
"Require-Start: $database".

Similar to what postfix do:

$ cat /etc/insserv.conf.d/postfix 
$mail-transport-agent postfix

So having a:
/etc/insserv.conf.d/mysql
$database mysql

and
/etc/insserv.conf/postgresql-9.6
$database postgresql-9.6

might actually help insserv to figure out the right sysvrc script order.
But I might be mistaken whether this would work if more packages has the
'$database' defined.

Ccing apache2 and postgresql maintainers on this one.

Cheers,
-- 
Ondřej Surý <ond...@sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver
Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro
pečení chleba všeho druhu

Bug#851357: Regression: No longer supports ServerName containing underscore

2017-01-14 Thread Ondřej Surý

Stefan,

JFTR underscores in domain names are allowed, just not for hostnames. SRV, 
TLSA and other RRs make use of them.

O.

On 14 January 2017 17:24:09 Stefan Fritsch  wrote:

On Saturday, 14 January 2017 12:33:55 CET Jonathan Vollebregt wrote:

Actually that makes another point: according to RFC952 hostnames are
allowed only a single period:

http://www.ietf.org/rfc/rfc952.txt

 >   ::= *["."]
 >::= [*[]]

Unless this was updated in another RFC that means apache shouldn't even
support subdomains in virtual hosts, and say goodbye to the .co.uk tld!

No, the *[ ... ] syntax means an arbitrary number of the thing in the
brackets.

I think we can write this off as confusion due to the apache
documentation and say this is an actual bug and ServerName is supposed
to take domainnames

I don't think underscores in domain names are allowed in general. But I know
that they are in are in wide use. So maybe there should be an exception or an
explicit knob to allow them.

A workaround is

HTTPProtocolOptions unsafe

Bug#851357: Regression: No longer supports ServerName containing underscore

2017-01-14 Thread Ondřej Surý


Hi Jonathan,

while I agree that such changes should not happen within one Debian release 
and the maintainer might want to relax the rules for the package, the 
ServerName accepts a hostname as a parameter and a valid hostname cannot 
contain underscore. So the Apache is behaving correctly here not accepting 
invalid hostname.


Cheers, Ondřej


On 14 January 2017 11:42:11 Jonathan Vollebregt  wrote:


Package: apache2
Version: 2.4.25-1
Severity: important

Dear Maintainer,

somewhere between 2.4.23-8 and 2.4.25-1 there was a regression that causes
apache to ignore ServerName directives containing underscores.

I have since tested and confirmed that removing the underscore fixes the
problem as does installing version 2.4.10-10+deb8u7

There is nothing in the error log indicating a problem (Not
surprising since it's not recognising the virtualhost at all)

The site conf file:

$ cat /etc/apache2/sites-available/kint_test.conf

ServerName kint_test.local
ServerAdmin webmaster@localhost
DocumentRoot /home/j/localhost/kint_test
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined


The folder in question: (chmod -R 777, and other sites under
/home/j/localhost work fine so it's not a file permission issue)

$ ls -l /home/j/localhost/kint_test
total 8
-rwxrwxrwx 1 j j 0 Jan 14 11:18 index.html

Relevant part of apache2.conf:


Options Indexes FollowSymLinks
AllowOverride All

Require ip 192.168
Require local


Relevant part of hosts file:

$ grep kint_test /etc/hosts
127.0.0.1   kint_test.local

Server response:

$ curl kint_test.local


400 Bad Request

Bad Request
Your browser sent a request that this server could not understand.

Additionally, a 400 Bad Request
	error was encountered while trying to use an ErrorDocument to handle the 
request.


Apache/2.4.25 (Debian) Server at 127.0.1.1 Port 80



-- Package-specific info:

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (800, 'testing'), (700, 'experimental'), 
  (600, 'stable')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages apache2 depends on:
ii  apache2-bin  2.4.25-1
ii  apache2-data 2.4.25-1
ii  apache2-utils2.4.25-1
ii  dpkg 1.18.18
ii  init-system-helpers  1.46
ii  lsb-base 9.20161125
ii  mime-support 3.60
ii  perl 5.24.1~rc4-1
pn  perl:any 
ii  procps   2:3.3.12-3

Versions of packages apache2 recommends:
ii  ssl-cert  1.0.38

Versions of packages apache2 suggests:
ii  apache2-doc  2.4.25-1
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  chromium [www-browser]   55.0.2883.75-2
ii  firefox-esr [www-browser]45.6.0esr-1
ii  lynx [www-browser]   2.8.9dev11-1
ii  w3m [www-browser]0.5.3-34

Versions of packages apache2-bin depends on:
ii  libapr1  1.5.2-5
ii  libaprutil1  1.5.4-3
ii  libaprutil1-dbd-sqlite3  1.5.4-3
ii  libaprutil1-ldap 1.5.4-3
ii  libc62.24-8
ii  libldap-2.4-22.4.44+dfsg-3
ii  liblua5.2-0  5.2.4-1.1+b1
ii  libnghttp2-141.18.1-1
ii  libpcre3 2:8.39-2
ii  libssl1.0.2  1.0.2j-5
ii  libxml2  2.9.4+dfsg1-2.1
pn  perl:any 
ii  zlib1g   1:1.2.8.dfsg-4

Versions of packages apache2-bin suggests:
ii  apache2-doc  2.4.25-1
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  chromium [www-browser]   55.0.2883.75-2
ii  firefox-esr [www-browser]45.6.0esr-1
ii  lynx [www-browser]   2.8.9dev11-1
ii  w3m [www-browser]0.5.3-34

Versions of packages apache2 is related to:
ii  apache2  2.4.25-1
ii  apache2-bin  2.4.25-1

-- Configuration Files:
/etc/apache2/apache2.conf changed [not included]
/etc/apache2/sites-available/000-default.conf changed [not included]

-- no debconf information

Bug#828236: Bug#844160: marked as done (apache2-dev should depend on libssl1.0-dev)

2016-11-13 Thread Ondřej Surý

On Mon, Nov 14, 2016, at 08:21, Adrian Bunk wrote:
> On Mon, Nov 14, 2016 at 05:03:45AM +0100, Ondřej Surý wrote:
> > > Looking at mod_ssl_openssl.h and the comment in #828330,
> > > I'd suggest the change below to add a dependency on libssl1.0-dev
> > > to apache2-dev.
> > 
> > And that exactly happens meaning that PHP 7.0 can no longer be built
> > unless all it's build-depends (including PHP 7.0) and rdepends move to
> > libssl1.0-dev as well.
> > 
> > So a nice deadlock, right? To be honest I would rather have a slightly
> > less tested apache2 with OpenSSL 1.1.0 and iron out the bugs as we go
> > than revert all the work I have done.
> > 
> > I reviewed the patch Kurt has provided and I don't see any strong reason
> > why anything should break.
> >...
> 
> Can you guarantee that rdeps of Apache can use 1.0.2 in stretch when 
> Apache itself uses 1.1?

Why?

> That is the most important question here.

No, I think the question is:

Can we migrate (or drop) all rdeps to 1.0.2?

> This is what my "mod_ssl_openssl.h and the comment in #828330"
> was referring to.
> 
> The dual 1.0.2/1.1 setup for stretch can only work when any set of 
> packages in the archive that needs the same OpenSSL version stays
> at 1.0.2 unless *all* packages in this set are compiling and working
> fine with 1.1

The *set* you are talking probably cover whole archive, since the
Build-Depends of PHP are quite vast and here are the Build-Depends
of Build-Depends:

(This is from stretch, not from unstable)
apache2-dev libssl-dev (>= 0.9.8m)
libc-client2007e-dev libssl-dev
libcurl4-openssl-dev libssl-dev
libevent-dev libssl-dev
libkrb5-dev libssl-dev
libpq-dev libssl-dev
libsasl2-dev libssl-dev
libsnmp-dev libssl-dev (>> 0.9.8)

Greping just Depends: on -dev packages is slightly more optimistic:

apache2-dev libssl-dev (<< 1.1)
libc-client2007e-dev libssl-dev
libpq-dev libssl-dev
libsnmp-dev libssl-dev

But ultimately I am afraid that libssl dependencies are so entagled
that it will cover all archive.

> And since the OpenSSL version used is part of the libcurl3 ABI
> (see #844018 for details), using 1.1 in stretch is anyway not
> really an option for Apache/PHP in stretch.

What you are really saying is that using OpenSSL 1.1 is generally
not an option for stretch.

Cheers,
-- 
Ondřej Surý <ond...@sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver
Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro
pečení chleba všeho druhu

Bug#828236: Bug#844160: marked as done (apache2-dev should depend on libssl1.0-dev)

2016-11-13 Thread Ondřej Surý

> Looking at mod_ssl_openssl.h and the comment in #828330,
> I'd suggest the change below to add a dependency on libssl1.0-dev
> to apache2-dev.

And that exactly happens meaning that PHP 7.0 can no longer be built
unless all it's build-depends (including PHP 7.0) and rdepends move to
libssl1.0-dev as well.

So a nice deadlock, right? To be honest I would rather have a slightly
less tested apache2 with OpenSSL 1.1.0 and iron out the bugs as we go
than revert all the work I have done.

I reviewed the patch Kurt has provided and I don't see any strong reason
why anything should break.

~~~

ssl_engine_io_init() is called but return value is not checked although
it might obviously fail as the function can return 0 on failure.

~~~

This bit looks suspicious as it changes the existing behavior:

-/* XXX: Should replace setting state with
SSL_renegotiate(ssl);
- * However, this causes failures in perl-framework
currently,
- * perhaps pre-test if we have already negotiated?
- */
-#ifdef OPENSSL_NO_SSL_INTERN
-SSL_set_state(ssl, SSL_ST_ACCEPT);
-#else
-ssl->state = SSL_ST_ACCEPT;
-#endif
+/* XXX: Why is this done twice? */
+SSL_renegotiate(ssl);
+/* XXX: Return value ignored, uses SSL_get_state instead?
*/

but it might be correct...

~~~

There also seem to be some changes unrelated to OpenSSL 1.1.0 as:

-RAND_pseudo_bytes(iv, EVP_MAX_IV_LENGTH);
+/* XXX: Return value not checked. */
+RAND_bytes(iv, EVP_MAX_IV_LENGTH);

or adding:
+SRP_user_pwd_free(u);

I think this should be in separate patch.

~~~

Kurt, can you confirm this doesn't change behavior of the code?

-else if (cert->valid && X509_check_issued(cert,cert) == X509_V_OK)
{
+else if (X509_check_issued(cert, cert) == X509_V_OK) {

~~~

Wrong ws here:

-nid = OBJ_obj2nid((ASN1_OBJECT
*)(xs->cert_info->key->algor->algorithm));
+X509_PUBKEY *pubkey = X509_get_X509_PUBKEY(xs);
+   X509_ALGOR *algor;
+   X509_PUBKEY_get0_param(NULL, NULL, NULL, , pubkey);
+nid = OBJ_obj2nid(algor->algorithm);

and here:

@@ -398,7 +403,9 @@ static int stapling_check_response(serve
 
 if (bio) {
 int n;
-if ((i2a_ASN1_INTEGER(bio, cinf->cid->serialNumber) !=
-1) &&
+ASN1_INTEGER *serial;
+   OCSP_id_get0_info(NULL, NULL, NULL, , cinf->cid);
+if ((i2a_ASN1_INTEGER(bio, serial) != -1) &&
 ((n = BIO_read(bio, snum, sizeof snum - 1)) > 0))
 snum[n] = '\0';
 BIO_free(bio);

Cheers,
-- 
Ondřej Surý <ond...@sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver
Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro
pečení chleba všeho druhu

On Sun, Nov 13, 2016, at 13:36, Debian Bug Tracking System wrote:
> Your message dated Sun, 13 Nov 2016 12:34:03 +
> with message-id <e1c5tz1-000gfb...@fasolo.debian.org>
> and subject line Bug#844160: fixed in apache2 2.4.23-7
> has caused the Debian Bug report #844160,
> regarding apache2-dev should depend on libssl1.0-dev
> to be marked as done.
> 
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
> 
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
> 
> 
> -- 
> 844160: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844160
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
> Email had 2 attachments:
> + apache2-dev should depend on libssl1.0-dev
>   3k (message/rfc822)
> + Bug#844160: fixed in apache2 2.4.23-7
>   8k (message/rfc822)

Re: [php-maint] Bug#827446: libapache2-mod-php5: postinst script changes MPM back to prefork, even with updates

2016-06-16 Thread Ondřej Surý

Control: reassign -1 apache2
Control: affects -1 libapache2-mod-php5

Rudy,

this needs to be fixed in apache2. Generally speaking a2enmod honors
when administrator disables the module and it doesn't re-enable it in
maintainer scripts, I have no idea why this is not the case with
apache2_switch_mpm. Maybe apache2 maintainers can shed some light on it.

Cheers,
-- 
Ondřej Surý <ond...@sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver
Vše pro chleba (https://vseprochleba.cz) – Potřeby pro pečení chleba
všeho druhu

On Thu, Jun 16, 2016, at 10:31, Rudy Broersma wrote:
> Package: libapache2-mod-php5
> Version: 5.6.22+dfsg-0+deb8u1
> Severity: minor
> 
> Dear Maintainer,
> 
> We have noticed that when a Debian package update is released for
> libapache2-mod-php5,
> that the dpkg/apt postinst script changes the Apache2 MPM back to
> prefork. This
> is done in /var/lib/dpkg/info/libapache2-mod-php5.postinst line 15 to 21:
> 
> mpm=$(a2query -M)
> case "$(a2query -M)" in
> prefork|itk) return 0;;
> *) if apache2_switch_mpm prefork; then return 0; fi;;
> esac
> apache2_msg err "Could not switch to prefork MPM, not enabling
> php5"
> return 1
> 
> In our situation, we have software that depends on libapache2-mod-php5
> (Plesk), but
> do not actually use php5 as an Apache module. We are also running the
> event MPM.
> 
> Now, with an update to this package, the MPM on production machines is
> changed back
> to the prefork MPM causing configuration to get lost, settings like
> MaxClients to fallback
> to tiny defaults, etc, etc.
> 
> I can understand that when installing libapache2-mod-php5 changing the
> MPM is justified,
> but I dont feel this is justified when installing updates. For example,
> in our
> case we dont use the PHP5 module, but we need it due to dependencies by
> Plesk.
> 
> Usually, when installing Debian updates, and the package comes with a
> modified configuration
> file dpkg will ask the administrator if he wants to ignore, view or
> implement the new configuration
> file. I believe this is the way to go when changing the MPM as well, as
> it means a pretty
> heafty change to the Apache webserver.
> 
> The postinst script currently just changes the MPM without asking any
> questions. I feel this
> is a too big of a change to perform without asking for confirmation.
> 
> So in short I would like to propose a change to the postinst script for
> this package:
> 
> 1. Require user input for changing the MPM. This will also ensure the
> package is not
>updated using unattended-upgrades (which is what happend in our case).
> 
> or
> 
> 2. Stop changing the MPM, atleast when updating the package.
> 
> 
> -- Package-specific info:
>  Additional PHP 5 information 
> 
>  PHP 5 SAPI (php5query -S): 
> apache2
> cgi
> fpm
> embed
> cli
> 
>  PHP 5 Extensions (php5query -M -v): 
> pdo_sqlite (Enabled for apache2 by maintainer script)
> pdo_sqlite (Enabled for cgi by maintainer script)
> pdo_sqlite (Enabled for fpm by maintainer script)
> pdo_sqlite (Enabled for embed by maintainer script)
> pdo_sqlite (Enabled for cli by maintainer script)
> imap (Enabled for apache2 by maintainer script)
> imap (Enabled for cgi by maintainer script)
> imap (Enabled for fpm by maintainer script)
> imap (Enabled for embed by maintainer script)
> imap (Enabled for cli by maintainer script)
> intl (Enabled for apache2 by maintainer script)
> intl (Enabled for cgi by maintainer script)
> intl (Enabled for fpm by maintainer script)
> intl (Enabled for embed by maintainer script)
> intl (Enabled for cli by maintainer script)
> curl (Enabled for apache2 by maintainer script)
> curl (Enabled for cgi by maintainer script)
> curl (Enabled for fpm by maintainer script)
> curl (Enabled for embed by maintainer script)
> curl (Enabled for cli by maintainer script)
> pdo (Enabled for apache2 by maintainer script)
> pdo (Enabled for cgi by maintainer script)
> pdo (Enabled for fpm by maintainer script)
> pdo (Enabled for embed by maintainer script)
> pdo (Enabled for cli by maintainer script)
> sqlite3 (Enabled for apache2 by maintainer script)
> sqlite3 (Enabled for cgi by maintainer script)
> sqlite3 (Enabled for fpm by maintainer script)
> sqlite3 (Enabled for embed by maintainer script)
> sqlite3 (Enabled for cli by maintainer script)
> mysql (Enabled for apache2 by maintainer script)
> mysql (Enabled for cgi by maintainer script)
> mysql (Enabled for fpm by maintainer script)
&g

Bug#823497: /usr/sbin/a2enmod: a2enmod: downgrade perl 5.16 requirements to allow Ubuntu backports

2016-05-05 Thread Ondřej Surý

Package: apache2
Version: 2.4.10-10+deb8u4
Severity: wishlist
File: /usr/sbin/a2enmod
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

could you please apply attached patch to allow easier Ubuntu precise backports?

Cheers,
Ondrej

- -- Package-specific info:

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

Kernel: Linux 4.2.0-35-generic (SMP w/24 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apache2 depends on:
ii  apache2-bin2.4.10-10+deb8u4
ii  apache2-data   2.4.10-10+deb8u4
ii  apache2-utils  2.4.10-10+deb8u4
ii  dpkg   1.17.27
ii  lsb-base   4.1+Debian13+nmu1
ii  mime-support   3.58
ii  perl   5.20.2-3+deb8u4
ii  procps 2:3.3.9-9

Versions of packages apache2 recommends:
ii  ssl-cert  1.0.35

Versions of packages apache2 suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
pn  www-browser  

Versions of packages apache2-bin depends on:
ii  libapr1  1.5.1-3
ii  libaprutil1  1.5.4-1
ii  libaprutil1-dbd-sqlite3  1.5.4-1
ii  libaprutil1-ldap 1.5.4-1
ii  libc62.19-18+deb8u4
ii  libldap-2.4-22.4.40+dfsg-1+deb8u2
ii  liblua5.1-0  5.1.5-7.1
ii  libpcre3 2:8.35-3.3+deb8u4
ii  libssl1.0.0  1.0.1k-3+deb8u5
ii  libxml2  2.9.1+dfsg1-5+deb8u1
ii  perl 5.20.2-3+deb8u4
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages apache2-bin suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
pn  www-browser  

Versions of packages apache2 is related to:
ii  apache2  2.4.10-10+deb8u4
ii  apache2-bin  2.4.10-10+deb8u4

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJXKy9FXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMEI5MzNEODBGQ0UzRDk4MUEyRDM4RkIw
Qzk5QjcwRUY0RkNCQjA3AAoJEAyZtw70/LsHvUcQAOCv54Qi/qBR4H9qUkCmBpz3
JRdcimRSjNxoTc7r/0QDs57tJTH1pG6/ZTQhlqbjQQlX5LuPyN6bWpiaDArO3+A3
wL8AIx9s9Eq76cMX1lu3H1gewjYM1jbLcPgW8CtbP/HDktx1bpZhw+N0hvpM0jZF
HDKq7f5z7p6AR60Pe+i2ibIY1/opvnZ+1Zj3t0QMc9WiRfDpzZUk/X+cIdQ8rma6
s+JAKZy55+9GxwIijg96LnYV0UeNpc5H04hUk0JixKEmcmZCInqnl6SSdt/mMnxm
o70jRF8dtzEkc0T/t0wJsHGBK/zLyY3vDkoCW8Iarv0GFH5EEav/G0i483RmxkaX
OoWAg8Co62ugH/5HuyZYrUVthKhoV9bmSm5Fli7nM365I7NffISZ9X09Xh+gcCM2
NCLjgisZPl9BcJzQGktqj4Y/ockTaSyHziG1ET4f8IK+l5Tpbi7XJ1/4xv1qu3nZ
DEn/BC/K1zK6jXnfGqSWTnyqOYBvgvH2w15cFfRTYp1a0b1qT2ZhGe6Az6nU2Ck6
1c6EjhGqnxN+blya7odPesddz8IgXqD2UTwQHA7UGx0bCXZbWQYRM39ExAnskqLq
M8rkCePjlnB0ZP5LtlnE2FLGymBo8TJS8WmqZWoWKobTnVM6Bgd55YRZEaOM6Z/x
1Xa8XvjzyLAp/L6ckBQi
=Iu+9
-END PGP SIGNATURE-
>From 119ca64c1e135e06ceb17a2033ec1243aea315e7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ond=C5=99ej=20Sur=C3=BD?= 
Date: Wed, 20 Apr 2016 16:09:30 +0200
Subject: [PATCH] Don't require perl 5.16 just for 'no warnings
 experimental::smartmatch;'

---
 debian/a2enmod | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/a2enmod b/debian/a2enmod
index 196b22d..350a285 100755
--- a/debian/a2enmod
+++ b/debian/a2enmod
@@ -11,8 +11,8 @@ use File::Spec;
 use File::Basename;
 use File::Path;
 use Getopt::Long;
-use feature ':5.16';
-no warnings "experimental::smartmatch";
+use 5.014;
+no if $] >= 5.017011, warnings => 'experimental::smartmatch';
 
 my $quiet;
 my $force;
-- 
2.1.4

Bug#821956: make a2enmod work with perl 5.14 (Ubuntu Precise)

2016-04-20 Thread Ondřej Surý

Source: apache2
Version: 2.4.18-2
Severity: minor
Tags: patch

Hi Stephan and Arno,

attached is a patch that makes a2enmod to run on Ubuntu Precise with
perl 5.14 while hopefully not breaking anything else :).  While
looking into perl code, I felt as if millions of voices suddenly cried
out in terror, and were suddenly silenced, so this might also be
horribly wrong :)

Cheers,
Ondrej

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

Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
>From 5035e4f5a1feff5b1f20ecfff6ae786ff3214816 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ond=C5=99ej=20Sur=C3=BD?= 
Date: Wed, 20 Apr 2016 16:09:30 +0200
Subject: [PATCH] Don't require perl 5.16 just for 'no warnings
 experimental::smartmatch;'

---
 debian/a2enmod | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/a2enmod b/debian/a2enmod
index 196b22d..350a285 100755
--- a/debian/a2enmod
+++ b/debian/a2enmod
@@ -11,8 +11,8 @@ use File::Spec;
 use File::Basename;
 use File::Path;
 use Getopt::Long;
-use feature ':5.16';
-no warnings "experimental::smartmatch";
+use 5.014;
+no if $] >= 5.017011, warnings => 'experimental::smartmatch';
 
 my $quiet;
 my $force;
-- 
2.1.4

Re: [php-maint] Bug#791902: libapache2-mod-php5.postinst: 291: [: !=: unexpected operator

2015-08-28 Thread Ondřej Surý

Control: reassign -1 apache2
Control: affects -1 libapache2-mod-php5

I think this:

 There is more than one MPM loaded. Do not proceed due to undefined
 results

should not happen...  But as I said the pulled code comes from apache2,
so apache2 maintainers might have some ideas why is this happening.

Cheers,
Ondrej

On Fri, Aug 28, 2015, at 00:43, Carlos C Soto wrote:
 Same problem here but I'm running Debian 8.1
 
 Package: libapache2-mod-php5
 Version: 5.6.12+dfsg-0+deb8
 Architecture: amd64
 
 Configuring libapache2-mod-php5 (5.6.12+dfsg-0+deb8u1) ...
 There is more than one MPM loaded. Do not proceed due to undefined
 results
 There is more than one MPM loaded. Do not proceed due to undefined
 results
 There is more than one MPM loaded. Do not proceed due to undefined
 results
 /var/lib/dpkg/info/libapache2-mod-php5.postinst: 291: [: !=: unexpected 
 operator
 apache2_switch_mpm prefork: No action required
 apache2_invoke: Enable module php5
 
 
 In my case apache was running and as I can see no invoke-rc.d was called 
 (last line)
 
 Thanks in advance developers!
 
 ___
 pkg-php-maint mailing list
 pkg-php-ma...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-maint


-- 
Ondřej Surý ond...@sury.org
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

Fwd: Re: [php-maint] Bug#791902: libapache2-mod-php5.postinst: 291: [: !=: unexpected operator

2015-07-09 Thread Ondřej Surý

-- 
Ondřej Surý ond...@sury.org
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

- Original message -
From: Ondřej Surý ond...@sury.org
To: Andreas Beckmann a...@debian.org, 791...@bugs.debian.org,
debian-ap...@lists.debian.org
Subject: Re: [php-maint] Bug#791902: libapache2-mod-php5.postinst: 291:
[: !=: unexpected operator
Date: Thu, 09 Jul 2015 16:10:08 +0200

Hi Andreas,

https://qa.debian.org/developer.php?email=

we pull /usr/share/apache2/apache2-maintscript-helper, so that error
probably comes from there.

I am Ccing apache2 maintainers, they might have some insight on that...

Cheers,
Ondrej

On Thu, Jul 9, 2015, at 13:59, Andreas Beckmann wrote:
 Package: libapache2-mod-php5
 Version: 5.6.9+dfsg-1
 Severity: important
 User: debian...@lists.debian.org
 Usertags: piuparts

 Hi,

 during a test with piuparts I noticed your package reported a postinst
 error upon installation but did not fail on it.
 I noticed this while analyzing the failure log from testing
 fusionforge-plugin-gravatar.

 From the attached log (scroll to the bottom...):

   Setting up libapache2-mod-php5 (5.6.9+dfsg-1) ...

   Creating config file /etc/php5/apache2/php.ini with new version
   There is more than one MPM loaded. Do not proceed due to undefined
   results
   There is more than one MPM loaded. Do not proceed due to undefined
   results
   There is more than one MPM loaded. Do not proceed due to undefined
   results
   /var/lib/dpkg/info/libapache2-mod-php5.postinst: 291: [: !=: unexpected
   operator
   apache2_switch_mpm prefork: No action required
   apache2_invoke: Enable module php5
   invoke-rc.d: policy-rc.d denied execution of restart.

 That postinst script has only 78 lines, no idea where this error comes
 from.

 cheers,

 Andreas
 ___
 pkg-php-maint mailing list
 pkg-php-ma...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-maint
 Email had 1 attachment:
 + fusionforge-plugin-gravatar_6.0.2+20150708-1.log.gz
   67k (application/gzip)

-- 
Ondřej Surý ond...@sury.org
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

--
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1436451786.1841141.319485033.2ab81...@webmail.messagingengine.com

Bug#716880: Solutions for the Apache upgrade hell

2014-07-14 Thread Ondřej Surý

Hi Arno,

On Sun, Jul 13, 2014, at 13:17, Arno Töll wrote:
 Hello,
 
 we've got a problem with Apache that causes problems during upgrades
 (e.g. #716880, #752922, #711925). In short, the issue is that Apache 2.4
 changed ABIs, so that we need to ensure that dpkg properly removes
 packages linking against the obsolete ABIs at upgrade time. This is the
 first time this happened since Debian Etch, so this brings a problem to
 the spotlight, that hasn't been one for a long time.
 
 To summarize the bug reports: The problem is, that Apache package
 maintainers at that time decided, that third party modules shall depend
 on apache2.2-common, by guaranteeing ABIs remain stable as long as the
 package name does not change. This is, so far policy compliant. However,
 by now ABIs did change and we were forced to rename the package (we did
 so, by providing a virtual API package third parties must depend on. At
 time of writing this is apache2-api-20120211). Unfortunately,
 apache2.2-common also contains conffiles and configuration file handling
 in postinst/postrm ...
 
 I spent a lot of time to properly transition to a new state with
 conffiles/configuration separated from ABI handling, and this works well
 enough for regular updates by now.
 
 Unfortunately it turns out, that /a lot/ of people use aptitude
 --purge-unused safe-upgrade, or the apt equivalent apt-get
 dist-upgrade --purge which causes dpkg to purge the user's
 configuration, in particular enabled modules, during the upgrade because
 apache2.2-common disappears in that step. Those people end up with
 effects as described in the bugs outlined above, for example with
 incomplete installations because our maintainer scripts had no chance to
 properly detect the state of the /etc/apache2 directory before the
 upgrade.
 
 This gives us three possibilities which all have unwanted side effects
 (unless you come up with an idea that all of us makes happy). I'm
 writing to this list in hope that someone has a very smart idea to make
 everyone happy, or express your support for either alternative to give
 us some insights what people think would be the best alternative.
 
 * Add a apache2.2-commmon transitional package. This gives us a chance
 to inspect /etc/apache2 in spite of --purge-unused and properly
 transition to Apache 2.4. HOWEVER, this has the nasty side effect that
 modules ABIs are considered compatible as far as dpkg is concerned.
 Therefore, old module packages aren't forced to be removed and this
 breaks at runtime when people try to start their upgraded web server
 with incompatible modules. As a workaround we could add a versioned
 Breaks for all modules in Wheezy (~ 75) in the apache2.2-common
 transitional package, and in addition for packages that existed in
 Squeeze or Etch only (no, really). That said, this still won't help for
 third party modules outside Debian which people might use (and to my
 best knowledge, they do a lot) and it's generally problematic in view of
 the policy with respect to library packaging (even though we're not a
 library strictly speaking)

This + BIG FAT WARNING in release notes seems to be the best option
to me.

People's configuration will probably break anyway due custom
configuration
files, etc. or manually compiled modules[1][2].

Also if people have custom modules that will get removed in the upgrade,
they wouldn't want to start the apache without those modules anyway -
this could have all kind of security implications - exposing the raw
source
files of interpreted languages, etc.

1. As an option you can walk through all enabled modules in apache2.4
postinst and detect incompatible ABI in /usr/lib/apache2/modules/*.so
files.

2. As a thought did you think about moving the modules under
/usr/lib/apache2/20120211/ (e.g. similar to what PHP has). You still
have time for that and it would make the transition easier in the future
(also with third party modules).

Cheers,
-- 
Ondřej Surý ond...@sury.org
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1405325501.4775.141318941.5caff...@webmail.messagingengine.com

Bug#711925: apache2-doc's config file breaks apache itself

2013-07-25 Thread Ondřej Surý

On Wed, Jul 24, 2013 at 11:16 PM, Arno Töll a...@debian.org wrote:

 On 24.07.2013 22:47, Stefan Fritsch wrote:
  The bug in apache2 is that we still treat this situation as an
  upgrade  in the postinst even if there is nothing left of the old
  install. If we can detect it, we should probably treat it as a new
  install instead.

 I do not think we could in a deterministic way. We might be able to
 guess based on certain heuristics, like no conffiles whatsoever but the
 apache packages being installed. However, I am sure this will bite
 others who deliberately rm'ed all of /etc/apache2 because they think our
 configuration sucks anyway.


Arno,

could you please rethink the idea of re-adding apache2.2-common with
version Breaks: on all reverse depends (with versions from wheezy, the
jessie can be handled by filling RC bugs case-by-case).

O.
-- 
Ondřej Surý ond...@sury.org

Bug#711925: apache2-doc's config file breaks apache itself

2013-07-25 Thread Ondřej Surý

On Thu, Jul 25, 2013 at 1:19 PM, Arno Töll a...@debian.org wrote:

 On 25.07.2013 13:16, Ondřej Surý wrote:
  could you please rethink the idea of re-adding apache2.2-common with
  version Breaks: on all reverse depends (with versions from wheezy, the
  jessie can be handled by filling RC bugs case-by-case).

 Yes, we did not definitely decide on that. It is, however, not going to
 solve this bug in particular as the conffiles would have to move
 regardless from apache2.2-common to apache2 which is the root cause with
 --purge-unsued.


Wouldn't

Package: apache2
Replaces: apache2.2-common ( 2.4.0)
Breaks: apache2.2-common ( 2.4.0)

Solve the problem?

E.g. from Debian policy manual 7.6.1:

If a package is completely replaced in this way, so that dpkg does not know
of any files it still contains, it is considered to have disappeared. It
will be marked as not wanted on the system (selected for removal) and not
installed. Any conffiles details noted for the package will be ignored, as
they will have been taken over by the overwriting package. The package's
postrm script will be run with a special argument to allow the package to
do any final cleanup required. See Summary of ways maintainer scripts are
called, Section 6.5. [54]

O.
-- 
Ondřej Surý ond...@sury.org

Bug#711925: apache2-doc's config file breaks apache itself

2013-07-25 Thread Ondřej Surý

On Thu, Jul 25, 2013 at 1:35 PM, Arno Töll a...@debian.org wrote:

 On 25.07.2013 13:25, Ondřej Surý wrote:
  Wouldn't
 
  Package: apache2
  Replaces: apache2.2-common ( 2.4.0)
  Breaks: apache2.2-common ( 2.4.0)
 
  Solve the problem?

 That's what we do already (minus breaks). That allows us to overwrite
 and take-over conffiles from apache2.2-common. This works nicely and
 does what it is supposed to do - except in cases where people use
 --purge-unused because they think that's fun.

 In that case apt[itude] decides to purge all of /etc/apache2 entirely
 _before_ we have a deterministic chance to do look at the state, because
 apache2.2-common is going to be removed by upgrading to 2.4.

 I am not sure if an empty 2.2-common package in addition to that would
 solve that problem, as it would ship none of the conffiles either, so
 consequently they would still be purged.


It's worth trying, isn't it? I think it would help, because it would get
purged later in the upgrade process (when apache2 is installed and replaces
the apache2.2-common).

O.
-- 
Ondřej Surý ond...@sury.org

Re: Bug#717610: a second run of aptitude safe-upgrade clears it

2013-07-23 Thread Ondřej Surý

I am quite sure it's related to:

   * Allow the use of apache2-maintscript-helper from a sub-function. We
rely
 on dpkg's arguments supplied in $1, $2 etc. This clashes with function
 arguments supplied to to sh sub-function. Allow manual override in such
 cases.

And I would say it's a regression from apache2 2.4.4-6 to 2.4.6-1.

The only place I am using apache2 maintscript helper from modified
environment is:

php5_enable() {
if [ $(a2query -M) != 'prefork' ] ; then
if apache2_switch_mpm prefork ; then
return 0
else
apache2_msg err Could not switch to prefork MPM, not
enabling php5
return 1
fi
fi
return 0
}

And I don't think that the apache2 modules should be doing some extra work
to pass the arguments in php5_enable function.

Also installing just libapache2-mod-php5 works, so I would say that it's
probably bug in apache2-maintscript-helper and not in the php5, but I hope
Arno will look at this soon enough.

Ondrej


On Tue, Jul 23, 2013 at 11:36 AM, Andreas Beckmann a...@debian.org wrote:

 Control: affects -1 + phpbb3 debian-edu-config-gosa-netgroups

   Processing triggers for libapache2-mod-php5 ...
   apache2-maintscript-helper invoked from a modified environment.
 Please hint required arguments manually

 On 2013-07-23 08:38, jida...@jidanni.org wrote:
  I get the same message. But then a second run of aptitude safe-upgrade
  gives no more error. Perhaps there is a bug too in aptitude?

 So it's ordering related ... but not a fault in apt/aptitude

 Anyway, the same problem appears in piuparts tests of

   debian-edu-config-gosa-netgroups
   phpbb3


 Andreas




--
Ondřej Surý ond...@sury.org

Bug#717610: [php-maint] Bug#717610: a second run of aptitude safe-upgrade clears it

2013-07-23 Thread Ondřej Surý

On Tue, Jul 23, 2013 at 12:32 PM, Arno Töll a...@debian.org wrote:

 On 23.07.2013 12:29, Ondřej Surý wrote:
  Control: reassign -1 apache2
  Control: retitle -1 apache2-maintscript-helper doesn't support dpkg
 triggers

 Yep, thanks. That is it. Did you recently enable triggers for your
 maintainer script so that the 2.4.6-1 upload is just coincidence?


Nope, the triggers are there for a long time. But it happens only if a
php5-module is installed on top if libapache2-mod-php5{,filter}.

O.
-- 
Ondřej Surý ond...@sury.org

Re: [php-maint] Bug#711454: libapache2-mod-php5: MPM prefork not found ... == ... Syntax error on line 9 of /etc/apache2/mods-enabled/php5.conf: Invalid command 'Order'

2013-06-07 Thread Ondřej Surý

reassign 711454 apache2
affects 711454 +php5
thank you

Hi apache2 maintainers,

there seems to be a glitch in the apache2 scripts or transition manual, which 
prevents MPM to be switched before the apache2 is configured.

It looks like I will need to Pre-Depend on apache2 = 2.4 for the transition 
period from 2.2 to 2.4.

That's also probably something which would be better places in dh helper to add 
replacement for ${apache2:Pre-Depends} which I would place into Pre-Depends:, 
so it can be dropped automatically when no longer needed.

Ondřej Surý

On 7. 6. 2013, at 0:45, Andreas Beckmann a...@debian.org wrote:

 Package: libapache2-mod-php5
 Version: 5.5.0~rc2+dfsg-2
 Severity: important
 Control: affects -1 + typo3-dummy
 
 Hi,
 
 while doing piuparts upgrade tests to sid I noticed the following:
 
 (libapache2-mod-php5):
  apache2_switch_mpm: MPM prefork not found
  Could not switch to prefork, not enabling php5
 
 (apache2):
  AH00526: Syntax error on line 9 of /etc/apache2/mods-enabled/php5.conf:
  Invalid command 'Order', perhaps misspelled or defined by a module not 
 included in the server configuration
 
 a bit more context, full log attached:
 
  Setting up php5-common (5.5.0~rc2+dfsg-2) ...
  Installing new version of config file /etc/cron.d/php5 ...
 
  Creating config file /etc/php5/mods-available/opcache.ini with new version
  Setting up libapache2-mod-php5 (5.5.0~rc2+dfsg-2) ...
  Replacing config file /etc/php5/apache2/php.ini with new version
  apache2_switch_mpm: MPM prefork not found
  Could not switch to prefork, not enabling php5
  Setting up apache2-data (2.4.4-5) ...
  Setting up apache2 (2.4.4-5) ...
  Installing new version of config file /etc/logrotate.d/apache2 ...
  Installing new version of config file /etc/init.d/apache2 ...
  Installing new version of config file /etc/apache2/envvars ...
  Installing new version of config file /etc/apache2/mods-available/dir.conf 
 ...
  Installing new version of config file 
 /etc/apache2/mods-available/mime_magic.conf ...
  Installing new version of config file 
 /etc/apache2/mods-available/include.load ...
  Installing new version of config file 
 /etc/apache2/mods-available/autoindex.conf ...
  Installing new version of config file /etc/apache2/mods-available/ldap.conf 
 ...
  Installing new version of config file 
 /etc/apache2/mods-available/authz_dbm.load ...
  Installing new version of config file /etc/apache2/mods-available/cgid.conf 
 ...
  Installing new version of config file 
 /etc/apache2/mods-available/userdir.conf ...
  Installing new version of config file /etc/apache2/mods-available/ssl.load 
 ...
  Installing new version of config file /etc/apache2/mods-available/alias.conf 
 ...
  Installing new version of config file 
 /etc/apache2/mods-available/setenvif.conf ...
  Installing new version of config file 
 /etc/apache2/mods-available/dav_fs.conf ...
  Installing new version of config file 
 /etc/apache2/mods-available/proxy_balancer.load ...
  Installing new version of config file 
 /etc/apache2/mods-available/authz_groupfile.load ...
  Installing new version of config file 
 /etc/apache2/mods-available/reqtimeout.conf ...
  Installing new version of config file /etc/apache2/mods-available/ssl.conf 
 ...
  Installing new version of config file 
 /etc/apache2/mods-available/negotiation.conf ...
  Installing new version of config file 
 /etc/apache2/mods-available/deflate.conf ...
  Installing new version of config file /etc/apache2/mods-available/info.conf 
 ...
  Installing new version of config file 
 /etc/apache2/mods-available/proxy_ftp.conf ...
  Installing new version of config file 
 /etc/apache2/mods-available/actions.conf ...
  Installing new version of config file 
 /etc/apache2/mods-available/status.conf ...
  Installing new version of config file 
 /etc/apache2/mods-available/proxy_balancer.conf ...
  Installing new version of config file 
 /etc/apache2/mods-available/authz_user.load ...
  Installing new version of config file /etc/apache2/mods-available/mime.conf 
 ...
  Installing new version of config file /etc/apache2/mods-available/asis.load 
 ...
  Installing new version of config file 
 /etc/apache2/mods-available/authz_host.load ...
  Installing new version of config file /etc/apache2/mods-available/proxy.conf 
 ...
  Installing new version of config file 
 /etc/apache2/mods-available/deflate.load ...
  Installing new version of config file /etc/apache2/apache2.conf ...
  Installing new version of config file /etc/apache2/ports.conf ...
  Installing new version of config file /etc/default/apache2 ...
  Installing new version of config file /etc/cron.daily/apache2 ...
  Removing obsolete conffile /etc/apache2/mods-available/authz_default.load ...
  Removing obsolete conffile /etc/apache2/mods-available/authn_default.load ...
  Removing obsolete conffile /etc/apache2/mods-available/mem_cache.load ...
  Removing obsolete conffile /etc/apache2/mods-available/mem_cache.conf ...
  Removing obsolete conffile

Bug#707024: Bug#661958: Reboot Apache2 2.4 transition

2013-05-16 Thread Ondřej Surý

On Thu, May 16, 2013 at 8:12 PM, Arno Töll a...@debian.org wrote:
 Hi,

 On 13.05.2013 10:51, Ondřej Surý wrote:
 I can ack that PHP 5.5 RC1 is prepared to enter the unstable.
 This will also trigger the libgd and php5.5 transitions.

 jcristau and me wondered if you want us to wait until you have a libgd
 package ready? There seems to be some discussion going on on d-devel
 related to that.

 Could you please clarify?

I have contacted all upstream binding authors and all of them, who get
back to me, report success, so I think we are safe to go.

Right now I have added one more patch (reported in Debian, fixed in
upstream) and I will be uploading to unstable.

Ondrej
--
Ondřej Surý ond...@sury.org


--
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caljhhg9viwamz6e18kai8zdnujywo-jfsufrsb6qurlos6-...@mail.gmail.com

Bug#707024: Bug#661958: Reboot Apache2 2.4 transition

2013-05-13 Thread Ondřej Surý

I can ack that PHP 5.5 RC1 is prepared to enter the unstable.

This will also trigger the libgd and php5.5 transitions.

O.

On Mon, May 13, 2013 at 10:36 AM, Arno Töll a...@debian.org wrote:
 Hi,

 would the Release Team be comfortable with an upload of Apache 2.4 to
 Sid on May, 20? That's a bit sooner than I expected, but on the other
 hand there is not much to gain to wait longer.

 We made good progress with our list of critical reverse dependencies so
 that only one is missing. Hence I believe, an upload on that date is
 feasible.

 --
 with kind regards,
 Arno Töll
 IRC: daemonkeeper on Freenode/OFTC
 GnuPG Key-ID: 0x9D80F36D




-- 
Ondřej Surý ond...@sury.org


--
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caljhhg_utkhwvcgfu9rrgdxnuh2p27-xzi1x4qt+pmcrl5z...@mail.gmail.com

Re: [php-maint] Apache 2.4 MediaWiki Debian tips

2013-05-09 Thread Ondřej Surý

Just don't use PHP 5.5 and Apache 2.4 from *experimental* yet, if you can't 
debug it, please.

Ondřej Surý

On 10. 5. 2013, at 4:36, jida...@jidanni.org wrote:

 Yes so I decided to reinstall from scratch and now index.php is being
 interpreted as plain text so I cannot figure out how to make it
 interpreted as PHP here with apache 2.4 in Debian and any searches just
 give advice for older versions of apache.
 
 ___
 pkg-php-maint mailing list
 pkg-php-ma...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-maint


--
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/421f34a7-48b8-4abe-85d8-c2a6a34e0...@sury.org

Bug#707071: dh_apache2 installs the dismod into postrm instead of prerm (which was common before Apache 2.4)

2013-05-07 Thread Ondřej Surý

Package: apache2-dev
Version: 2.4.4-2
Severity: normal

Hi,

the apache2_invoke dismod module should be installed in prerm,
because the module file cease to exists between prerm and postrm.

Thus if somebody/something restarts the apache2 before the removal
process is complete, the apache2 process will fail to (re)start.

I am filling this as 'normal' since I am not sure if I am correct, but
if I am then this should be a blocker bug (e.g. this needs to be fixed
before upload to unstable).

Ondrej

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130507085355.31083.50363.reportbug@localhost6.localdomain6

Re: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine

2012-10-26 Thread Ondřej Surý

On Sat, Oct 6, 2012 at 9:51 PM, Stefan Fritsch s...@debian.org wrote:
Hi Ondřej,

I also cannot think of any configuration that would make everyone happy. At
the moment, I fear this can only be solved by more documentation.

Maybe one could add such a paragraph to the NEWS entry of php5-cgi 5.4.4-5,
e.g. before The standard configuration now also... :

WARNING: The new configuration may override other configuration
directives you may have added locally for the .php extension, for
example for FastCGI processing. This behavior is caused by FilesMatch
configuration sections overriding directives appearing in global server
or VirtualHost scope. You should review and test your configuration and
verify that your php scripts work as expected.

In the end I have used slightly different text with a warning to check
the existing setup foo.php.jpeg vulnerability. Improvements welcome
(as a patch, not as a rant).

+ The new (dummy) php5_cgi configuration uses SetHandler directive and
+ thus it might interfere with your existing custom configuration like
+ FastCGI (mod_fcgid or mod_fastcgi). In that case please disable
+ php5_cgi module (a2dismod php5_cgi) to reenable the existing
+ functionality of your custom configuration. It is also advised that
+ you check your custom configuration whether it's not vulnerable to
+ foo.php.jpeg attacks. The php5_cgi configuration snippet can be used
+ as base - it's important to use FilesMatch or Files directive to
+ limit the handling to the last extension.

I think it became clear that we are stuck with no solution which would
work for anyone, so this is the minimal variant of what we should do
in PHP package. If somebody comes with better solution (or just tests
the non-magic mime-types as written down by sf in
http://wiki.debian.org/Apache/WheezyMimeTypes), I think we can still
change that before release. But now we at least need more test in
php5-cgi.NEWS.

O.
--
Ondřej Surý ond...@sury.org

--
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caljhhg9sermgxmzpyi0da+kjkj_nbsc_9s0x6aseyv5gps-...@mail.gmail.com

Re: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine

2012-10-08 Thread Ondřej Surý

Stephan,

thanks for the input.

Just one last question which came to my mind. Would this all be fixed
if we added non-magic type to mime-support (e.g.
http://bugs.debian.org/670945) and reverting the changes done in the
php5-cgi package?

That I think would justify change in the mime-support package. Too
much breakage on every front now.

On Sat, Oct 6, 2012 at 9:51 PM, Stefan Fritsch s...@debian.org wrote:
Hi Ondřej,

I also cannot think of any configuration that would make everyone happy. At
the moment, I fear this can only be solved by more documentation.

Maybe one could add such a paragraph to the NEWS entry of php5-cgi 5.4.4-5,
e.g. before The standard configuration now also... :

The README.Debian or the wiki page you are already pointing to should then
list likely candidates for problematic local configurations, like
AddHandler fcgid-script .php. Maybe it could also say, that if all else
fails and the user is willing to live with the *.php.foo problem, the old
behavior can be restored by replacing
etc/apache2/mods-available/php5_cgi.conf with something like

AddType application/x-httpd-php phtml pht php php3 php4 php5
AddType application/x-httpd-php-source phps

to get the old behavior back. What do you think?

This sucks. In hindsight, maybe the mime.types change should have been
deferred until we ugrade to apache 2.4 and people have to adjust their
configs anyway. But I think it's too late now to go back. And leaving the
*.php.foo problem there for yet another release cycle would not have been a
good solution either.

Cheers,
Stefan

--
Ondřej Surý ond...@sury.org

--
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caljhhg-kehf6oknxwww_tq-trho+eqz+sod4479tcn9sum1...@mail.gmail.com

Re: Possible release note for systems running PHP through CGI.

2012-08-21 Thread Ondřej Surý

On Mon, Aug 20, 2012 at 8:12 PM, Stefan Fritsch s...@debian.org wrote:
On Monday 20 August 2012, Ondřej Surý wrote:
Ah, I see; it gets executed when there is no know handler or
mime-type for second extension.

E.g. index.php.jpeg works as expected (e.g. returning PHP source
code), index.php.blubb but gets executed. I don't think there's any
harm in disabling php.foobar and php.blubb files.

There is also the case that the extensions after .php are known to
Apache but are not associated with mime types or handlers. For
example, there are extensions like .de and .en which cause the
Content-Language header to be set, extensions for setting the charset
(e.g. .utf8) and extensions for setting the content-encoding (none
configured by default).

I don't know how often this is actually used together with php.
Setting the Content-* headers in the php script seems saner to me.

Right, I have never seen this to be used together with PHP, but it
probably deserves a note somewhere.

Good to see that we are heading towards a solution anyway.

What shall I do with #674089 ? I can reassign it to php5-cgi so
that your next upload closes it, or do we still need release
notes ?

I think we still might need release notes, but it needs to be
updated based on final impact of changes we have done. I am not
sure if the information about filename.php.unknown-mime-type
is worth release notes or just NEWS file in PHP. My guess would be
latter, but opinions may vary.

Maybe add just a small paragraph that the configuration of the
extensions has changed and php users should read the NEWS file?

That's probably sensible approach. I have quickly drafted short
paragraph which can be used for release notes:

Default PHP extension configuration
---

The mime-types package has dropped non-standard definitions of
PHP MIME-Types as a security measure. Default PHP configuration
for libapache2-mod-php5{filter} and php5-cgi now only serve files
which have .php, .php[345] and .phtml extensions on a most right
place as opposed to previous state where filename.php.foobar
would have been interpreted. Please read NEWS file in the PHP
SAPI of your choice for further information.

---

O.
--
Ondřej Surý ond...@sury.org

--
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CALjhHG_CqTNyOY2K8QwLk=yFAJ6JYKDvs9aRAjFUVGdYZCB=l...@mail.gmail.com

Re: Possible release note for systems running PHP through CGI.

2012-08-21 Thread Ondřej Surý

 Default PHP extension configuration

^^^
This needs Apache 2, e.g.

Default PHP extension configuration for Apache 2.

 ---

 The mime-types package has dropped non-standard definitions of
 PHP MIME-Types as a security measure.  Default PHP configuration
 for libapache2-mod-php5{filter} and php5-cgi now only serve files
 which have .php, .php[345] and .phtml extensions on a most right
 place as opposed to previous state where filename.php.foobar
 would have been interpreted.  Please read NEWS file in the PHP
 SAPI of your choice for further information.

O.
-- 
Ondřej Surý ond...@sury.org


--
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caljhhg_0smdoegerxyen1u0mxgpmyyt1gbvmqdmictt-u4e...@mail.gmail.com

Re: Possible release note for systems running PHP through CGI.

2012-08-21 Thread Ondřej Surý

On Tue, Aug 21, 2012 at 9:38 AM, Konstantin Khomoutov
flatw...@users.sourceforge.net wrote:
 On Tue, Aug 21, 2012 at 09:07:59AM +0200, Ondřej Surý wrote:

 [...]
 Maybe add just a small paragraph that the configuration of the
 extensions has changed and php users should read the NEWS file?

 That's probably sensible approach.  I have quickly drafted short
 paragraph which can be used for release notes:

 Default PHP extension configuration
 ---

 The mime-types package has dropped non-standard definitions of
 PHP MIME-Types as a security measure.  Default PHP configuration
 for libapache2-mod-php5{filter} and php5-cgi now only serve files
 which have .php, .php[345] and .phtml extensions on a most right
 place as opposed to previous state where filename.php.foobar
 would have been interpreted.  Please read NEWS file in the PHP
 SAPI of your choice for further information.

 I fail to parse that on a most right place bit though I'm not a native
 speaker.  If you meant that those extension specifications form a minimal
 sane and safe subset, may be just go ahead and write exactly that. ;-)

Nope I mean that the extension should be last.

E.g.  index.blah.php, but not index.php.blah.

O.
-- 
Ondřej Surý ond...@sury.org


--
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CALjhHG8-3XkmJK53qrHpJjvFBATpproJB�h5rk7pgksmj...@mail.gmail.com

Re: Possible release note for systems running PHP through CGI.

2012-08-20 Thread Ondřej Surý

Hi all,

[multiple messages from d-d and d-r merged together]

I am also concerned that a *simple* solution to restore the old
behaviour in a secure way is not provided: maybe php5-cgi should install
a sensible default configuration in /etc/apache2/conf.d/ ?

I have prepared new update for PHP based on comments from d-d. The
commit is here:

http://anonscm.debian.org/gitweb/?p=pkg-php/php.git;a=commit;h=72eef08994f65b227103509617652d7c0bf0587a

To sum the changes:

- create dummy php5_cgi module, which has the required configuration inside
- enable this module if upgrading from anything older than 5.4.4-5
- the module is not enabled on fresh installs (user has to enable it manually)
- update NEWS.Debian to:

php5 (5.4.4-5) unstable; urgency=low

Please be aware that the mime-types package dropped non-standard
definitions for PHP that might affect any systems using PHP 5 running
as CGI or FastCGI. Following definitions were dropped:

application/x-httpd-phpphtml pht php
application/x-httpd-php-source phps
application/x-httpd-php3 php3
application/x-httpd-php3-preprocessed php3p
application/x-httpd-php4 php4
application/x-httpd-php5 php5

The php5-cgi package mitigates any known issues by creating a (dummy)
apache2 module php5_cgi with a configuration containing handlers for
all previously defined extensions. Even though we believe that this
configuration should keep your PHP scripts interpreted, it might be a
good idea to check your apache2 site-wide configuration and also any
specific PHP configuration for websites running on your system.

As far as we know definitions from the mime-types packages are not
used in any other webserver included in Debian, but it might affect
any application which relies on system MIME types to interpret PHP
files.

-- Ondřej Surý ond...@debian.org Wed, 15 Aug 2012 10:31:31 +0200

- Update the README.Debian to match current state.

I will upload this change as part of 5.4.6-1 upload to Debian experimental
and if everything is ok, I'll merge it back to 5.4.4-5 targeted to
unstable-testing.

As far as the mime-support package is concerned, I think that we reached the
consensus that we will not add the entries back, and that the consequences
will
be documented in the php5-cgi package's NEWS file and in the release notes.

I agree on that, even though I think that PHP should have it's own
mimetype definition (same as python or perl, e.g. application/x-php,
but let's keep this discussion out of this issue, since it's something
different).

I guess we could consider that for a very specific, low-popcon package.
But knowingly interrupting upgrades for a well-known problem, on a very
high number of systems? I'm not sure that's appropriate. Quite the
opposite, actually.

I believe that update that I just did should solve any backwards
compatibility issues. (Crossed fingers... have to do thourough testing
first, I tend to make mistakes from time to time.)

Many of the users of php5-cgi will be doing so because they are using other
web servers. The discussion in #674089 seems to mainly revolve around
Apache. How does this affect other web servers?

I am not aware of any other (Debian shipped) web server which uses
system-wide mime-types. At least both nginx and lighttpd don't depend
on system mime types for interpreting PHP files (both use extension
based definitions).

- In Squeeze, using default configurations, files with .php in their name
such as foo.php.jpeg are executed as PHP scripts by the Apache web
servers
runing PHP scripts through php5-cgi.

Charles, did you test that or you base that claim on Christoph's
mails? I have just tested both php5-cgi in standard configuration as
recommended in README.Debian and this claim doesn't seem to be true:

$ wget -q -O - http://localhost:8080/index.php
bar
$ wget -q -O - http://localhost:8080/index.php.jpeg
?php echo 'foo'; ?

Also Apache2 documentation is very clear on that issue:
See http://httpd.apache.org/docs/2.2/mod/mod_mime.html#multipleext

If more than one extension is given that maps onto the same type of
meta-information, then the one to the right will be used, except for
languages and content encodings. For example, if .gif maps to the MIME-type
image/gif and .html maps to the MIME-type text/html, then the file
welcome.gif.html will be associated with the MIME-type text/html.

However there could be a problem when you use MIME-type and handler
together (which we *don't* use):

Care should be taken when a file with multiple extensions gets associated
with both a MIME-type and a handler. This will usually result in the request
being handled by the module associated with the handler.

Maybe that's because it's expected they would be PHP scripts emitting
JPEG files, not plain JPEG files? This seems like a feature to me, not a
bug. Why

Re: Possible release note for systems running PHP through CGI.

2012-08-20 Thread Ondřej Surý

On Mon, Aug 20, 2012 at 3:35 PM, Charles Plessy ple...@debian.org wrote:
Charles, did you test that or you base that claim on Christoph's
mails? I have just tested both php5-cgi in standard configuration as
recommended in README.Debian and this claim doesn't seem to be true:

$ wget -q -O - http://localhost:8080/index.php
bar
$ wget -q -O - http://localhost:8080/index.php.jpeg
?php echo 'foo'; ?

I did not test, and was trusting from http://bugs.debian.org/589384, which
requested the removal of the PHP media types for Wheezy, that the problem was
still present in some configurations.

Ah, I see; it gets executed when there is no know handler or mime-type
for second extension.

E.g. index.php.jpeg works as expected (e.g. returning PHP source
code), index.php.blubb but gets executed. I don't think there's any
harm in disabling php.foobar and php.blubb files.

Good to see that we are heading towards a solution anyway.

What shall I do with #674089 ? I can reassign it to php5-cgi so that your
next
upload closes it, or do we still need release notes ?

I think we still might need release notes, but it needs to be updated
based on final impact of changes we have done. I am not sure if the
information about filename.php.unknown-mime-type is worth release
notes or just NEWS file in PHP. My guess would be latter, but opinions
may vary.

Also I am not happy that we make these changes so late in release
cycle, but I guess we now have to find a way how to cope with them and
still make release team happy. I think the changes I have done are
least intrusive, but again opinions may vary.

O.
--
Ondřej Surý ond...@sury.org

--
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caljhhg8dd+nv2uvgjbvrtubdna3m+o1afo0bqylyfpqkhuj...@mail.gmail.com

Re: [php-maint] Bug#674089: Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems

2012-08-15 Thread Ondřej Surý

On Wed, Aug 15, 2012 at 4:34 AM, Christoph Anton Mitterer
cales...@scientia.net wrote:
 On Wed, 2012-08-15 at 09:02 +0900, Charles Plessy wrote:
 For the moment there is the draft proposed by Christoph at 
 http://bugs.debian.org/674089#66
 I should note perhaps, that this draft expected all the proposals I made
 in #674205 to be in place, which they were not yet, when I've looked the
 last time.

With the exception of RemoteType php they are all in the place.

Thanks for the text, I will use it as a base for NEWS in php5-cgi.

This is the final text which I have commited to git repository:

php5 (5.4.4-5) unstable; urgency=low

 Please be aware that mime-types package dropped non-standard
 definitions for PHP that might affect any systems using PHP 5
 running as CGI or FastCGI.

 The package mime-types has dropped the following non-standard
 definitions:

  application/x-httpd-phpphtml pht php
  application/x-httpd-php-source phps
  application/x-httpd-php3   php3
  application/x-httpd-php3-preprocessed  php3p
  application/x-httpd-php4   php4
  application/x-httpd-php5   php5

 Systems, especially webservers (including but possibly not limited to
 the Apache HTTPD Server) may have used this to mark files as having
 the a PHP Internet Media Type (commonly known as MIME type).  They
 may have used it further, to determine that such files are to be
 interpreted by PHP rather than served as normal files.

 If a webserver would not consider these files to be interpreted
 anymore this would have at least the following effects:
  - PHP web programs/sites no longer work as expected
  - PHP files might be directly exposed, which may be a security
problem

 In order to avoid any problems when not using Apache PHP5 module, and
 if you relied on MIME type definitions, read the README.Debian from
 the php5-common package on how to correctly configure PHP 5 running
 as a CGI or FastCGI (examples are provided for the Apache HTTPD
 Server) and take care, that and PHP files intended to be interpreted
 are recognised as such (typically by adding MIME-Type or handler
 definitions in the webserver configuration).

 -- Ondřej Surý ond...@debian.org  Wed, 15 Aug 2012 10:31:31 +0200

O.
-- 
Ondřej Surý ond...@sury.org


--
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caljhhg9g3ub5e9fwgozakgj1apb_syy9ej3cr5evomhfxlw...@mail.gmail.com

Re: [php-maint] Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems

2012-08-14 Thread Ondřej Surý

Charles,

On Tue, Aug 14, 2012 at 2:50 AM, Charles Plessy ple...@debian.org wrote:
Le Tue, Aug 14, 2012 at 02:27:33AM +0200, Christoph Anton Mitterer a écrit :

Question: Can any other webservers use mod_php? If so, they _might_ be
vulnerable, as the supplied Apache config snippet probably doesn't apply
to them.

Most people I know run either CGI (if just security
counts) or FPM (if security and/or performance counts)...

If upgrading to Wheezy would unconditionally break these systems,
No,... this is not necessarily the case,.. if people have e.g. set their
own handlers/mime-times for php in apache.

Hi again,

I have the following questions for the PHP maintainers.

1) Can libapache2-mod-php5 be vulnerable ?

I don't think so. And from my testing it doesn't seem to be the case.

2) The user base of php5-cgi is thousands (see Popcon URL below). What
feedback
did you have from Sid and Wheezy users ?

http://qa.debian.org/popcon-graph.php?packages=php5-cgi+libapache2-mod-php5show_vote=onfrom_date=to_date=hlght_date=date_fmt=%25Y-%25mbeenhere=1

None.

3) Will upgrading unconditionally break sites using php5-cgi with Apache ?

Probably.

4) Would you like to implement some of Christoph's suggestion or add a NEWs
file to php5-cgi ?

Yes, I will probably add NEWS file to php5-cgi. Do you already have some
text which can be added to release notes or we still need to cook something
up? I would like to keep this text in sync.

On mime-support's side, I will not add a NEWs file, as it would interrupt the
installation of tens of thousands of systems which do not run PHP.

Understood.

After your answer, I propose to send a brief summary to debian-release and
debian-devel, proposing reassign the bug to the release notes with the same
severity.

Will you take care of that?

O.
--
Ondřej Surý ond...@sury.org

--
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caljhhg9r88mwh1wdpw-fddjzwmegcl4fnvnvryoekpglykg...@mail.gmail.com

Re: [php-maint] Bug#666820: php5: sourceful transition towards Apache 2.4

2012-04-06 Thread Ondřej Surý

Hi,

just an ACK. I am aware of the transition and will make necessary
steps to fix PHP 5.4 when apache 2.4 reaches unstable (php5_5.4.1~rc1
already includes upstream support for Apache 2.4).

Heads up on the upload to unstable would be nice, but not mandatory.

O.

On Sun, Apr 1, 2012 at 23:15,  a...@debian.org wrote:
 Package: php5
 Severity: important
 User: debian-apache@lists.debian.org
 Usertags: apache24transition

 Dear maintainer,

 your package php5 is provding an Apache2 web server module.
 We're upgrading Apache to the new upstream version 2.4 [1] (tracked
 as transition bug #661958). This requires all modules to be rebuilt
 due to ABI changes.  Thus, you need to rebuild and reupload your
 Apache2 module package in a version compatible to our new package
 available in experimental [2].  Please note it is not enough to
 simply rebuild the module - it needs some adaptions in the module
 package metadata. We have written packaging guidelines for our
 reverse dependencies [3]. Please read it carefully, it should be able
 to answer most of your questions. Do also look at dh_apache2
 (available through the dh-apache2 package) which can simplify
 packaging Apache2 modules.  In short, we want to highlight these
 changes you need to be aware of.

 * APIs changed for some cases [3]. Chances are your module needs some
  adaptions, please get in touch with upstream or us if you need help
  to port your module to Apache 2.4.

 * MPM packages are gone. You cannot depend or conflict with a
  particular MPM anymore. If your module does not work with a
  particular module, make sure to make it abort with an error if
  loaded together with an incompatible MPM. You can use our
  apache2-maintscript-helper [4] to switch to the MPM of your choice
  in your maintainer scripts.

 * Do not build-depend on apache2-threaded-dev or apache2-prefork-dev
  anymore. Just like MPMs are gone, are our MPM -dev packages as
  well. All modules need to simply build-depend on apache2-dev.

 * Do NOT depend on apache2, apache2-common or any other real apache2
  package in your binary module package. Depend on our virtual
  apache2-api-20120211 package only!

 * Do NOT call a2enmod/a2dismod in your maintainer scripts. Use our
  apache2-maintscript-helper [3] instead. This is required to get a
  uniform and stateful handling of all Apache2 modules.


 You can look at our Apache 2.4 packaging hints [5] for hands-on
 tutorials.  Please note: This bug is filed as important for now. As
 the time goes by we plan make it a release critical severity. In the
 consequences your module either needs an update or is going to be
 removed from Wheezy. For the time being please tag the bug as pending
 as soon as you have a package ready. We strongly recommend that at
 least maintainers of complex module packages make an upload to
 experimental as well. Of course, uploading simple modules to
 experimental is welcome, too.

 [1] https://lists.debian.org/debian-devel-announce/2012/03/msg00013.html
 [2] 
 http://packages.debian.org/search?keywords=apache2searchon=sourcenamesexact=1suite=allsection=all
 [3] 
 http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git;a=blob;f=debian/PACKAGING;hb=next
 [4] http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html
 [5] http://wiki.debian.org/Apache/PackagingFor24





 ___
 pkg-php-maint mailing list
 pkg-php-ma...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-maint



-- 
Ondřej Surý ond...@sury.org


--
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CALjhHG9bbBb=n=bkghnpk0t1g2ggfwordfohs7msxh4xi0v...@mail.gmail.com

Bug#621366: Still uses libdb4.8

2011-04-06 Thread Ondřej Surý

Package: apr-util
Version: 1.3.9+dfsg-5
Severity: normal
User: pkg-db-de...@lists.alioth.debian.org
Usertags: db5.1

Your package currently still uses Berkeley DB version 4.8 (libdb4.8).

However, there is a newer Berkeley DB version in the archive (libdb5.1),
with a compatible API.  Berkeley DB version 4.8 will be eventually
removed from unstable in favor of version 5.1.

Please port your package to libdb5.1 as soon as possible.  In most cases
only change required is to update build depends from libdb4.8-dev
to libdb-dev, or just recompile the package.

More complicated scenarios:

- Package does check for DB_VERSION_MAJOR == 4 - this should be updated
  to (DB_VERSION_MAJOR  4) || ((DB_VERSION_MAJOR == 4)  (DB_VERSION_MINOR = 
XX)).

- Configure checks - sometime there is a list of db-4.8 db-4.6 db-4.2, etc., 
this
  needs to be updated to just db (or db-5.1 db-5 db), or at least list the 'db'
  in the front

You can see example patch in cyrus-imapd-2.2:
http://git.debian.org/?p=pkg-cyrus-imapd/cyrus-imapd-2.2.git;a=blob;f=debian/patches/99-berkelydb-5.1.dpatch;hb=HEAD

- The packages which use Berkeley DB transactional mode need to upgrade
  the database files before the upgrade.  This is fairly straightforward
  and is well documented on the Berkeley DB website.  But you probably
  already know that because it's not the first Berkeley DB transition.

The example script can be found in the cyrus-imapd-2.4 (not yet released):
http://git.debian.org/?p=pkg-cyrus-imapd/cyrus-imapd-2.4.git;a=blob;f=debian/cyrus-upgrade-db;hb=HEAD

Thanks, 
--
Ondřej Surý ond...@debian.org

-- System Information:
Debian Release: squeeze/sid
  APT prefers maverick-updates
  APT policy: (500, 'maverick-updates'), (500, 'maverick-security'), (500, 
'maverick-proposed'), (500, 'maverick-backports'), (500, 'maverick')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.35-28-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



--
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110406205711.7745.31849.reportbug@localhost6.localdomain6

Re: [php-maint] Bug#619036: php5: Build-Depends uninstallable

2011-03-21 Thread Ondřej Surý

On Sun, Mar 20, 2011 at 19:41, Raphael Geissert geiss...@debian.org wrote:
 On Sunday 20 March 2011 11:15:54 Kurt Roeckx wrote:
 Your build-depends are uninstallable because you build-depend on
 libdb-dev, which depends on libdb5.1-dev, and apache2-prefork-dev
 which depends on libaprutil1-dev, which depends on libdb4.8-dev.

 And libdb5.1-dev and libdb4.8-dev of course conflict with each
 other.

 For apache: Stefan et al,
 Do you have any objection to switch to libdb5.1-dev (and bd on libdb-dev)?

Meanwhile I will upload php5 5.3.6-2 build-depending on libdb4.8-dev
and we will have to coordinate the next switch with apache2 I guess.

 Based on a few tests via php, databases from 4.8 and 5.1 seem to be
 compatible.

This seems to be true for even longer chain of releases from what I
remember from cyrus-imapd tests.

 In the long term, something needs to be decided and done. The former
 maintainer of db uploaded the latest version and orphaned the packages.

I guess if we create pkg-db group it could be handled quite
gracefully, I might be willing to join that group, because I maintain
quite some packages depending on db and if we can get somebody from
apache2, ldap and subversion, we would have quite strong team.

Ondrej
-- 
Ondřej Surý ond...@sury.org


--
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/AANLkTikwGJvU4xe7n4xXCysKQ7i6y31Mtct=vkf8x...@mail.gmail.com

Bug#578754: apache2-mpm-prefork: child exit signal Segmentation fault (11)

2010-04-22 Thread Ondřej Surý

/buildd/php5-5.2.6.dfsg.1/Zend/zend_vm_execute.h:92
 #33901 0xb725e8c6 in zend_do_fcall_common_helper_SPEC 
 (execute_data=0xbfffb5fc) at 
 /tmp/buildd/php5-5.2.6.dfsg.1/Zend/zend_vm_execute.h:234
 #33902 0xb724a490 in execute (op_array=0x8665dfc) at 
 /tmp/buildd/php5-5.2.6.dfsg.1/Zend/zend_vm_execute.h:92
 #33903 0xb725e8c6 in zend_do_fcall_common_helper_SPEC 
 (execute_data=0xbfffb79c) at 
 /tmp/buildd/php5-5.2.6.dfsg.1/Zend/zend_vm_execute.h:234
 #33904 0xb724a490 in execute (op_array=0x8665a4c) at 
 /tmp/buildd/php5-5.2.6.dfsg.1/Zend/zend_vm_execute.h:92
 #33905 0xb725e8c6 in zend_do_fcall_common_helper_SPEC 
 (execute_data=0xbfffb96c) at 
 /tmp/buildd/php5-5.2.6.dfsg.1/Zend/zend_vm_execute.h:234
 #33906 0xb724a490 in execute (op_array=0x8662f30) at 
 /tmp/buildd/php5-5.2.6.dfsg.1/Zend/zend_vm_execute.h:92
 #33907 0xb725e8c6 in zend_do_fcall_common_helper_SPEC 
 (execute_data=0xbfffbb0c) at 
 /tmp/buildd/php5-5.2.6.dfsg.1/Zend/zend_vm_execute.h:234
 #33908 0xb724a490 in execute (op_array=0x8662b20) at 
 /tmp/buildd/php5-5.2.6.dfsg.1/Zend/zend_vm_execute.h:92
 #33909 0xb725e8c6 in zend_do_fcall_common_helper_SPEC 
 (execute_data=0xbfffbefc) at 
 /tmp/buildd/php5-5.2.6.dfsg.1/Zend/zend_vm_execute.h:234
 #33910 0xb724a490 in execute (op_array=0x864fd34) at 
 /tmp/buildd/php5-5.2.6.dfsg.1/Zend/zend_vm_execute.h:92
 #33911 0xb725e8c6 in zend_do_fcall_common_helper_SPEC 
 (execute_data=0xbfffc11c) at 
 /tmp/buildd/php5-5.2.6.dfsg.1/Zend/zend_vm_execute.h:234
 #33912 0xb724a490 in execute (op_array=0x864edb8) at 
 /tmp/buildd/php5-5.2.6.dfsg.1/Zend/zend_vm_execute.h:92
 #33913 0xb7224bd0 in zend_execute_scripts (type=8, retval=0x0, file_count=3) 
 at /tmp/buildd/php5-5.2.6.dfsg.1/Zend/zend.c:1215
 #33914 0xb71daaf3 in php_execute_script (primary_file=0xbfffe3d8) at 
 /tmp/buildd/php5-5.2.6.dfsg.1/main/main.c:2028
 #33915 0xb729ccc0 in php_handler (r=0x8695a18) at 
 /tmp/buildd/php5-5.2.6.dfsg.1/sapi/apache2handler/sapi_apache2.c:648
 #33916 0x0807a1c9 in ap_run_handler (r=0x8695a18) at 
 /tmp/buildd/apache2-2.2.9/server/config.c:159
 #33917 0x0807d5e1 in ap_invoke_handler (r=0x8695a18) at 
 /tmp/buildd/apache2-2.2.9/server/config.c:373
 #33918 0x0808af00 in ap_internal_redirect (new_uri=0x86959d0 
 /index.php?OTSESSID=9bd9a4fd553d5d1e462fa6bc23fe79ba/1/frmCatID/155/, 
 r=0x868cdc8)
    at /tmp/buildd/apache2-2.2.9/modules/http/http_request.c:477
 #33919 0xb6e156c3 in handler_redirect (r=0x868cdc8) at 
 /tmp/buildd/apache2-2.2.9/modules/mappers/mod_rewrite.c:4829
 #33920 0x0807a1c9 in ap_run_handler (r=0x868cdc8) at 
 /tmp/buildd/apache2-2.2.9/server/config.c:159
 #33921 0x0807d5e1 in ap_invoke_handler (r=0x868cdc8) at 
 /tmp/buildd/apache2-2.2.9/server/config.c:373
 #33922 0x0808b0a6 in ap_process_request (r=0x868cdc8) at 
 /tmp/buildd/apache2-2.2.9/modules/http/http_request.c:258
 #33923 0x080881d8 in ap_process_http_connection (c=0x8686d50) at 
 /tmp/buildd/apache2-2.2.9/modules/http/http_core.c:190
 #33924 0x080815f9 in ap_run_process_connection (c=0x8686d50) at 
 /tmp/buildd/apache2-2.2.9/server/connection.c:43
 #33925 0x0808fcd4 in child_main (child_num_arg=value optimized out) at 
 /tmp/buildd/apache2-2.2.9/server/mpm/prefork/prefork.c:680
 #33926 0x080900b3 in make_child (s=0x80ac908, slot=1) at 
 /tmp/buildd/apache2-2.2.9/server/mpm/prefork/prefork.c:777
 #33927 0x0809073a in ap_mpm_run (_pconf=0x80a80c8, plog=0x80da190, 
 s=0x80ac908) at /tmp/buildd/apache2-2.2.9/server/mpm/prefork/prefork.c:795
 #33928 0x08066f10 in main (argc=Cannot access memory at address 0x0
 ) at /tmp/buildd/apache2-2.2.9/server/main.c:732
 (gdb) quit


 -- Package-specific info:
 List of /etc/apache2/mods-enabled/*.load:
  alias auth_basic authn_file authz_default authz_groupfile
  authz_host authz_user autoindex cgi deflate dir env info mime
  mod-security negotiation php5 setenvif ssl status unique_id

 -- System Information:
 Debian Release: 5.0.4
  APT prefers stable
  APT policy: (500, 'stable')
 Architecture: i386 (i686)

 Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core)
 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/bash

 Versions of packages apache2-mpm-prefork depends on:
 ii  apache2.2-common    2.2.9-10+lenny7      Apache HTTP Server common files
 ii  libapr1             1.2.12-5+lenny1      The Apache Portable Runtime 
 Librar
 ii  libaprutil1         1.2.12+dfsg-8+lenny4 The Apache Portable Runtime 
 Utilit
 ii  libc6               2.7-18lenny2         GNU C Library: Shared libraries
 ii  libpcre3            7.6-2.1              Perl 5 Compatible Regular 
 Expressi

 apache2-mpm-prefork recommends no packages.

 apache2-mpm-prefork suggests no packages.

 -- no debconf information







-- 
Ondřej Surý ond...@sury.org
http://blog.rfc1925.org/



--
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/w2w3221680d1004220714z37d88356kb3cd8f68c36fb

Bug#578754: apache2-mpm-prefork: child exit signal Segmentation fault (11)

2010-04-22 Thread Ondřej Surý

      The Apache Portable Runtime 
 Librar
 ii  libaprutil1         1.2.12+dfsg-8+lenny4 The Apache Portable Runtime 
 Utilit
 ii  libc6               2.7-18lenny2         GNU C Library: Shared libraries
 ii  libpcre3            7.6-2.1              Perl 5 Compatible Regular 
 Expressi

 apache2-mpm-prefork recommends no packages.

 apache2-mpm-prefork suggests no packages.

 -- no debconf information







 --
 ???Ond??ej Surý ond...@sury.org
 http://blog.rfc1925.org/






-- 
Ondřej Surý ond...@sury.org
http://blog.rfc1925.org/



--
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/j2s3221680d1004220750i4b5390aapaea2a7be7123b...@mail.gmail.com

Bug#517126: closed by Ondřej Surý ond...@sury.org (Re: Bug#517126: apache2: PHP (5) support cannot be installed)

2009-02-25 Thread Ondřej Surý

On Wed, Feb 25, 2009 at 21:24,  a...@users.sourceforge.net wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi, Ondřej,

 Thank you for pointing this out and my apologies. I thought aptitude
 search would be
 about the same as apt-cache search but I was wrong. I'll revert to doing
 my searches
 with apt-cache.

Never used aptitude, so don't know why the results differ, but maybe you
should ask aptitude developers? Or if the behaviour differs from what is
documented in aptitute docs (man page), you should fill a bugreport.

 Can you give me any advice on who to turn to concerning Java
 and G Numeric code not working any more?

Fill a bug report against those packages with details of your problems.

 Sorry for bothering you and thank you for your quick reaction.

np, this is cca fourth bug report about apache 1.x and php5 ;),
and there has been(maybe still is) bug in the release notes.

Ondrej

 Axel
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (GNU/Linux)
 Comment: Made with pgp4pine 1.76

 iEYEARECAAYFAkmlqQcACgkQMiDYPOQNapFKFwCeI2ngQJ9O+Lqbxv18LNRjOMhJ
 Y5EAoLgyqssn2yxh9Om7FypUjDpsUU5Z
 =8ldG
 -END PGP SIGNATURE-




-- 
Ondřej Surý ond...@sury.org



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

Bug#397405: apache2-mpm-prefork: child seg-faults on access

2006-11-07 Thread Ondřej Surý

Isn't this related to #397402, ie. update of php4?

 after upgrading today, apache 2.2.3-3 is not working: on access, the
 child returns a segmentation fault:
 
 [Tue Nov 07 08:24:22 2006] [notice] child pid 17033 exit signal \
 Segmentation fault (11)]
 
 Any idea on how I can fix that?

Try downgrading php4 to php4-4.4.4~4 and let us know if it helps.

Ondrej.
-- 
Ondřej Surý [EMAIL PROTECTED]

Bug#397265: closed by Thom May [EMAIL PROTECTED] (LFS works fine)

2006-11-06 Thread Ondřej Surý

Peter Samuelson píše v Po 06. 11. 2006 v 13:48 -0600:
 [britneyfreek]
  then please tell me what's wrong on my side?
  i got the original debian packages.
  
  why does stat() and filesize() and some other fail on files larger 2gb?
 
 They don't fail for us.
 
 Can you provide more information about what you are doing and how you
 determined that stat() and filesize() are failing?

My wild guess would be that they are using php4/5.  And php4 got LFS
support with 4.4.4-5 and php5 is getting to be compiled with LFS for
5.2.0-1 which will be uploaded this evening if everything will be ok.

Ondrej.
-- 
Ondřej Surý [EMAIL PROTECTED]

Bug#388805: RFP: please package mod_auth_xradius

2006-09-22 Thread Ondřej Surý

retitle 388805 RFP: please package mod_auth_xradius
reassign 388805 wnpp
severity 388805 wishlist
thank you

You have filled bug at wrong package. Apache 2.X doesn't contain module
for radius auth.  However I was able to find mod_auth_xradius, so I am
changing your bug to RFP (Request For Package) and reassigning it to our
WNPP database.


mod_auth_xradius provides high performance authentication against 
RFC 2865 RADIUS Servers.

Features
*Supports popular RADIUS Servers including 
 OpenRADIUS, FreeRADIUS and commercial servers.
*Distributed Authentication Cache using apr_memcache.
*Local Authentication Cache using DBM.
*Uses standard HTTP Basic Authentication, unlike 
 mod_auth_radius which uses cookies for sessions.

Kind regards,
-- 
Ondřej Surý [EMAIL PROTECTED]

45 matches

Mail list logo