On 2023/06/29 19:55:52 +0200, Florian Obser wrote:
> I'm worried that we pass un-sanitized input through to fcgi.
> Of course we are passing *a lot* of un-sanitized input through to fcgi,
> so does this matter in the grand scheme of things?
> But I'd like if server_http_parsehost() enforces syntac
On Wed, Jun 07, 2023 at 04:00:43PM +0200, Florian Obser wrote:
> tests, OKs?
The diff is not going to get better by maturing on the list. If no one
tests voluntarily, they will have to. I looked over it and nothing really
shocked me.
ok tb
On 2023-06-19 18:27 +02, Omar Polo wrote:
> currently httpd uses the name specified in the config `server' block
> which is not guaranteed to be a valid hostname.
>
> quoting rfc3875:
>
>The SERVER_NAME variable MUST be set to the name of the server host
>to which the client request is dir
> > > - if ((new = reallocarray(comm->communities, newsize,
> > > - sizeof(struct community))) == NULL)
> > > + if ((new = recallocarray(comm->communities, comm->size,
> > > + newsize, sizeof(struct community))) == NULL)
> > > fatal(__func__
On Thu, Jun 29, 2023 at 06:25:01PM +0200, Theo Buehler wrote:
> On Tue, Jun 27, 2023 at 12:10:21PM +0200, Claudio Jeker wrote:
> > Sorry this diff is a monster but it kind of turned into a all or nothing
> > situation.
>
> Frankly, it's not that bad.
>
> > For a long time bgpd used a static 4k bu
On Tue, Jun 27, 2023 at 12:10:21PM +0200, Claudio Jeker wrote:
> Sorry this diff is a monster but it kind of turned into a all or nothing
> situation.
Frankly, it's not that bad.
> For a long time bgpd used a static 4k buffer plus a len argument to build
> updates. The result was ok but was also
On 2023-06-29 15:03 +02, Claudio Jeker wrote:
> Once again struct sockaddr_in6 causes 64bit systems to cry. This time in
> relayd. You can not statically setup a route message and think it will
> work. All our routing daemons switched to iov for building the route
> message out of various componen
On Thu, Jun 29, 2023 at 03:03:12PM +0200, Claudio Jeker wrote:
> Once again struct sockaddr_in6 causes 64bit systems to cry. This time in
> relayd. You can not statically setup a route message and think it will
> work. All our routing daemons switched to iov for building the route
> message out of
On Thu, Jun 29, 2023 at 04:16:32PM +0200, Theo Buehler wrote:
> A thinko slipped through review in aspa.c which broke the ASPA counters.
> Use only one counter and call it STYPE_PROVIDERS.
>
> Is it ok to switch from "both" to "valid" in output-ometric.c for
> consistency with the other products o
A thinko slipped through review in aspa.c which broke the ASPA counters.
Use only one counter and call it STYPE_PROVIDERS.
Is it ok to switch from "both" to "valid" in output-ometric.c for
consistency with the other products or do we need to maintain compat for
some parsers?
output before and aft
Once again struct sockaddr_in6 causes 64bit systems to cry. This time in
relayd. You can not statically setup a route message and think it will
work. All our routing daemons switched to iov for building the route
message out of various components. This diff does the same for relayd.
With this it is
On Thu, Jun 29, 2023 at 09:12:06AM +, Job Snijders wrote:
> On Thu, Jun 29, 2023 at 09:30:19AM +0200, Theo Buehler wrote:
> > I wrote versions of this diff several times in the past but never sent
> > it out. A question by claudio encouraged me...
> >
> > cryptowarnx() and cryptoerrx() fail at
On Thu, Jun 29, 2023 at 09:30:19AM +0200, Theo Buehler wrote:
> I wrote versions of this diff several times in the past but never sent
> it out. A question by claudio encouraged me...
>
> cryptowarnx() and cryptoerrx() fail at showing openssl error stacks
> in a pleasant way as no amount of lipsti
I wrote versions of this diff several times in the past but never sent
it out. A question by claudio encouraged me...
cryptowarnx() and cryptoerrx() fail at showing openssl error stacks
in a pleasant way as no amount of lipstick can make this pig pretty.
I don't think these stacks should be shown
14 matches
Mail list logo
