Re: httpd: patch for portability asprintf use

On Fri, May 06, 2016 at 06:48:38PM +0200, Reyk Floeter wrote: > > > On 06.05.2016, at 18:36, Theo de Raadt wrote: > > > >> If OpenBSD's behavior of asprintf is non-standard and everyone else is > >> doing it differently, we would probably have to apply the patch. But this > >> would also affect

Re: httpd: patch for portability asprintf use

On Fri, 06 May 2016 18:53:28 +0200, Hiltjo Posthuma wrote: > It is not an issue, but I thought it was not intended because the > asprintf(3) documentation said: > > "The value of ret in this situation is > implementation-dependent (on OpenBSD, ret will be set to the null >

Re: httpd: patch for portability asprintf use

Theo de Raadt wrote: > > If OpenBSD's behavior of asprintf is non-standard and everyone else is > > doing it differently, we would probably have to apply the patch. But this > > would also affect many other places in the tree were we rely on our > > asprintf semantics. > > Actually, we have fixed

Re: httpd: patch for portability asprintf use

> Theo de Raadt wrote: > > > If OpenBSD's behavior of asprintf is non-standard and everyone else is > > > doing it differently, we would probably have to apply the patch. But this > > > would also affect many other places in the tree were we rely on our > > > asprintf semantics. > > > > Actually,

Re: httpd: patch for portability asprintf use

On Fri, May 6, 2016 at 6:47 PM, Todd C. Miller wrote: > On Fri, 06 May 2016 17:56:16 +0200, Hiltjo Posthuma wrote: > >> Any OK's for this? >> >> Please also see my mail with subject "httpd: fix/style: unbalanced >> va_start and va_end macros" (don't want to spam the mailinglist :)). > > I didn't c

Re: httpd: patch for portability asprintf use

> On 06.05.2016, at 18:36, Theo de Raadt wrote: > >> If OpenBSD's behavior of asprintf is non-standard and everyone else is >> doing it differently, we would probably have to apply the patch. But this >> would also affect many other places in the tree were we rely on our >> asprintf semantics. >

Re: httpd: patch for portability asprintf use

On Fri, 06 May 2016 17:56:16 +0200, Hiltjo Posthuma wrote: > Any OK's for this? > > Please also see my mail with subject "httpd: fix/style: unbalanced > va_start and va_end macros" (don't want to spam the mailinglist :)). I didn't change those before because body and hstsheader are initialized t

Re: httpd: patch for portability asprintf use

> If OpenBSD's behavior of asprintf is non-standard and everyone else is > doing it differently, we would probably have to apply the patch. But this > would also affect many other places in the tree were we rely on our > asprintf semantics. Actually, we have fixed all usage cases in our tree to be

Re: httpd: patch for portability asprintf use

> On 06.05.2016, at 17:56, Hiltjo Posthuma wrote: > > On Wed, Apr 27, 2016 at 2:41 PM, Hiltjo Posthuma > wrote: >> Hi, >> >> The following patch for httpd makes sure the value of the asprintf buffer is >> zeroed on error and not relied upon, so at the 'done' labe

Re: httpd: patch for portability asprintf use

On Wed, Apr 27, 2016 at 2:41 PM, Hiltjo Posthuma wrote: > Hi, > > The following patch for httpd makes sure the value of the asprintf buffer is > zeroed on error and not relied upon, so at the 'done' label free(body) and > free(hstsheader) is safe. > > from asprintf(3): > > "The asprintf()

httpd: patch for portability asprintf use

Hi, The following patch for httpd makes sure the value of the asprintf buffer is zeroed on error and not relied upon, so at the 'done' label free(body) and free(hstsheader) is safe. from asprintf(3): "The asprintf() and vasprintf() functions return the number of characters that

Re: httpd patch

On Sat, Jan 16, 2016 at 04:35:16AM +, Peter J. Philipp wrote: > Hello again, > > I couldn't sleep because for some reason my head was spinning around this > code. In sleep I reviewed what I remembered of this code and noticed two > things. > > 1. My patch was against 5.8 not -current, so i

Re: httpd patch

On Fri, Jan 15, 2016 at 08:36:05PM +, Peter J. Philipp wrote: > Hello, > > I had nothing better to do tonight after work so I read a little in httpd. > I have come up with a patch for i386 and any architecture where off_t != > size_t. > > So on i386 there is this: > > uranus$ ./sizetest > o

httpd patch

Hello, I had nothing better to do tonight after work so I read a little in httpd. I have come up with a patch for i386 and any architecture where off_t != size_t. So on i386 there is this: uranus$ ./sizetest off_t = 8 size_t = 4 and I have these files in a directory: uranus$ ls -lhi total 126

Re: httpd: patch to close TLS sockets that,fail before TLS handshake

Good enough for me. Thanks On 08/27/15 08:42, Joel Sing wrote: On Tuesday 25 August 2015 19:19:58 Edgar Pettijohn wrote: I was curious if this issue is fixed in -current or if there is going to be a patch available on the errata page? Yes, this is fixed in -current (and will be in 5.8) - see

Re: httpd: patch to close TLS sockets that,fail before TLS handshake

On Tuesday 25 August 2015 19:19:58 Edgar Pettijohn wrote: > I was curious if this issue is fixed in -current or if there is going to > be a patch available on the errata page? Yes, this is fixed in -current (and will be in 5.8) - see r1.68 of server.c. There may be back ports/commits of various h

Re: httpd: patch to close TLS sockets that,fail before TLS handshake

I was curious if this issue is fixed in -current or if there is going to be a patch available on the errata page? Thanks Edgar

Re: httpd: patch to close TLS sockets that fail before TLS handshake

On Wednesday 15 July 2015 23:38:33 Jack Burton wrote: > In 5.7-stable & -current, httpd, when listening for TLS, does not close > the client socket when tls_accept_socket() returns any non-recoverable > error. The problem manifests most often when a client connects but does > not attempt TLS handsh

Re: httpd: patch to close TLS sockets that fail before TLS handshake

On Wed, 2015-07-15 at 23:38 +0930, Jack Burton wrote: > Sorry, I don't have any hosts running -current at the moment, but I've > written a trivial patch against 5.7-stable to treat that particular > failure mode in the same way as was already being done for EV_TIMEOUTs. > That fixes the issue for

httpd: patch to close TLS sockets that fail before TLS handshake

In 5.7-stable & -current, httpd, when listening for TLS, does not close the client socket when tls_accept_socket() returns any non-recoverable error. The problem manifests most often when a client connects but does not attempt TLS handshake. Steps to reproduce: * Configure httpd to listen for TLS