takes MAINTAINER.
OK sthen@
Comment:
name-based proxying of HTTPS without decrypting traffic
Description:
Proxies incoming HTTP and TLS connections based on the hostname
contained in the initial request of the TCP session without decrypting
traffic. This enables HTTPS name-based virtual hosting to separate
backend servers without installing the private key on the proxy machine.
- Supports IPv4, IPv6 and Unix domain sockets for both back end
servers and listeners.
- Supports multiple listening sockets per instance.
- Supports HAProxy protocol to propagate original source address to
backend servers.
Homepage:
https://github.com/dlundquist/sniproxy
Maintainer:
Renaud Allard <renaud@allard.it>
Dino currently requires version 2.3.2, citing compat issues with
libsignal-protocol-c patch releases. 2.3.3 is safe, no API and ABI
change. Tweak to accept any 2.3.x release for now, to let dino build.
This release contains bugfixes, improvements to logging output, a slight
rework of wirese-keygen(1) so it securely creates key files itself rather
than printing them on standard output and more.
Tested between amd64 and sparc64 (different endianess).
Diff from Tim Juijsten (upstream, MAINTAINER), thanks!
INetSim is a software suite for simulating common internet services in a
lab environment, e.g. for analyzing the network behaviour of unknown
malware samples.
ok aja@
they were moved from a kernel header to src/usr.sbin/rad/rad.h
(ADV_PREFERRED_LIFETIME and ADV_VALID_LIFETIME). Use dhcpcd's own
constants instead. From florian@
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.
As discussed with sthen, the workaround for this android client is
probably still needed but JuiceSSH development appears to have stalled.
Those folks should probably just open-source their client instead of
letting it rot (personal opinion).
While here, don't force -std=gnu++11, base-clang and ports-gcc use at
least C++11 by default.
sthen agrees about dropping MESSAGE
