)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"change_message_id":"a1e2d867bd2321656daec4006647cdd03419688b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"ac978e46_4adbd8ef","updated":"2025-12-09 14:05:42.000000000","message":"I pushed a rebased version without changes to trigger the building on buildbots","commit_id":"0ac6b4766490c6ab33ee81b13983308bc9da4be6"},{"author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"change_message_id":"fc8e6231e3843d6f6e00eb670b811bf798913a8a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"435a3ad4_bc661678","updated":"2025-12-10 13:56:15.000000000","message":"In do_init_crypto_tls we do \n\n    to.ssl_ctx \u003d c-\u003ec1.ks.ssl_ctx;\n\nwhich copies the context and also the stack","commit_id":"0ac6b4766490c6ab33ee81b13983308bc9da4be6"},{"author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"change_message_id":"922313d1038bf5c7297b23f24a74b10b9c22fc8d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"64c3536d_6070c600","updated":"2025-12-10 13:53:32.000000000","message":"So I debugged this further and the root cause is that tls_root_ctx is shared/copied around between tls_options and key_schedule context. With the old implementation this was not a problem since the pointer never changed. But with the new implementation the pointer is freed and changed in one instance and the other instance will then still try to free the old pointer and that causes a free on an invalid pointer and that segfaults.","commit_id":"0ac6b4766490c6ab33ee81b13983308bc9da4be6"},{"author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"change_message_id":"6b86e37f493d61863eb503cfcaea3e7a8f849d2c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"d9003658_04ef9790","updated":"2025-12-09 14:47:47.000000000","message":"There seem to be a problem when the CRL file gets invalid:\n\nI setup OpenVPN with a normal setup\n\n(gdb) run\nStarting program: /home/arne/openvpn-cmake-debug/openvpn --server 10.33.0.0 255.255.255.0 --server-ipv6 fd00:f00f:babe::1/64 --topology subnet --cert /home/arne/ut-ca/server.pem --key /home/arne/ut-ca/server.key --dev tun --verb 4 --data-ciphers AES-256-GCM:AES-128-GCM:AES-192-GCM --tun-mtu 1400 --keepalive 10 25 --push explicit-exit-notify\\ 3 --verb 4 --crl-verify /home/arne/ut-ca/ca.crl --ca /home/arne/ut-ca/ca.pem\n\n[...]\n\nThen connected a client and that went fine. \n\nThen I replaced the CRL file with an invalid one:\n\nrm ca.crl \u0026\u0026 touch ca.crl\n\nConnecting the client again first works fine (connection gets rejected)\n\n\n\n2025-12-09 14:43:11 us\u003d78031 Connection Attempt MULTI: multi_create_instance called\n2025-12-09 14:43:11 us\u003d78143 udp4:192.168.188.75:58649 Re-using SSL/TLS context\n2025-12-09 14:43:11 us\u003d78267 udp4:192.168.188.75:58649 Control Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1250 tun_max_mtu:0 headroom:126 payload:1600 tailroom:126 ET:0 ]\n2025-12-09 14:43:11 us\u003d78293 udp4:192.168.188.75:58649 Data Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1400 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]\n2025-12-09 14:43:11 us\u003d82903 udp4:192.168.188.75:58649 VERIFY WARNING: depth\u003d0, unable to get certificate CRL: C\u003dKG, ST\u003dNA, O\u003dOpenVPN-TEST, CN\u003dTest-Client, emailAddress\u003darne@openvpn.net\n2025-12-09 14:43:11 us\u003d83007 udp4:192.168.188.75:58649 VERIFY WARNING: depth\u003d1, unable to get certificate CRL: C\u003dKG, ST\u003dNA, L\u003dBISHKEK, O\u003dOpenVPN-TEST, emailAddress\u003darne@openvpn.net\n2025-12-09 14:43:11 us\u003d83165 udp4:192.168.188.75:58649 VERIFY ERROR: CRL not loaded\n2025-12-09 14:43:11 us\u003d83238 udp4:192.168.188.75:58649 Sent fatal SSL alert: unknown CA\n2025-12-09 14:43:11 us\u003d83289 udp4:192.168.188.75:58649 OpenSSL: error:0A000086:SSL routines::certificate verify failed:\n2025-12-09 14:43:11 us\u003d83330 udp4:192.168.188.75:58649 TLS_ERROR: BIO read tls_read_plaintext error\n2025-12-09 14:43:11 us\u003d83358 udp4:192.168.188.75:58649 TLS Error: TLS object -\u003e incoming plaintext read error\n2025-12-09 14:43:11 us\u003d83405 udp4:192.168.188.75:58649 TLS Error: TLS handshake failed\n2025-12-09 14:43:11 us\u003d83550 Warning buffer of freed TLS session is still in use (session-\u003ekey[0].send_reliable-\u003earray[0])\n2025-12-09 14:43:11 us\u003d83686 udp4:192.168.188.75:58649 SIGUSR1[soft,tls-error] received, client-instance restarting\n2025-12-09 14:43:11 us\u003d83759 Packet (P_CONTROL_V1) with invalid or missing SID from [AF_INET]192.168.188.75:58649 or wrong packet id\n2025-12-09 14:43:13 us\u003d380641 Packet (P_CONTROL_V1) with invalid or missing SID from [AF_INET]192.168.188.75:58649 or wrong packet id\n2025-12-09 14:43:13 us\u003d380799 Packet (P_CONTROL_V1) with invalid or missing SID from [AF_INET]192.168.188.75:58649 or wrong packet id\n\n\nBut then reconnecting again leads to a segfault:\n\n\n2025-12-09 14:43:14 us\u003d950844 Connection Attempt MULTI: multi_create_instance called\n2025-12-09 14:43:14 us\u003d950963 udp4:192.168.188.75:59576 Re-using SSL/TLS context\n2025-12-09 14:43:14 us\u003d951112 udp4:192.168.188.75:59576 Control Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1250 tun_max_mtu:0 headroom:126 payload:1600 tailroom:126 ET:0 ]\n2025-12-09 14:43:14 us\u003d951162 udp4:192.168.188.75:59576 Data Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1400 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]\n2025-12-09 14:43:14 us\u003d955828 udp4:192.168.188.75:59576 VERIFY WARNING: depth\u003d0, unable to get certificate CRL: C\u003dKG, ST\u003dNA, O\u003dOpenVPN-TEST, CN\u003dTest-Client, emailAddress\u003darne@openvpn.net\n2025-12-09 14:43:14 us\u003d955883 udp4:192.168.188.75:59576 VERIFY WARNING: depth\u003d1, unable to get certificate CRL: C\u003dKG, ST\u003dNA, L\u003dBISHKEK, O\u003dOpenVPN-TEST, emailAddress\u003darne@openvpn.net\n2025-12-09 14:43:14 us\u003d955942 udp4:192.168.188.75:59576 VERIFY ERROR: CRL not loaded\n2025-12-09 14:43:14 us\u003d955961 udp4:192.168.188.75:59576 Sent fatal SSL alert: unknown CA\n2025-12-09 14:43:14 us\u003d955981 udp4:192.168.188.75:59576 OpenSSL: error:0A000086:SSL routines::certificate verify failed:\n2025-12-09 14:43:14 us\u003d955988 udp4:192.168.188.75:59576 TLS_ERROR: BIO read tls_read_plaintext error\n2025-12-09 14:43:14 us\u003d955996 udp4:192.168.188.75:59576 TLS Error: TLS object -\u003e incoming plaintext read error\n2025-12-09 14:43:14 us\u003d956005 udp4:192.168.188.75:59576 TLS Error: TLS handshake failed\n2025-12-09 14:43:14 us\u003d956018 Warning buffer of freed TLS session is still in use (session-\u003ekey[0].send_reliable-\u003earray[0])\n2025-12-09 14:43:14 us\u003d956061 udp4:192.168.188.75:59576 SIGUSR1[soft,tls-error] received, client-instance restarting\n2025-12-09 14:43:14 us\u003d956089 Packet (P_CONTROL_V1) with invalid or missing SID from [AF_INET]192.168.188.75:59576 or wrong packet id\n\\\n\n\n2025-12-09 14:43:28 us\u003d286692 Connection Attempt MULTI: multi_create_instance called\n2025-12-09 14:43:28 us\u003d286782 udp4:192.168.188.75:60010 Re-using SSL/TLS context\n2025-12-09 14:43:28 us\u003d287024 udp4:192.168.188.75:60010 OpenSSL: error:0308010C:digital envelope routines::unsupported:Global default library context, Algorithm (none : 0), Properties (\u003cnull\u003e)\n2025-12-09 14:43:28 us\u003d287031 udp4:192.168.188.75:60010 OpenSSL: error:0480006C:PEM routines::no start line:\n2025-12-09 14:43:28 us\u003d287034 udp4:192.168.188.75:60010 CRL: cannot read CRL from file /home/arne/ut-ca/ca.crl\n2025-12-09 14:43:28 us\u003d287036 udp4:192.168.188.75:60010 CRL: loaded 1 CRLs from file /home/arne/ut-ca/ca.crl\n2025-12-09 14:43:28 us\u003d287058 udp4:192.168.188.75:60010 Control Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1250 tun_max_mtu:0 headroom:126 payload:1600 tailroom:126 ET:0 ]\n2025-12-09 14:43:28 us\u003d287061 udp4:192.168.188.75:60010 Data Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1400 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]\n2025-12-09 14:43:28 us\u003d292177 udp4:192.168.188.75:60010 VERIFY OK: depth\u003d1, C\u003dKG, ST\u003dNA, L\u003dBISHKEK, O\u003dOpenVPN-TEST, emailAddress\u003darne@openvpn.net\n2025-12-09 14:43:28 us\u003d292774 udp4:192.168.188.75:60010 VERIFY OK: depth\u003d0, C\u003dKG, ST\u003dNA, O\u003dOpenVPN-TEST, CN\u003dTest-Client, emailAddress\u003darne@openvpn.net\n2025-12-09 14:43:28 us\u003d293487 udp4:192.168.188.75:60010 peer info: IV_VER\u003d2.7_rc3\n2025-12-09 14:43:28 us\u003d293559 udp4:192.168.188.75:60010 peer info: IV_PLAT\u003dmac\n2025-12-09 14:43:28 us\u003d293612 udp4:192.168.188.75:60010 peer info: IV_TCPNL\u003d1\n2025-12-09 14:43:28 us\u003d293639 udp4:192.168.188.75:60010 peer info: IV_MTU\u003d1600\n2025-12-09 14:43:28 us\u003d293652 udp4:192.168.188.75:60010 peer info: IV_NCP\u003d2\n2025-12-09 14:43:28 us\u003d293664 udp4:192.168.188.75:60010 peer info: IV_CIPHERS\u003dAES-256-GCM:AES-128-GCM:CHACHA20-POLY1305\n2025-12-09 14:43:28 us\u003d293704 udp4:192.168.188.75:60010 peer info: IV_PROTO\u003d8094\n2025-12-09 14:43:28 us\u003d293775 udp4:192.168.188.75:60010 peer info: ID\u003de7afaf\n2025-12-09 14:43:28 us\u003d293793 udp4:192.168.188.75:60010 peer info: IV_LZO_STUB\u003d1\n2025-12-09 14:43:28 us\u003d293799 udp4:192.168.188.75:60010 peer info: IV_COMP_STUB\u003d1\n2025-12-09 14:43:28 us\u003d293804 udp4:192.168.188.75:60010 peer info: IV_COMP_STUBv2\u003d1\n2025-12-09 14:43:28 us\u003d293983 udp4:192.168.188.75:60010 TLS: move_session: dest\u003dTM_ACTIVE src\u003dTM_INITIAL reinit_src\u003d1\n2025-12-09 14:43:28 us\u003d294092 udp4:192.168.188.75:60010 TLS: tls_multi_process: initial untrusted session promoted to trusted\n2025-12-09 14:43:28 us\u003d294701 udp4:192.168.188.75:60010 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bits RSA, signature: ecdsa-with-SHA256, peer temporary key: 768 bits X25519MLKEM768, peer signing digest/type: rsa_pss_rsae_sha256 RSASSA-PSS, key agreement: X25519MLKEM768\n2025-12-09 14:43:28 us\u003d294754 udp4:192.168.188.75:60010 [Test-Client] Peer Connection Initiated with [AF_INET]192.168.188.75:60010\n2025-12-09 14:43:28 us\u003d294784 Test-Client/udp4:192.168.188.75:60010 MULTI_sva: pool returned IPv4\u003d10.33.0.2, IPv6\u003dfd00:f00f:babe::1001\n2025-12-09 14:43:28 us\u003d295142 Test-Client/udp4:192.168.188.75:60010 Data Channel MTU parms [ mss_fix:1360 max_frag:0 tun_mtu:1400 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]\n2025-12-09 14:43:28 us\u003d295205 Test-Client/udp4:192.168.188.75:60010 Outgoing dynamic tls-crypt: Cipher \u0027AES-256-CTR\u0027 initialized with 256 bit key\n2025-12-09 14:43:28 us\u003d295223 Test-Client/udp4:192.168.188.75:60010 Outgoing dynamic tls-crypt: Using 256 bit message hash \u0027SHA256\u0027 for HMAC authentication\n2025-12-09 14:43:28 us\u003d295230 Test-Client/udp4:192.168.188.75:60010 Incoming dynamic tls-crypt: Cipher \u0027AES-256-CTR\u0027 initialized with 256 bit key\n2025-12-09 14:43:28 us\u003d295238 Test-Client/udp4:192.168.188.75:60010 Incoming dynamic tls-crypt: Using 256 bit message hash \u0027SHA256\u0027 for HMAC authentication\n2025-12-09 14:43:28 us\u003d295297 Test-Client/udp4:192.168.188.75:60010 MULTI: Learn: 10.33.0.2 -\u003e Test-Client/udp4:192.168.188.75:60010\n2025-12-09 14:43:28 us\u003d295333 Test-Client/udp4:192.168.188.75:60010 MULTI: primary virtual IP for Test-Client/udp4:192.168.188.75:60010: 10.33.0.2\n2025-12-09 14:43:28 us\u003d295352 Test-Client/udp4:192.168.188.75:60010 MULTI: Learn: fd00:f00f:babe::1001 -\u003e Test-Client/udp4:192.168.188.75:60010\n2025-12-09 14:43:28 us\u003d295359 Test-Client/udp4:192.168.188.75:60010 MULTI: primary virtual IPv6 for Test-Client/udp4:192.168.188.75:60010: fd00:f00f:babe::1001\n2025-12-09 14:43:28 us\u003d295389 Test-Client/udp4:192.168.188.75:60010 SENT CONTROL [Test-Client]: \u0027PUSH_REPLY,explicit-exit-notify 3,tun-ipv6,route-gateway 10.33.0.1,topology subnet,ping 10,ping-restart 25,ifconfig-ipv6 fd00:f00f:babe::1001/64 fd00:f00f:babe::2,ifconfig 10.33.0.2 255.255.255.0,peer-id 0,cipher AES-256-GCM,protocol-flags cc-exit tls-ekm dyn-tls-crypt,tun-mtu 1400\u0027 (status\u003d1)\n2025-12-09 14:43:29 us\u003d319915 Test-Client/udp4:192.168.188.75:60010 Data Channel: cipher \u0027AES-256-GCM\u0027, rx-peer-id: 0, tx-peer-id: 0\n2025-12-09 14:43:29 us\u003d320027 Test-Client/udp4:192.168.188.75:60010 Timers: ping 10, ping-restart 50\n2025-12-09 14:43:29 us\u003d320051 Test-Client/udp4:192.168.188.75:60010 Protocol options: protocol-flags cc-exit tls-ekm dyn-tls-crypt\n2025-12-09 14:43:37 us\u003d293135 Test-Client/udp4:192.168.188.75:60010 CC-EEN exit message received by peer\n2025-12-09 14:43:37 us\u003d293196 Test-Client/udp4:192.168.188.75:60010 Delayed exit in 5 seconds\n2025-12-09 14:43:42 us\u003d321905 Test-Client/udp4:192.168.188.75:60010 SIGTERM[soft,delayed-exit] received, client-instance exiting\n2025-12-09 14:43:42 us\u003d322142 ovpn_handle_peer: received data for a non-existing peer 0\n2025-12-09 14:43:58 us\u003d52079 Connection Attempt MULTI: multi_create_instance called\n2025-12-09 14:43:58 us\u003d52177 udp4:192.168.188.75:58033 Re-using SSL/TLS context\n2025-12-09 14:43:58 us\u003d52342 udp4:192.168.188.75:58033 OpenSSL: error:0308010C:digital envelope routines::unsupported:Global default library context, Algorithm (none : 0), Properties (\u003cnull\u003e)\n2025-12-09 14:43:58 us\u003d52349 udp4:192.168.188.75:58033 OpenSSL: error:0480006C:PEM routines::no start line:\n2025-12-09 14:43:58 us\u003d52352 udp4:192.168.188.75:58033 CRL: cannot read CRL from file /home/arne/ut-ca/ca.crl\n2025-12-09 14:43:58 us\u003d52354 udp4:192.168.188.75:58033 CRL: loaded 0 CRLs from file /home/arne/ut-ca/ca.crl\n2025-12-09 14:43:58 us\u003d52375 udp4:192.168.188.75:58033 Control Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1250 tun_max_mtu:0 headroom:126 payload:1600 tailroom:126 ET:0 ]\n2025-12-09 14:43:58 us\u003d52378 udp4:192.168.188.75:58033 Data Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1400 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]\n2025-12-09 14:43:58 us\u003d57062 udp4:192.168.188.75:58033 VERIFY WARNING: depth\u003d0, unable to get certificate CRL: C\u003dKG, ST\u003dNA, O\u003dOpenVPN-TEST, CN\u003dTest-Client, emailAddress\u003darne@openvpn.net\n2025-12-09 14:43:58 us\u003d57086 udp4:192.168.188.75:58033 VERIFY WARNING: depth\u003d1, unable to get certificate CRL: C\u003dKG, ST\u003dNA, L\u003dBISHKEK, O\u003dOpenVPN-TEST, emailAddress\u003darne@openvpn.net\n2025-12-09 14:43:58 us\u003d57129 udp4:192.168.188.75:58033 VERIFY ERROR: CRL not loaded\n2025-12-09 14:43:58 us\u003d57142 udp4:192.168.188.75:58033 Sent fatal SSL alert: unknown CA\n2025-12-09 14:43:58 us\u003d57155 udp4:192.168.188.75:58033 OpenSSL: error:0A000086:SSL routines::certificate verify failed:\n2025-12-09 14:43:58 us\u003d57157 udp4:192.168.188.75:58033 TLS_ERROR: BIO read tls_read_plaintext error\n2025-12-09 14:43:58 us\u003d57160 udp4:192.168.188.75:58033 TLS Error: TLS object -\u003e incoming plaintext read error\n2025-12-09 14:43:58 us\u003d57164 udp4:192.168.188.75:58033 TLS Error: TLS handshake failed\n2025-12-09 14:43:58 us\u003d57175 Warning buffer of freed TLS session is still in use (session-\u003ekey[0].send_reliable-\u003earray[0])\n2025-12-09 14:43:58 us\u003d57217 udp4:192.168.188.75:58033 SIGUSR1[soft,tls-error] received, client-instance restarting\n2025-12-09 14:43:58 us\u003d57246 Packet (P_CONTROL_V1) with invalid or missing SID from [AF_INET]192.168.188.75:58033 or wrong packet id\n2025-12-09 14:43:59 us\u003d165790 Packet (P_CONTROL_V1) with invalid or missing SID from [AF_INET]192.168.188.75:58033 or wrong packet id\n2025-12-09 14:43:59 us\u003d165885 Packet (P_CONTROL_V1) with invalid or missing SID from [AF_INET]192.168.188.75:58033 or wrong packet id\n2025-12-09 14:44:05 us\u003d928745 Connection Attempt MULTI: multi_create_instance called\n2025-12-09 14:44:05 us\u003d928929 udp4:192.168.188.75:54942 Re-using SSL/TLS context\n\nProgram received signal SIGSEGV, Segmentation fault.\n0x00007ffff7ba7cc5 in OPENSSL_sk_pop_free () from /lib/x86_64-linux-gnu/libcrypto.so.3\n\n(gdb) bt\n#0  0x00007ffff7ba7cc5 in OPENSSL_sk_pop_free () from /lib/x86_64-linux-gnu/libcrypto.so.3\n#1  0x000055555561339a in backend_tls_ctx_reload_crl (ssl_ctx\u003d0x55555576f260, crl_file\u003d0x7fffffffe5f2 \"/home/arne/ut-ca/ca.crl\", crl_inline\u003dfalse)\n    at /home/arne/openvpn-git/src/openvpn/ssl_openssl.c:1348\n#2  0x0000555555608148 in tls_ctx_reload_crl (ssl_ctx\u003d0x55555576f260, crl_file\u003d0x7fffffffe5f2 \"/home/arne/ut-ca/ca.crl\", crl_file_inline\u003dfalse)\n    at /home/arne/openvpn-git/src/openvpn/ssl.c:503\n#3  0x0000555555608e63 in key_state_init (session\u003d0x55555576f970, ks\u003d0x5555557700e0) at /home/arne/openvpn-git/src/openvpn/ssl.c:879\n#4  0x000055555560924c in tls_session_init (multi\u003d0x55555576f260, session\u003d0x55555576f970) at /home/arne/openvpn-git/src/openvpn/ssl.c:1023\n#5  0x0000555555609748 in tls_multi_init_finalize (multi\u003d0x55555576f260, tls_mtu\u003d1250) at /home/arne/openvpn-git/src/openvpn/ssl.c:1177\n#6  0x0000555555592659 in do_init_frame_tls (c\u003d0x55555577f2c0) at /home/arne/openvpn-git/src/openvpn/init.c:3462\n#7  0x0000555555594b45 in init_instance (c\u003d0x55555577f2c0, env\u003d0x5555556fdb30, flags\u003d10) at /home/arne/openvpn-git/src/openvpn/init.c:4613\n#8  0x0000555555595625 in inherit_context_child (dest\u003d0x55555577f2c0, src\u003d0x7fffffffb5d8, sock\u003d0x5555556fd8e0) at /home/arne/openvpn-git/src/openvpn/init.c:4914\n#9  0x00005555555aba4b in multi_create_instance (m\u003d0x7fffffffb510, real\u003d0x7fffffffafb0, sock\u003d0x5555556fd8e0) at /home/arne/openvpn-git/src/openvpn/multi.c:737\n#10 0x00005555555a8bec in multi_get_create_instance_udp (m\u003d0x7fffffffb510, floated\u003d0x7fffffffb3b0, sock\u003d0x5555556fd8e0) at /home/arne/openvpn-git/src/openvpn/mudp.c:269\n#11 0x00005555555b198e in multi_process_incoming_link (m\u003d0x7fffffffb510, instance\u003d0x0, mpp_flags\u003d5, sock\u003d0x5555556fd8e0) at /home/arne/openvpn-git/src/openvpn/multi.c:3357\n#12 0x00005555555a8fd1 in multi_process_io_udp (m\u003d0x7fffffffb510, sock\u003d0x5555556fd8e0) at /home/arne/openvpn-git/src/openvpn/mudp.c:357\n#13 0x00005555555b54b5 in multi_io_process_io (m\u003d0x7fffffffb510) at /home/arne/openvpn-git/src/openvpn/multi_io.c:468\n#14 0x00005555555b3629 in tunnel_server_loop (multi\u003d0x7fffffffb510) at /home/arne/openvpn-git/src/openvpn/multi.c:4197\n#15 0x00005555555b37da in tunnel_server (top\u003d0x7fffffffcb50) at /home/arne/openvpn-git/src/openvpn/multi.c:4249\n#16 0x00005555555b8110 in openvpn_main (argc\u003d31, argv\u003d0x7fffffffe168) at /home/arne/openvpn-git/src/openvpn/openvpn.c:309\n#17 0x00005555555b8256 in main (argc\u003d31, argv\u003d0x7fffffffe168) at /home/arne/openvpn-git/src/openvpn/openvpn.c:384\n(gdb)","commit_id":"0ac6b4766490c6ab33ee81b13983308bc9da4be6"},{"author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"change_message_id":"2d535cbd7bbefcc07e2796603947f30a22da9bc4","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"68001880_c0aa9bee","updated":"2025-12-10 15:42:56.000000000","message":"I changed the patch slightly to work with the 1431 that fixes the problem that this patches runs into.","commit_id":"f749dedbbd62f68ea578442f6dd577c339b75d42"},{"author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"change_message_id":"fc66d2b8e353c399b7201d6dda6f87e99ff9062c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":9,"id":"6b18f20d_eae83c03","updated":"2026-03-31 16:30:38.000000000","message":"I gave the patch a +2 but there some part of the patch that I adjusted when I needed to rebase it, so probably not a full +2 ack.","commit_id":"9438baa6be79a4661b118b028639d5e951575649"},{"author":{"_account_id":1000030,"name":"MaxF","email":"max@max-fillinger.net","username":"MaxF"},"change_message_id":"3403b3ac0c3f7122adce2cc066b87ae69fa81609","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":12,"id":"6606a64d_00d20420","updated":"2026-04-15 16:39:29.000000000","message":"This makes sense to me, but I don\u0027t know these functions in-depth. Just one question about how exactly X509_STORE_CTX_set0_crls() copies the CRLs.","commit_id":"615d0dee8480f28a07c2b6846e0c4dc2fd96956a"}],"src/openvpn/ssl_openssl.c":[{"author":{"_account_id":1000030,"name":"MaxF","email":"max@max-fillinger.net","username":"MaxF"},"change_message_id":"3403b3ac0c3f7122adce2cc066b87ae69fa81609","unresolved":true,"context_lines":[{"line_number":318,"context_line":"    ASSERT(session);"},{"line_number":319,"context_line":""},{"line_number":320,"context_line":"    /* Configure CRLs. */"},{"line_number":321,"context_line":"    X509_STORE_CTX_set0_crls(ctx, session-\u003eopt-\u003essl_ctx-\u003ecrls);"},{"line_number":322,"context_line":"    return X509_verify_cert(ctx);"},{"line_number":323,"context_line":"}"},{"line_number":324,"context_line":""}],"source_content_type":"text/x-csrc","patch_set":12,"id":"c1a234c8_f81029f6","line":321,"range":{"start_line":321,"start_character":0,"end_line":321,"end_character":63},"updated":"2026-04-15 16:39:29.000000000","message":"Does this function copy the CRLs into ctx, or a pointer to them? If it\u0027s the latter, does this modified X509_STORE_CTX continue to exist inside the SSL_CTX  after this callback? (What I\u0027m getting at is, do we need to worry about dangling pointers if reload_crl is called?)","commit_id":"615d0dee8480f28a07c2b6846e0c4dc2fd96956a"},{"author":{"_account_id":1000030,"name":"MaxF","email":"max@max-fillinger.net","username":"MaxF"},"change_message_id":"3be1071bf9597faa47fa910010850f46013a4f0a","unresolved":false,"context_lines":[{"line_number":318,"context_line":"    ASSERT(session);"},{"line_number":319,"context_line":""},{"line_number":320,"context_line":"    /* Configure CRLs. */"},{"line_number":321,"context_line":"    X509_STORE_CTX_set0_crls(ctx, session-\u003eopt-\u003essl_ctx-\u003ecrls);"},{"line_number":322,"context_line":"    return X509_verify_cert(ctx);"},{"line_number":323,"context_line":"}"},{"line_number":324,"context_line":""}],"source_content_type":"text/x-csrc","patch_set":12,"id":"25db34bc_0e2d0916","line":321,"range":{"start_line":321,"start_character":0,"end_line":321,"end_character":63},"in_reply_to":"6820491f_1542525e","updated":"2026-04-15 20:31:46.000000000","message":"Thanks for the explanations, I\u0027ll add my approval to this commit!","commit_id":"615d0dee8480f28a07c2b6846e0c4dc2fd96956a"},{"author":{"_account_id":1000047,"name":"davidben","email":"davidben@google.com","username":"davidben"},"change_message_id":"11768229532ab3281f39684165b0a9c2a19b02b0","unresolved":true,"context_lines":[{"line_number":318,"context_line":"    ASSERT(session);"},{"line_number":319,"context_line":""},{"line_number":320,"context_line":"    /* Configure CRLs. */"},{"line_number":321,"context_line":"    X509_STORE_CTX_set0_crls(ctx, session-\u003eopt-\u003essl_ctx-\u003ecrls);"},{"line_number":322,"context_line":"    return X509_verify_cert(ctx);"},{"line_number":323,"context_line":"}"},{"line_number":324,"context_line":""}],"source_content_type":"text/x-csrc","patch_set":12,"id":"4e11b60a_6a1828e8","line":321,"range":{"start_line":321,"start_character":0,"end_line":321,"end_character":63},"in_reply_to":"c1a234c8_f81029f6","updated":"2026-04-15 17:27:38.000000000","message":"\u003e Does this function copy the CRLs into ctx, or a pointer to them?\n\nPointer to them. set0 functions in OpenSSL generally are a pointer to them.\n\n\u003e If it\u0027s the latter, does this modified X509_STORE_CTX continue to exist inside the SSL_CTX after this callback?\n\nNope. OpenSSL is very inconsistent about the relationship between `FOO` and `FOO_CTX`. `X509_STORE` is shared configuration between certificate verifications, while `X509_STORE_CTX` is a single certificate verification operation. So this object will be freed shortly after this function returns. It\u0027s just a vehicle for passing the verification bits to the caller.\n\n\u003e (What I\u0027m getting at is, do we need to worry about dangling pointers if reload_crl is called?)\n\nShould be OK!","commit_id":"615d0dee8480f28a07c2b6846e0c4dc2fd96956a"},{"author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"change_message_id":"22df74b257cac363ef7e83d9406be4c474422b94","unresolved":true,"context_lines":[{"line_number":318,"context_line":"    ASSERT(session);"},{"line_number":319,"context_line":""},{"line_number":320,"context_line":"    /* Configure CRLs. */"},{"line_number":321,"context_line":"    X509_STORE_CTX_set0_crls(ctx, session-\u003eopt-\u003essl_ctx-\u003ecrls);"},{"line_number":322,"context_line":"    return X509_verify_cert(ctx);"},{"line_number":323,"context_line":"}"},{"line_number":324,"context_line":""}],"source_content_type":"text/x-csrc","patch_set":12,"id":"6820491f_1542525e","line":321,"range":{"start_line":321,"start_character":0,"end_line":321,"end_character":63},"in_reply_to":"c1a234c8_f81029f6","updated":"2026-04-15 18:16:05.000000000","message":"set0/get0 in OpenSSL terms mean no copy being made. We are really passing the pointer. \n\nThis is not super avoid but     session-\u003eopt-\u003essl_ctx is a pointer that points to the global tls_root_ctx. Commit 44dd39b3ef actually makes it a real pointer. Before it was as well but in a very weird way that all the pointers in that ssl_ctx would point to a global object but ssl_ctx still being local.\n\nThe pointer is technically dangling but since we set that before every access of it (in the callback), the pointer is also always updated.","commit_id":"615d0dee8480f28a07c2b6846e0c4dc2fd96956a"}]}