> URL-safe-base64

And make sure to specify what exactly you mean by that. base64url-encoding is incompatible with base64+urlencoding in ~3% of cases, which is easily missed during development, but will surely happen in production.

Isn't it a lot more than 3%? I don't think I've heard anyone say url-safe-base64 and actually mean urlencode(base64(x))

… yeah. I assume they're getting that from doing 3/64, but for uniform bytes, you're rolling that 3/64 chance every base64-output-character. (And bytes are hardly uniform, either … TFA's example input of JSON is going to skew towards that format's character set.)

oh, geez. No, just base64, using the URL safe alphabet. (The obvious 62 characters, and "-_" for the last two.

It's called "urlsafe base64", or some variant, in the languages I work in.

> This encoding may be referred to as "base64url".

https://datatracker.ietf.org/doc/html/rfc4648#section-5

But yeah, it's not base64 followed by a urlencode. It's "just" base64-with-a-different-alphabet.

Looks like Mozilla is currently working on implementing `sendmmsg` and `recvmmsg` use in neqo (Mozilla's QUIC implementation) [1].

[1] https://github.com/mozilla/neqo/issues/1693

Here's the code, for those interested in finding the bug: https://github.com/mozilla-mobile/firefox-ios/tree/main/Brow...

It says in the article

> Seabed 2030 is a long-term mapping project attempting to fully chart the seafloor and reveal all features 100 meters or larger by 2030.

There is an area of interest, "Area 3: Indian Ocean: Ninetyeast Ridge" around 30S 87E, which specifically mentions MH370:

https://seabed2030.org/wp-content/uploads/2023/06/AtlanticIn...

Though that is quite a bit (~830 km / ~1250 km from the center of the square around 30S 87E) off to the (north)west of the most recent search proposal from mh370search.com:

https://www.mh370search.com/2024/03/16/mh370-a-new-hope/

edit: Got the distance wrong. Corrected.

Certainly weird that wireshark shows TLSv1 while curl shows TLSv1.3. That shouldn't happen unless something interfered with the Client Hello. (or the wireshark version is outdated)

Ran into this myself about 10 days ago.

If a TLS handshake is aborted partway through, Wireshark will label it “TLSv1”. It actually retroactively labels the 1.0 TLS packets as 1.3 after a successful TLS 1.3 handshake finishes.

This makes sense because a TLSv1.3 handshake actually starts as 1.0 and then upgrades to 1.3 only with IIRC the Server Hello response to the ClientHello.

The following links document this behavior, in case you or your organization’s security team is nervous TLSv1 is actually being used:

https://superuser.com/a/1618420

https://ask.wireshark.org/question/24276/how-does-wireshark-...

https://gitlab.com/wireshark/wireshark/-/issues/16114

Oh, indeed, that's quite surprising. A TLSv1.3 Client Hello always contains the supported_versions extension, which should allow wireshark to label it correctly, regardless of whether or not the handshake actually finishes. Though, tbf, it does say TLSv1 and not TLSv1.0. I wonder how it would look had TLSv1.3 been named TLSv2.0 after all...

edit: Ah, that GitLab link lead me to https://gitlab.com/wireshark/wireshark/-/issues/19515 which is a recent discussion around this topic and https://gitlab.com/wireshark/wireshark/-/merge_requests/1377... already dealt with it :)

linux-firmware does not carry any microcode update for Renoir (yet). Or what do you mean by "TFA"?

The fixed Renoir microcode should have revision >= 0x0860010b as per the kernel: https://github.com/torvalds/linux/commit/522b1d69219d8f08317...

TFA == The Fine Article :)

Updated microcode shows 0x08600106 revision so I guess that explains it.

> and if

Do you mean the obvious `sudo snap set system refresh.hold="$(date --date=+100years +%Y-%m-%dT%H:%M:%S%:z)"`? (no error)

edit: Ah, that silently stops working after 60 days, nvm.

That's why there's OCSP stapling and OCSP must staple. Ever seen an nginx server fail HTTPS connection exactly once after rotating the certificate? That's nginx lazily fetching the OCSP response from upstream for stapling purposes.

Notarization has a similar "stapling" workflow as well.

Here's the spec:

https://html.spec.whatwg.org/multipage/input.html#attr-input...

> Authors are encouraged to specify both any MIME types and any corresponding extensions when looking for data in a specific format.

> User agents should prevent the user from selecting files that are not accepted by one (or more) of these tokens.

Besides all the points other people already made, the money saved by being able to switch to deploying the Starlink constellation via SuperHeavy/Starship (very likely to be cheaper in $ per satellite-to-orbit) instead of F9 earlier makes taking risks and iterating faster even more appealing.