samueloph

This was patched on time: https://tracker.debian.org/news/1710762/accepted-openssl-354...

edit: even curl itself - which created the original document linked above - has http 3 just in an experimental build.

It's not experimental when built with ngtcp2, which is what you will get on distros like Debian 13-backports (plain Debian 13 uses OpenSSL-QUIC), Debian 14 and onward, Arch Linux and Gentoo.

Reference: https://curl.se/docs/http3.html

You can test it on Debian experimental, or use a Debian container:

$ podman run debian:experimental /bin/bash -c 'apt install --update -t experimental -y curl && curl --version'

Version 8.13.0~rc3-1+exp1 is syncing to the repositories and has HTTPS RR support enabled.

HTTP/3 is enabled in the curl package on Debian:

https://samueloph.dev/blog/debian-curl-now-supports-http3/

There's another one: https://github.com/RsyncProject/rsync/issues/715

There's a serious regression in the fixes: https://github.com/RsyncProject/rsync/issues/702

It impacts those who need to use `-r` (recursive) together with `-H` (preserve hardlinks),

HTTP/3 is enabled in the curl package on Debian:

https://samueloph.dev/blog/debian-curl-now-supports-http3/

Daniel also has a more up-to-date post on HTTP/3:

https://daniel.haxx.se/blog/2024/06/10/http-3-in-curl-mid-20...

In unstable you get a timely fix from upstream, in stable you get a fix by the security team.

For anything that is serious enough, you will get a security fix straight away for both unstable and testing (through the testing-security repository).

For things that are not really that important, yes, you will get the fix later.

We should be able to fix this within the next few days, thank you!

It's fixed now, should work in non-linux environments.

argh, we are looking into fixing that now.

I knew getopt was linux-specific but I thoughts the only impact was that the long form argument (--opt) would not work. I turns out it doesn't run at all instead.

We should be able to fix this within the next few days, thank you!

There is also --remote-header-name (-J) which takes the remote file name from the header instead of the URL, which is what wget does.

I don't think that's the case, that behavior is opt-in as indicated in wget's manpage:

This can currently result in extra round-trips to the server for a "HEAD" request, and is known to suffer from a few bugs, which is why it is not currently enabled by default.

As others pointed out, you can do that, you can also set them in .curlrc, or you can write a script if you want to allow for multiple URLs to be downloaded in parallel (not possible with an alias), or now you can just use wcurl :)

Note: wcurl sets a bit more flags than that, it also encodes the whitespaces in the URL and does parallel downloading of multiple URLs.

That might be a nice improvement, but I believe people want a single command without any arguments for this use case.

"curl --progress-bar" does that

"wcurl --opts="--progress-bar" URL"

I was wondering if that should be the default for wcurl, but the bar only works for downloading single files, I was afraid of users thinking there's a bug whenever they downloaded more than one file if the bar wasn't there anymore.

Opens up blog post about pattern matching in Rust.

Not a single "match" statement.

This post could increase its reach by explaining why a let statement is pattern matching, or at least point to a reference.

Although I understand people who don't know this already are not the target audience.

Here's the reference for those who need it: https://doc.rust-lang.org/book/ch18-01-all-the-places-for-pa...

The only issue I have with wayland is that screen sharing from slack does not work (when using the app).

That's still an experimental feature on curl's side so I'm not sure. https://everything.curl.dev/helpers/ws/support

Nice write-up.

I'm one of the Debian maintainers of curl and we are close to enabling http3 on the gnutls libcurl we ship.

We have also started discussing the plan for enabling http3 on the curl CLI in time for the next stable release.

Right now the only option is to switch the CLI to use the gnutls libcurl, but looks like it might be possible to stay with openssl, depending on when non-experimental support lands and how good openssl's implementation is.

What's up the the Red Hat mention? One of the first things the presenter says is that his job has nothing to do with this.

Edit: mentioning the presenter's name might be better. FTR the video is titled: "Glorious Eggroll (ProtonGE Developer )Talks at the Ubuntu Summit (Day 2)"

RedHat is one of the subscribers of the mailing list where the CVE details were sent under embargo, so yes, they were bound to that and broke the embargo 13 hours earlier than the lift date.

Debian can't really directly pay contributors (there are some rare few cases like lawyers, etc....), so that would be one of the reasons for what the article is talking about.

The best thing someone could do in this scenario would to be hire someone to work on/improve Debian directly.

Debian Jessie is terribly out of date and hasn't seen regular security updates for five years now, from https://www.debian.org/releases/jessie/:

Nowadays you get 10 years of support if you make use of the Freexian project.

Even the page you linked mentions that:

Jessie also had benefited from Long Term Support (LTS) until the end of June 2020.

And then you can use the ELTS support, which goes up until 2025: https://wiki.debian.org/LTS/Extended

So yes, users should not be running such old releases, but there's still support. And even though Freeexian's support is not officially affiliated with Debian, it's done by Debian Developers.

If you want to run this SteamOS release, you should consider pointing to Freexian's repo for security updates.

"Alert: if you look up curl CVEs in public sources like NVD you will find they use inflated severity levels and CVSS scores. They think they know better and override our assessments. This is a systemic error that we unfortunately cannot fix. Feel free to complain to them - we keep doing it to no use - and consider using our material as the canonical sources for curl issues."

But that’s only if you count the starting year as 1993; Red Hat the actual company seems to have been started in 1995, from what I read. In that case, they would have been 28 years old today.

The distro was not created before 1994 either, so looks like they're counting the moment the founders got together as the creation date (before the distro, before the company) ?!

Two settings I always set in my .inputrc which are not listed in the page:

  # Make autocompletion case insensitive and display suggestions after single tab.
  # https://bugs.debian.org/990353
  set completion-ignore-case On
  set show-all-if-ambiguous On

Wow, two brand new fonts in 2022 and they still make lowercase "l" look exactly like uppercase "i", I thought we were past that by now :(

I'm starting to question my understanding of algorithmic complexity, the author says things like "complexity being worst case O(n \log n)" and seems to talk about big O notation used for average cases as well.

I've learned that big O notation is always and exclusively about the worst case, for average and best cases we use Theta Θ and Omega Ω, respectively.

Do people not follow these definitions strictly? Has the author committed a mistake or am I missing something?

I did experience an interviewer once saying that my complexity analysis was wrong as the worst case would be extremely rare to hit, I did try to explain nicely that big O notation is always about the worst case, and that they were thinking about big Theta instead, now I wonder if I was wrong.

If you're interested in Portuguese in general, I suggest listening to Azorean Portuguese. It's so different it sounds like a different language to most Brazilians (and I assume to other nationalities as well),

https://www.youtube.com/watch?v=u7efyRaaTUU

Yes, it's funny in a way that Brazilian culture is influencing Portuguese's other than the reverse (since Portugal colonized Brazil). I guess during the internet era, having a bigger population is a big factor on "culture pressure" or whatnot (there's more Brazilian online content than Portuguese, or any other lusophone country).

I used to do the same for "Samuel" but figured I'm happier saying my name the correct way when asked instead of having that weird feeling. I don't mind if people say it differently with their accents or don't try to say it like I do, but it's nice when somebody says it correctly.

"correct pronunciation" to me, in terms of names, roughly means the pronunciation that that person grew with (so it's about where they're from).