samueloph

Yeah, the definition of "portable" being used is one that is not useful for most users, the fact that it's not in Fedora and neither Debian is a sign of it. Especially considering the demand for ghostty, it's a very cool project.

Someone willing to distribute ghostty has to pull in a whole programing language stack just for it, ghostty seems to be the most important project written in zig so far.

For the definition of portable that matters to me, this is the least portable possible, if it was written in almost any other language it would have been more portable. And yes, this all goes away once zig is onboarded to all distros, then it becomes "empirically portable", but we're not there yet.

PS.: "Portable" meaning which CPU architectures are supported is not a very useful meaning of the word for me, even though it's more accurate, it says nothing about the ability to actually build and run it in different OSes.

exactly, that's why in my opinion the patches should have been made available straight away instead of doing this, it made it worse.

Deciding to announce it like this is wild, it's an invitation for everyone to put their agents to work in order to find out what the vulnerability is and exploit it, while nobody is allowed to patch it until tomorrow.

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