Enable floating panes. These are panes which sit above the layout
("tiled panes") like popups but unlike popups are not modal and behave
like panes (so the same escape sequence support). Floating panes are
created with the "new-pane" command, bound to * by default.
Currently floating panes can only be moved and resized using the mouse.
The default second status line (if "status-format" is set to 2) has
changed to show a list of panes.
This is the first step and many obvious features are not yet complete
(notably the ability to swap floating panes, resize them using
resize-pane, change them between floating and tiles, and restore custom
layouts with floating panes).
Mostly written by Michael Grant with help from Dane Jensen.
add X25519MLKEM768 to the start of the default ECDHE curves list, allowing
libtls clients to connect to servers which don't offer any other curves
(this has been seen in the wild with got, reported by stsp). ok tb@
depends on recent libssl changes (ssl_tlsext.c r1.161, t1_lib.c r1.209).
Correctly handle failure to buffer DTLS messages.
If we fail to buffer an outgoing DTLS message, we're not going to be able
to retransmit it. Correctly propagate the failure.
ok kenjiro@ tb@
Move DTLS change cipher spec handling to its own function.
When a TLSv1.2 change cipher spec message has been built, call a separate
function that can handle the DTLS specific processing rather than including
this in the TLS code.
ok kenjiro@ tb@
Move DTLS handshake message handling to its own function.
When a TLSv1.2 handshake message has been built, call a separate function
that can handle the DTLS specific processing rather than including this in
the TLS code.
ok kenjiro@ tb@
Remove ssl3_handshake_msg_hdr_len()
This function is only called in one location, which is always a DTLS
context - use DTLS1_HM_HEADER_LENGTH directly instead.
ok kenjiro@ tb@
libssl: don't break TLSv1.2 with X25519MLKEM768
If the list of 'groups' starts with X25519MLKEM768 for a TLSv1.2 server,
ssl3_send_server_kex_ecdhe() attempts to use NID_X25519MLKEM768, which
it receives from tls1_get_supported_groups(). This does not work because
it never received the peer's public keys, which causes an error return
from tls_key_share_server_generate_mlkem768x25519().
For a TLSv1.2-only client with custom supported group list we will
currently send ML-KEM if configured. We should not do this.
There is more to fix here: if a TLSv1.2 client is misconfigured with
only X25519MLKEM768, we should not send a supported groups extension
(with this commit we'll send an empty one, which is an RFC violation).
This commit simply filters X25519MLKEM768 out of the supported groups
list if we're configured to be TLSv1.2-only.
feedback/ok jsing kenjiro (on an earlier version)
