If we need to make an exception we can do it and properly document the
reason but by default we should just use the default login class.
rc.d uses daemon or the login class provided in login.conf.d so this has
no impact there.
discussed with sthen@, tb@ and robert@
praying that my grep/sed skills did not break anything and still
believing in portbump :-)
- Switch over to using PCRE2.
- Convert over to using the haproxy's Makefile for the regular
install target and simplify the post-install target handling.
From brad.
This version essentially aims at fixing the HTX header encoding
issue mentioned in a previous message, and that may lead to a
request smuggling attack.
New release pointed out by tb
"A vulnerability was found that makes it possible to abuse the
HTTP/2 parser, allowing an attacker to prepend hostnames to a
request, append top-level domains to an existing domain, and inject
invalid characters through the :method pseudo-header."
https://www.haproxy.com/blog/august-2021-haproxy-2-0-http-2-vulnerabilities-fixed/
"Haproxy now supports keeping the private and public keys in
separate files, while previously, they needed to be in the same
file. This allows us to directly use the output of acme-client(1)
without doing extra scripting."
Based on a diff from Aisha Tammy who also authored the quote.
This is a backport from upstream:
BUILD: makefile: enable crypt(3) for OpenBSD (496374e)
Upstream diff from Matthieu Guegan, port one from brad. Prodded by both.
From the Announce email:
The main driver for this release is that it contains a fix for a
serious vulnerability that was responsibly reported last week by
Felix Wilhelm from Google Project Zero, affecting the HPACK
decoder used for HTTP/2. CVE-2020-11100 was assigned to this
issue.
This vulnerability makes it possible under certain circumstances
to write to a wide range of memory locations within the process'
heap, with the limitation that the attacker doesn't control the
absolute address, so the most likely result and by a far margin
will be a process crash, but it is not possible to completely
rule out the faint possibility of a remote code execution, at
least in a lab-controlled environment.
