TimWolla

The examples in TFA are terrible and I don't get why it was necessary to jump the gun by submitting that article instead of actually waiting for the release and the official release page with more carefully designed examples.

Given that the cat effectively is out of the bag, does the example on the release page (sneak preview) make more sense to you: https://www.php.net/releases/8.5/en.php#closures-in-const-ex...?

As a side note, even PHP's official wiki cannot highlight correctly the multiline attributes behind a "#"

Yes, unfortunately the off-the-shelf software of the Wiki uses a custom-built highlighter instead of the `highlight_string()` function that is bundled with PHP: https://www.php.net/manual/en/function.highlight-string.php

That image is over one year old: https://github.com/linuxcontainers/debian-slim/pkgs/containe...

Google Container Registry provides a pull-through mirror, though, just prefix `mirror.gcr.io` and use `library` as the user for the Docker Official Images. For example `mirror.gcr.io/library/redis` for https://hub.docker.com/_/redis.

Indeed. It might even result in out of range values due to implicit rounding (`3.5 + (4.5 - 3.5) * (the largest float smaller than 1)` results in 4.5, which is unexpected).

I'm a contributor to the PHP programming language and a maintainer of the randomness functionality and did some research into this topic to provide a floating point generation method that is as good as possible and came across the "Drawing Random Floating-point Numbers from an Interval" paper by Frédéric Goualard.

PHP 8.3 ships with a method generating random floats from arbitrary intervals based on the γ-section algorithm described in that paper. The PHP documentation goes into additional detail:

https://www.php.net/manual/en/random-randomizer.getfloat.php

As part of the implementation I also reached out to Prof. Goualard with some questions for clarification regarding the behavior for extreme values, which resulted in an Corrigendum being published, since the algorithm was buggy in those cases (https://frederic.goualard.net/publications/corrigendum.pdf). The entire exchange with Prof. Goualard was really pleasant.

For PHP 8.3, we upgraded production during the RC phase, but were prepared to revert back to an older one by not relying on the new functionality. Docker makes this easy.

As long as you do not use the new functionality, I'd claim that a new PHP version is no less stable than an older one. And on a contrary you would be missing out on some bugfixes that were deemed too risky to apply to an existing version.

Disclosure: I've got a commit-bit for PHP, so we had in-house expertise to diagnose issues ourselves.

It seems to be better to err on the side of 'people dont know if they want a PRNG or a CSPRNG' and switch the default to the latter with an explicit choice for the former for people that know what they need :)

That’s exactly what we did in PHP 8.2 [1] with the new object-oriented randomness API: If you as the developer don’t make an explicit choice for the random engine to use, you’ll get the CSPRNG.

Now unfortunately the hard part is convincing folks to migrate to the new API - or even from the global Mt19937 instance using mt_rand() to the CSPRNG using random_int() which is already available since 7.0.

[1] https://www.php.net/releases/8.2/en.php#random_extension

No:

    route:          5.44.240.0/21
    descr:          Zoner Oy
    origin:         AS201692
    mnt-by:         MNT-ZONER
    created:        2014-09-03T08:09:00Z
    last-modified:  2014-09-03T08:09:00Z
    source:         RIPE

I think I recall chatting with you on here or email, I can't remember which.

Could possibly also have been in the issue tracker, which I did help bootstrapping and doing maintenance for quite a while after initially setting it up. Luckily the core team has took over, since I had much less time for HAProxy contributions lately.

FYI: Serving static files is easier and more flexible in modern versions of HAProxy via the `http-request return` action [1]. No need to abuse error pages and no need to embed the header within the error file any longer :-) You even have some dynamic generation capabilities via the `lf-file` option, allowing you to embed e.g. the client IP address or request ID in responses.

[1] https://docs.haproxy.org/dev/configuration.html#4.4-return

Disclosure: I'm a community contributor to HAProxy.

I'm using nom to parse a simple access control DSL in https://github.com/wbbaddons/Tims-PackageServer/blob/master/.... You can see how it looks in the tests of the linked file.

The DSL supports comparison operators, '&&', '||' and nested expressions, while preventing mixing of '&&' and '||' without making precedence clear using parentheses. This DSL should fit 'non-trivial', but it still should be simple enough to easily understand it.

I don't believe this is necessarily true. Unless I'm misunderstand you, each of the possible variants of spelling out 32 hexadecimal characters could theoretically SHA-256 into the spelled-out hash + 1 (looping around at ff…ff).

I suspect you'd lose that money. Many of the recent GitHub outages were caused by database issues. Examples: https://github.blog/2023-05-03-github-availability-report-ap.... In fact last march they specifically mentioned “Database stability”: https://github.blog/2022-04-06-github-availability-report-ma...

Indeed. While I do maintain two of them, that maintenance is effectively equivalent to being an open source maintainer or open source contributor. I do not have any non-public knowledge about the Docker Official Images program. My interaction with the Docker Official Images program can be summed up as “my PRs to docker-library/official-images” (https://github.com/docker-library/official-images/pulls/TimW...) and the #docker-library IRC channel on Libera.Chat.

The images you mention (alpine, node, golang) are all so-called “Docker Official Images”. Those are all the ones without a slash as the namespace separator in them: https://hub.docker.com/search?q=&type=image&image_filter=off...

They are versioned and reviewed here: https://github.com/docker-library/official-images

I don't expect them to go away.

Disclosure: I maintain two of them (spiped, adminer).

Note: The hash in the SO question is not vulnerable, because it is too long. The issue exists specifically for hashes that both contain a `$` and are too short. The “too short” is necessary for the trailing NUL byte of the input to be copied into the output and thus to truncate early because of the `strlen()`.

I assume s/bit/not/. The checking function is “does the given password with the stored parameters hash to the same value as the stored hash”. Hash functions are deterministic.

So returning the original hash for a valid password is the success case.

Disclosure: I am not the author of the initial bug, but I investigated the issue together with another developer. I'm the author of the linked advisory and I've authored the commit that fixed the issue.

As the advisory states I don't know about the why, but I have a suspicion. PHP initially didn't implement BCrypt itself, but delegated to the system crypt, making the behavior of crypt() system-dependent. Now the PHP manual for crypt() showcases this example:

    crypt('rasmuslerdorf', '$2a$07$usesomesillystringforsalt$');

In fact such broken hashes appear to actually exist in the wild as showcased by this Stack Overflow question: https://stackoverflow.com/q/75519073/782822

but missed one of the three ways crypt can signal failure (returning the input unmodified)

Returning the input unmodified is not failure, but success. That's how you check that a password is valid without having a specialized API.

I've interpreted the "put out" in the initial comment as in "put out a fire" (i.e. mitigate), instead of "send out".

71M requests per second gives you about 14ns per request. WolframAlpha says that's about 4 times the latency of a L2 cache access and 0.8 times the latency of a Mutex lock / unlock: https://www.wolframalpha.com/input?i=1+second+%2F+71+million. So even if you have a massive amount of cores in that machine, you still don't really have much time to spend on a single request and a single mutex operation will exceed your budget.

For comparison: HAProxy was able to deal with 2M requests per second on a single machine in 2021: https://www.haproxy.com/de/blog/haproxy-forwards-over-2-mill... (Disclosure: I'm a HAProxy community contributor).

Personally I sync the emails in my Gmail account to my server at Hetzner using imapsync [1] every once in a while. The data on that server is backed up off-site at rsync.net using Borg. I'm intentionally not using Hetzner's storage boxes, because I want my backup to be entirely independent, e.g. if my Hetzner customer account is closed down for whatever reason.

[1] https://imapsync.lamiral.info/

Only this specific curly braces syntax, which is less powerful than the still-supported '{$foo}' variant: https://wiki.php.net/rfc/deprecate_dollar_brace_string_inter...

I do the same for my personal machine. It's acting as the router/gateway in front of several Docker containers (both HTTP and also other protocols, such as SMTP or IRC).

Disclosure: I'm a community contributor to HAProxy.

OpenSSL 3 is in Ubuntu 22.04 LTS [1]. I expect that alone to be bad enough.

[1] https://discourse.ubuntu.com/t/jammy-jellyfish-release-notes...

When I need DNS I know 8.8.8.8 just works.

I've never had the need to know the IP address of a DNS resolver from the top of my head. Either the IP address of a working DNS resolver is provided by DHCP or I just install a local caching resolver that recurses itself (e.g. unbound).

When reading along: Keep in mind that I'm not a core developer and thus are not directly involved in development, design decisions, or roadmap. I have some understanding of the internals and the associated challenges based on my contributions and discussions on the mailing list, but the following might not be entirely correct.

I wonder if a disk-writing process could be spun out before dropping privileges?

I mean … it sure can and that appears the plan based on the last comment in that issue. However the “no disk access” policy is also useful for security. HAProxy can chroot itself to an empty directory to reduce the blast radius and that is done in the default configuration on at least Debian.

but I don't see why disk accesses need to block requests

My understanding is that historically Linux disk IO was inherently blocking. A non-blocking interface (io_uring) only became available fairly recently: https://stackoverflow.com/a/57451551/782822. And even then it's a operating system specific interface. For the BSD's you need a different solution.

If your process is blocked for even one millisecond when handling two million of requests per second (https://www.haproxy.com/de/blog/haproxy-forwards-over-2-mill...) then you drop 2k requests or increase latency.

or why they have to occur in the same thread as requests?

“have” is a strong word, of course nothing “has” to be. One thing to keep in mind is that HAProxy is 20 years old and apart from possibly doing Let's Encrypt there was no real need for it to have disk access. HAProxy is a reverse proxy / load balancer, not a web server.

Inter-thread communication comes with its own set of challenges and building something reliable for a narrow use case is not necessarily worth it, because you likely need to sacrifice something else.

As an example at scale you can't even let your operating system schedule out one of the worker threads to schedule in the “disk writer” thread, because that will effectively result in a reduced processing capacity for some fractions of a second which will result in dropped requests or increased latency. This becomes even worse if the worker holds an important lock.

It does not, because HAProxy does not perform any disk access at runtime and thus would be unable to persist the certificates anywhere. Disks accesses can be unpredictably slow and would block the entire thread which is not something you want when handling hundreds of thousands of requests per second.

See this issue and especially the comment from Lukas Tribus: https://github.com/haproxy/haproxy/issues/1864

Disclosure: Community contributor to HAProxy, I help maintain HAProxy's issue tracker.

Exactly all of this. I've mentioned the first point about add_header redefining instead of appending in a previous HN comment of mine: https://news.ycombinator.com/item?id=27253579. As mentioned in that comment, HAProxy's configuration is much more obvious, because it's procedural. You can read it from top to bottom and know what's happening in which order.

Disclosure: Community contributor to HAProxy, I help maintain HAProxy's issue tracker.

Disclosure: Community contributor to HAProxy, I help maintain HAProxy's issue tracker.

For my mental model, nginx is the right choice for SSL termination, logging, request mangling, interpretation of cookies and loadbalancing based on request information (for example choosing haproxy instances based on a domain name).

HAProxy can do all that and IMO it also does it better.

Personally I chain HAProxy and nginx in reverse order: HAProxy exposed to the Internet, doing all the heavy lifting. (Multiple) nginx with minimal config as a static file server and FastCGI gateway behind HAProxy.

see also: https://news.ycombinator.com/item?id=27253579

The dataplane API is an external product that itself uses the "stats socket". I personally don't have any experience with the dataplane API.

Changing certificates (https://docs.haproxy.org/2.6/management.html#9.3-add%20ssl%2...) and adding servers (https://docs.haproxy.org/2.6/management.html#9.3-add%20serve...) using the stats socket is both officially documented.

If you find the documentation insufficient or unclear, then this can be considered a documentation bug that I recommend filing here: https://github.com/haproxy/haproxy/issues

I'm surprised you find the documentation lacking. What type of API are you talking about? The internal C API? Lua? Configuration? Something else?

Disclosure: I'm a community contributor to HAProxy and help maintain the issue tracker.