Re: Wheezy update of apache2?
Hi there, Am 17.07.2017 um 22:50 schrieb Chris Lamb: > Hi Stefan, > >> Note that a previous DLSA introduced a regression. It would be nice if >> you could take a look at that, too: >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858373 > > Unfortunately I uploaded this morning before I saw your note about > this regression. > > I've added anarcat and mejo to CC as they are mentioned in the > apache2 2.2.22-13+deb7u8 upload; could one of you take care of it? Unfortunately I'm on holidays with bad internet connectivity until August 5th. Will not find time to look into the regression earlier. Also, I just did further debugging and a final fix to the deb7u8 upload. I remember that backporting the CVE-2016-8743 fix to 2.2.22 very intrusive and complex. Kind regards, jonas signature.asc Description: OpenPGP digital signature
Re: testing and review requested for Wheezy update of apache2
Am 23.02.2017 um 11:59 schrieb Guido Günther: > On Wed, Feb 22, 2017 at 06:54:46PM +0100, Jonas Meurer wrote: >> Am 22.02.2017 um 18:46 schrieb Guido Günther: >>> Hi Jonas, >>> On Wed, Feb 22, 2017 at 05:28:46PM +0100, Jonas Meurer wrote: >>>> This time with the debdiff between Antoine's version and mine. >>> Are there packages available for testing? I could give it another whirl. >> >> Sorry, yes you can find them at >> https://people.debian.org/~mejo/wheezy-lts/ > > Thanks I tested these with several combinations of HttpProtocolOptions > on a apache serving pages directly and in reverse proxy mode with no > noticed ill effects. All right, then we should go for the update. Antoine, do you take care of it? Cheers, jonas signature.asc Description: OpenPGP digital signature
Re: testing and review requested for Wheezy update of apache2
Am 22.02.2017 um 18:46 schrieb Guido Günther: > Hi Jonas, > On Wed, Feb 22, 2017 at 05:28:46PM +0100, Jonas Meurer wrote: >> This time with the debdiff between Antoine's version and mine. > Are there packages available for testing? I could give it another whirl. Sorry, yes you can find them at https://people.debian.org/~mejo/wheezy-lts/ Cheers, jonas signature.asc Description: OpenPGP digital signature
Re: testing and review requested for Wheezy update of apache2
This time with the debdiff between Antoine's version and mine. Cheers, jonas Am 22.02.2017 um 17:23 schrieb Jonas Meurer: > Hi Antoine, hi LTS list, > > first, thanks to Antoine for doing the backport. After digging into the > details myself I quite understand why he requested a second (and ideally > a third) opinion! > > Am 20.02.2017 um 21:27 schrieb Antoine Beaupré: >> With a fresh mind (and 30 days delay!) I am looking at this again... > > as discussed with Antoine on IRC, I looked into this during the last two > days ... > >>>> 2: [ "GET / HTTP/1.0\n\n" => 400], >>>> 8: [ "GET / HTTP/1.0\0\r\n\r\n"=> 400], >>>> 26: [ "GET / HTTP/1.0\r\nFoo: b\0ar\r\n\r\n"=> 400], >>>> >>>> #2 is weird - it just returns nothing now: >>>> >>>> $ printf "GET / HTTP/1.0\n\n" | nc localhost 80 >>>> $ >>> >>> This works better in 2.4.10 with the backport and in 2.4.25: There, >>> >>> printf "GET / HTTP/1.0\n\n" | nc localhost 80 >>> >>> gives a 400 Bad request, as expected. >> >> Hm... I tried the packages I uploaded last month to people.d.o, and they >> do not fail those tests anymore. At least, >> >> # printf "GET / HTTP/1.0\n\n" | nc localhost 80 >> HTTP/1.1 400 Bad Request >> # printf "GET / HTTP/1.0\r\nFoo: b\0ar\r\n\r\n" | nc localhost 80 >> HTTP/1.1 400 Bad Request >> # printf "GET / HTTP/1.0\0\r\n\r\n" | nc localhost 80 >> HTTP/1.1 400 Bad Request >> >> This all looks good... > > Unfortunately not that good ... > > "GET / HTTP/1.0\0\r\n\r\n" is a valid request and apparently pretty > similar to what most web browsers do (except that they do send more > headers). > > While doing a basic smoke test I discovered that requests from firefox > and wget both got a "400 Bad Request" response, which isn't the expected > behaviour. > > The following debug log lines confirmed that there's something broken: > > [debug] protocol.c(959): [client 127.0.0.1] (22)Invalid argument: Failed > to read request header line > [debug] protocol.c(1302): [client 127.0.0.1] request failed: error > reading the headers > > Apparently, the last empty line triggered the error while it should not > do so. > > So I started digging into the code and finally found out that the > following patch was missing in Antoine's packages: > https://svn.apache.org/viewvc?view=revision=1775232 > > It's a bit mean as the patch got applied to the httpd 2.2 branch way > earlier than the CVE-2016-8743 related patches. Seems like the bug just > wasn't triggered until the CVE-2016-8743 related patches came in. > > After applying the patch (attached), the basic things worked as expected: > >>> Have you tried if that diff helps with >>> >>> printf "GET / HTTP/1.0\n\n" | nc localhost 80 >>> >>> returning nothing? I don't see how the change would help, but I haven't >>> tried >>> it or looked at the code in total. >> >> Well, it's rather strange but things all seem to work here.. .The above >> now returns the 400 error as expected. > > Looks better now: > > (request and corresponding error log) > > $ printf "GET / HTTP/1.0\n\n" | nc localhost 80 > HTTP/1.1 400 Bad Request > > [debug] protocol.c(1258): [client 127.0.0.1] request failed: malformed > request line > > $ printf "GET / HTTP/1.0\r\nFoo: b\0ar\r\n\r\n" | nc localhost 80 > HTTP/1.1 400 Bad Request > > [debug] protocol.c(953): [client 127.0.0.1] (22)Invalid argument: Failed > to read request header line Foo: b > [debug] protocol.c(1296): [client 127.0.0.1] request failed: error > reading the headers > > $ printf "GET / HTTP/1.0\r\n\r\n" | nc localhost 80 > HTTP/1.1 200 OK > > [no error log, valid request] > >>>> It does mean that "echo GET / | nc localhost 80" now fails, but that >>>> seems to be the design of the Apache team, unfortunately. :( No more >>>> "telnet into port 80" it seems? >>> >>> Note that telnet does LF -> CRLF conversion, so telnet still works for >>> debugging. But nc does not. >> >> That should be acceptable. I am not sure it does it correctly, however: >> >> # printf "GET / HTTP/1.0\r\n\r\n" | nc localhost 80 >> HTTP/1.1 400 Bad Request >> >> That doesn't look right, actually - shouldn't this return a 200
Re: testing and review requested for Wheezy update of apache2
Hi Antoine, hi LTS list, first, thanks to Antoine for doing the backport. After digging into the details myself I quite understand why he requested a second (and ideally a third) opinion! Am 20.02.2017 um 21:27 schrieb Antoine Beaupré: > With a fresh mind (and 30 days delay!) I am looking at this again... as discussed with Antoine on IRC, I looked into this during the last two days ... >>> 2: [ "GET / HTTP/1.0\n\n" => 400], >>> 8: [ "GET / HTTP/1.0\0\r\n\r\n"=> 400], >>> 26: [ "GET / HTTP/1.0\r\nFoo: b\0ar\r\n\r\n"=> 400], >>> >>> #2 is weird - it just returns nothing now: >>> >>> $ printf "GET / HTTP/1.0\n\n" | nc localhost 80 >>> $ >> >> This works better in 2.4.10 with the backport and in 2.4.25: There, >> >> printf "GET / HTTP/1.0\n\n" | nc localhost 80 >> >> gives a 400 Bad request, as expected. > > Hm... I tried the packages I uploaded last month to people.d.o, and they > do not fail those tests anymore. At least, > > # printf "GET / HTTP/1.0\n\n" | nc localhost 80 > HTTP/1.1 400 Bad Request > # printf "GET / HTTP/1.0\r\nFoo: b\0ar\r\n\r\n" | nc localhost 80 > HTTP/1.1 400 Bad Request > # printf "GET / HTTP/1.0\0\r\n\r\n" | nc localhost 80 > HTTP/1.1 400 Bad Request > > This all looks good... Unfortunately not that good ... "GET / HTTP/1.0\0\r\n\r\n" is a valid request and apparently pretty similar to what most web browsers do (except that they do send more headers). While doing a basic smoke test I discovered that requests from firefox and wget both got a "400 Bad Request" response, which isn't the expected behaviour. The following debug log lines confirmed that there's something broken: [debug] protocol.c(959): [client 127.0.0.1] (22)Invalid argument: Failed to read request header line [debug] protocol.c(1302): [client 127.0.0.1] request failed: error reading the headers Apparently, the last empty line triggered the error while it should not do so. So I started digging into the code and finally found out that the following patch was missing in Antoine's packages: https://svn.apache.org/viewvc?view=revision=1775232 It's a bit mean as the patch got applied to the httpd 2.2 branch way earlier than the CVE-2016-8743 related patches. Seems like the bug just wasn't triggered until the CVE-2016-8743 related patches came in. After applying the patch (attached), the basic things worked as expected: >> Have you tried if that diff helps with >> >> printf "GET / HTTP/1.0\n\n" | nc localhost 80 >> >> returning nothing? I don't see how the change would help, but I haven't >> tried >> it or looked at the code in total. > > Well, it's rather strange but things all seem to work here.. .The above > now returns the 400 error as expected. Looks better now: (request and corresponding error log) $ printf "GET / HTTP/1.0\n\n" | nc localhost 80 HTTP/1.1 400 Bad Request [debug] protocol.c(1258): [client 127.0.0.1] request failed: malformed request line $ printf "GET / HTTP/1.0\r\nFoo: b\0ar\r\n\r\n" | nc localhost 80 HTTP/1.1 400 Bad Request [debug] protocol.c(953): [client 127.0.0.1] (22)Invalid argument: Failed to read request header line Foo: b [debug] protocol.c(1296): [client 127.0.0.1] request failed: error reading the headers $ printf "GET / HTTP/1.0\r\n\r\n" | nc localhost 80 HTTP/1.1 200 OK [no error log, valid request] >>> It does mean that "echo GET / | nc localhost 80" now fails, but that >>> seems to be the design of the Apache team, unfortunately. :( No more >>> "telnet into port 80" it seems? >> >> Note that telnet does LF -> CRLF conversion, so telnet still works for >> debugging. But nc does not. > > That should be acceptable. I am not sure it does it correctly, however: > > # printf "GET / HTTP/1.0\r\n\r\n" | nc localhost 80 > HTTP/1.1 400 Bad Request > > That doesn't look right, actually - shouldn't this return a 200? Yep, and it does now. Also a test with 'telnet localhost 80' worked as expected now. > # printf "GET /\r\n\r\n" | nc localhost 80 > > returns a correct 200, however. If I got the code right, that's because for protocol version HTTP/0.9, no header checks are done. >>> I am really wondering why we shouldn't just package 2.2.32 after >>> all. the change is kind of massive, but it would make me feel much >>> better than the current patch set: >>> >>> 136 files changed, 1738 insertions(+), 4409 deletions(-) >> >> I am not sure either. For 2.4.10/jessie the changes are a bit less >> intrusive >> and I intend to use the backported version: >> >> 9 files changed, 1064 insertions(+), 303 deletions(-) >> >> But for 2.2/wheezy it's a difficult decision. > > The problem with wheezy is that it would require reviewing years of > patches to see which one have been factored upstream: > > apache2-2.2.22$ diffstat debian/patches/* | tail -1 > 92 files changed, 3687 insertions(+), 1533 deletions(-) > > It's interesting that this is similar to the diff between the two > versions. ;) In other
Bug#489383: apache2.2-common: duplicated documentation lines in default-ssl virtualhost configuration
Package: apache2.2-common Version: 2.2.9-3 Severity: minor Hello, In /etc/apache2/sites-available/defalt-ssl, at documentation of the 'SSL Protocol Adjustments', the following lines are dublicated: # This forces an accurate shutdown when the connection is closed, i.e. a # SSL close notify alert is send and mod_ssl waits for the close notify # alert of the client. This is 100% SSL/TLS standard compliant, but in # This forces an accurate shutdown when the connection is closed, i.e. a greetings, jonas -- Package-specific info: List of enabled modules from 'apache2 -M': alias auth_basic authn_file authz_default authz_groupfile authz_host authz_user autoindex cgi dir env mime negotiation php5 rewrite setenvif status userdir -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-1-amd64-resivo (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages apache2.2-common depends on: ii apache2-utils 2.2.9-3 utility programs for webservers ii libapr11.2.12-4 The Apache Portable Runtime Librar ii libaprutil11.2.12+dfsg-7 The Apache Portable Runtime Utilit ii libc6 2.7-12GNU C Library: Shared libraries ii libmagic1 4.24-4File type determination library us ii libssl0.9.80.9.8g-10.1 SSL shared libraries ii lsb-base 3.2-12Linux Standard Base 3.2 init scrip ii mime-support 3.44-1MIME files 'mime.types' 'mailcap ii net-tools 1.60-19 The NET-3 networking toolkit ii perl 5.10.0-11 Larry Wall's Practical Extraction ii procps 1:3.2.7-8 /proc file system utilities ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime Versions of packages apache2.2-common recommends: ii ssl-cert 1.0.21 simple debconf wrapper for OpenSSL Versions of packages apache2.2-common is related to: pn apache2-mpm-event none (no description available) pn apache2-mpm-itk none (no description available) ii apache2-mpm-prefork 2.2.9-3Apache HTTP Server - traditional n pn apache2-mpm-workernone (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390794: apache2-mpm-prefork: /usr/sbin/apache2 not executable
Package: apache2-mpm-prefork Version: 2.2.3-1 Severity: grave Justification: renders package unusable hello, with the latest apache2-mpm-prefork upgrade, /usr/sbin/apache2 has become unexecutable. the permissions now are -rw-r--r--. /etc/init.d/apache2 therefore exites silently. ... jonas -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-amd64-resivo Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages apache2-mpm-prefork depends on: ii apache2.2-common2.2.3-1 Next generation, scalable, extenda ii libapr1 1.2.7-6 The Apache Portable Runtime Librar ii libaprutil1 1.2.7+dfsg-2 The Apache Portable Runtime Utilit ii libc6 2.3.6.ds1-5 GNU C Library: Shared libraries ii libdb4.34.3.29-6 Berkeley v4.3 Database Libraries [ ii libdb4.44.4.20-8 Berkeley v4.4 Database Libraries [ ii libexpat1 1.95.8-3.3 XML parsing C library - runtime li ii libldap22.1.30-13+b1 OpenLDAP libraries ii libpcre36.7-1Perl 5 Compatible Regular Expressi ii libpq4 8.1.4-7 PostgreSQL C client library ii libsqlite3-03.3.7-1 SQLite 3 shared library ii libuuid11.39-1.1 universally unique id library apache2-mpm-prefork recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
