daltux
:debian: 📰 Apareceram notícias sobre o pacote curl, ao atualizá-lo hoje no #Debian #sid (unstable) e que achei interessantes compartilhar. É o anúncio de alterações importantes, aparentemente entrando em efeito agora e iniciadas alguns meses atrás pelos mantenedores, em suma:

- O utilitário curl, a partir da versão 8.8.0-2, passa a suportar HTTP/3, com os parâmetros --http3 ou --http3-only. Para conseguir isso, o programa agora passa a utilizar GnuTLS no lugar de OpenSSL. Ainda fornecerão uma variação de libcurl que continua usando OpenSSL.

- Incluíram o comando wcurl (veja seu manual) que facilita baixar um arquivo sem precisar lembrar os parâmetros do curl. Pode ser chamado no lugar dos usos mais simples de wget.

O conteúdo completo da mensagem está em https://metadata.ftp-master.debian.org/changelogs/main/c/curl/curl_8.12.0+git20250209.89ed161+ds-1_curl.NEWS

#curl #http3 #gnutls #openssl #gnu #softwareLivre
Debian -- Details of package curl in sid

packages.debian.org
Feb 10, 2025, 13:31 · · · 1 · 0
🅴🆁🆄🅰 🇷🇺
Обновился #OpenSSL до 3.4.0 и опять без полноценной нормальной поддержки #QUIC, т.е. непригодный для #HTTP/3 на серверной стороне. И, соответственно, ещё не ясно на сколько хорошо сделана клиентская часть :)
Аж вспомнились времена, когда желая получить #curl поддерживающий нормально работу #HTTP/3 приходилось собирать его из исходников с #GnuTLS, вместо #OpenSSL.

#HTTP/3 работает не через #tcp/ip, а использует в качестве транспорта протокол #QUIC (Quick UDP Internet Connections), т.е. передаёт данные поверх #udp, без использования #tcp/ip, не устанавливая tcp-соединений. Вот картинка про современный #HTTP

Сам по себе #QUIC не умеет передавать данные в открытом виде, а может только через #TLS v1.3, т.е. в обязательном порядке только зашифрованные (используется вариант #TLS близкий к #DTLS, а не тот вариант #TLS что применяется повсеместно для tcp-соединений).

#curl может использовать разные альтернативы #OpenSSL, т.к. изначально спроектирован таким образом, что не привязан именно к #OpenSSL, вот официальная документация что и как с криптографическими бэкендами. Примерно там же есть сравнение разных бэкендов.

Что предлагаю по реализации HTTP/3 сами авторы?
Вот зелёным выделена комбинация библиотек, которую полагают наиболее стабильным и полноценным вариантом
Вся загвоздка в том, что #OpenSSL пытается содержать в себе реализацию #QUIC, а не использует реализацию в виде какой-то библиотеки.

Что получается с предлагаемой комбинацией?
Протокол #HTTP/3 реализуется через библиотеку #nghttp3, необходимая реализация #QUIC через #ngtcp2, а для TLS используется #GnuTLS или же #wolfSSL
Вот официальная документация с деталями по сборке отдельных составляющих. Если доступный в системе #GnuTLS далёк от свежих версий, то легко собирается из исходников.

В целом, про варианты #curl с поддержкой #HTTP/3 очень хорошо и достойно расписано здесь. Есть и перевод этой публикации на русском языке.

#https #http #openssl #lang_ru @Russia
(webdev Tory) :emacs:

My emacs is failing to negotiate addresses that always worked before, though Curl does just fine by them. Errors indicate that #gnutls might be the problem. I wonder what happened and if more will break if I update it... #guix

Artlog

That's another late impact of the famous letsencrypt intermediate certificate change ...

i will just open a bug on #gnutls when my brain will have cooled a little.

Artlog

chasing in detween #ubuntu and #debian packaging of cadaver ( yes it's the program name ), i finaly found that it was not related to build but to system ca certificates.

ca-certificates are not the same, and there is an expired CA on debian that just confuses gnutls that stops reading following CAs.
Depending on when this expired ca is in the list server certificate will be accepted or not.

Just a #gnutls one.

Iron Bug
I found where the memory leak in GnuTLS happened! I traced it for quite long time to trace it down in multithreaded calls of multiple libraries. it took some time and getting into the libraries internals.

so, the leak happens when gnutls_handshake returns an error. then the internal buffers for handshake headers are not freed properly and leak.
the cheap and dirty solution is to call gnutls_deinit and gnutls_init each time when a session failed a handshake (they may be numerous in long sessions).
this happens only when multiple threads call gnutls_handshake. on a single thread I didn't get any leaks. though, maybe there were no errors because I just had not enough traffic on the socket. though, they claim that gnutls is thread safe. so I'm not sure if everything is all right with such a use. I debug it in libmicrohttpd where I discovered the problem.
the internal fix for GnuTLS doesn't seem that easy. but I will to think on it. maybe the reinitialization from the outside is not that bad.
I will try to make a test example for showing the problem and send bug reports and possible patches to upstream.
#programming #gnutls #libmicrohttpd #memory leaks #bugs #hint #bugfix
bumble's (🐝) rumple (🦄)

Well, I'm back at attempting to get a #Heroku buildpack working for #Guile #Artanis (well, technically, getting #GnuTLS working with the Guile and Artanis buildpacks I already got working so you can use HTTPS with Artanis).

And, while I'm here, might as well update my Guile buildpack to 3.0; looks like it's working, so far…

🅹🅴🅳🅸🅴 🇺🇦🕊️

Massives #Sicherheitsproblem in #GnuTLS erlaubt Mitlesen von Kommunikation

Ein Fehler bei der Umsetzung der #TLS-Verschlüsselung gefährdet deren Sicherheit, wenn die Bibliothek GnuTLS zum Einsatz kommt.

heise.de/security/meldung/Mass