| Summary: | Haproxy subversion update | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Raphael Gertz <mageia> |
| Component: | RPM Packages | Assignee: | QA Team <qa-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | mageia, mageia, sysadmin-bugs |
| Version: | 9 | Keywords: | advisory, validated_update |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | MGA9-64-OK | ||
| Source RPM: | haproxy-2.8.4-1.mga9.src.rpm | CVE: | |
| Status comment: | |||
|
Description
Raphael Gertz
2023-12-12 03:06:43 CET
Haproxy has fixed issues in last upstream version 2.8.5 of branch 2.8.
Impacted mga9 & cauldron.
Suggested advisory:
========================
type: bugfix
subject: Updated haproxy package fixes some bugs
src:
9:
core:
- haproxy-2.8.5-1.mga9
description: |
Haproxy has a major, few medium and few minor bugs fixed in last upstream
version 2.8.5 of branch 2.8
Fixed major bug list:
- quic: complete thread migration before tcp-rules
Fixed medium bug list:
- mux-h2: fail earlier on malloc in takeover()
- mux-h1: fail earlier on malloc in takeover()
- mux-fcgi: fail earlier on malloc in takeover()
- quic: Possible crash for connections to be killed
- master/cli: Properly pin the master CLI on thread 1 / group 1
- peers: fix partial message decoding
- quic: Possible crash during retransmissions and heavy load
- proxy: always initialize the default settings after init
references:
- https://bugs.mageia.org/show_bug.cgi?id=32618
- https://www.haproxy.org/download/2.8/src/CHANGELOG
$ systemctl status haproxy.service
● haproxy.service - HAproxy Loadbalancer
Loaded: loaded (/usr/lib/systemd/system/haproxy.service; enabled; preset: disabled)
Active: active (running) since Mon 2023-12-11 XX:XX:XX CET; Xmin ago
Main PID: XXXXXX (haproxy)
Status: "Ready."
Tasks: 9 (limit: 65000)
Memory: 36.3M
CPU: Xmin Xs
CGroup: /system.slice/haproxy.service
├─XXXXXX /usr/sbin/haproxy -f /etc/haproxy/haproxy.conf -Ws
└─XXXXXX /usr/sbin/haproxy -f /etc/haproxy/haproxy.conf -Ws
$ curl -I http://127.0.0.1:8000
HTTP/1.1 302 Found
content-length: 0
location: https://127.0.0.1:8000/
cache-control: no-cache
$ curl -I -k https://127.0.0.1:8000
HTTP/2 200
date: Tue, 12 Dec 2023 01:14:09 GMT
content-type: text/html; charset=UTF-8CC:
(none) =>
mageia
Raphael Gertz
2023-12-12 03:15:04 CET
CC:
(none) =>
mageia
katnatek
2023-12-12 03:16:40 CET
Keywords:
(none) =>
validated_update $ rpm -qa | grep haproxy haproxy-quic-2.8.5-1.mga9 haproxy-2.8.5-1.mga9 You may install haproxy-noquic instead if you prefer. (uses openssl instead of quictls library) x86_64 Rpm list: haproxy-2.8.5-1.mga9.x86_64.rpm haproxy-noquic-2.8.5-1.mga9.x86_64.rpm haproxy-quic-2.8.5-1.mga9.x86_64.rpm haproxy-utils-2.8.5-1.mga9.x86_64.rpm An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2023-0143.html Resolution:
(none) =>
FIXED @raphael: can you explain quic/noquic in the package description?? currently it is "HAProxy is free, open source software that provides a high availability load balancer and proxy server for TCP and HTTP-based applications that spreads requests across multiple servers. It is written in C and has a reputation for being fast and efficient. Build without QUIC protocol support." it is not clear, one is linked to openssl/quic - and what difference it makes for the user. At the end of description: "Build without QUIC protocol support." First google result on QUIC is a wikipedia entry about it. Openssl don't include (Yet) the QUIC protocol which is kept as an overlay in quictls until it's enventualy integrated in openssl. What do you suggest as description improvement ? For me it seemed clear enough. For me it is not clear, noquic is linked to openssl. As you decided to make two packages, what is the "benefit" not using quic? Is it faster, smaller? How do I decide to use quic or noquic? (In reply to Marc Krämer from comment #7) > For me it is not clear, noquic is linked to openssl. As you decided to make > two packages, what is the "benefit" not using quic? Is it faster, smaller? > How do I decide to use quic or noquic? Basicaly I was using quic, it was available at first with a rpm rebuild argument until I managed a more proper solution. I had some help when it went down to "negociate" with the OpenSSL maintainer who was not happy about a concurrent ssl library inclusion. With some patches quictls was isolated to not contaminate other distribution packages pathing the way for a quic-enabled haproxy package. Performance wise, it would have been better to package LibreSSL or WolfSSL, but it's kind easier and safe to follow openssl patch set and updates... I didn't found back the reference, but it was written somewhere something like that: Haproxy QUIC is production ready, we use it on our haproxy website, but it may required to disable it on short notice if something critical happen. The reasonable choice seemed to have a conservative fallback noquic package and a quic version for adventurous people ;) See: https://www.haproxy.org/#news https://github.com/haproxy/wiki/wiki/SSL-Libraries-Support-Status https://www.mail-archive.com/haproxy@formilux.org/msg42914.html To decide if you use quic or not read: https://www.haproxy.com/blog/how-to-enable-quic-load-balancing-on-haproxy Right now if someone wants to enable it, he has everything. It seems reasonable to me that one should voluntarily install the package with the "QUIC" functionality, uncomment the configuration lines before exposing relatively recent code on a port open to the wide Internet. Ok. Why don't you add some hint in the quic package: QUIC: This version uses the quic library for ssl tls and quic protocol. More information on quic can be found here. https://www.haproxy.com/blog/how-to-enable-quic-load-balancing-on-haproxy Note this is only relevant for Layer 7 connections. NO_QUIC: This version uses the traditional ssl library for ssl and tls protocol. If you want Layer 7 quic protcol connections, use the ha-proxy-quic version. |