At some point "enshittification" will likely also come to Cloudflare. They have the scale already, some new manager and/or investor/shareholder will push for all the money they can get, even if it has long-term cost.
That's the entire appeal of WSL (for me). A single source checkout I can work on from both sides; no inconsistency of forgetting that I need to apply changes twice.
Without it, I can just as well ssh into another box.
I've generally found it better to do it other way around - keep all the stuff in Linux partition and from Windows side access that over the virtual network share \\wsl.localhost\\home\me\whatever
> but the point is the SHA-1, as far as Git is concerned, isn't even a security feature. It's purely a consistency check. The security parts are elsewhere, so a lot of people assume that since Git uses SHA-1 and SHA-1 is used for cryptographically secure stuff, they think that, Okay, it's a huge security feature. It has nothing at all to do with security, it's just the best hash you can get. ... [1]
It's of course possible that SHA-1 was not originally intended as a security feature, but according to Hyrum's law, every observable API behavior becomes something that somebody starts to depend on, so if you start very publicly shipping a cryptographically secure hash, you better keep it cryptographically secure.
At the very latest, this fact was cemented when first-party git commit signatures started depending on the security properties of SHA-1.
> if you start very publicly shipping a cryptographically secure hash, you better keep it cryptographically secure
So if my API happens to return text strings that always happen to have an even number of characters, I better make sure that all future versions of it also always return an even number of characters, just in case some moron decided to bank their application's functionality on that? No. If you decide to write a fragile application tethered to some incidental property of some upstream software, your application deserves to break.
> No. If you decide to write a fragile application tethered to some incidental property of some upstream software, your application deserves to break.
Just because you never made any promise regarding one aspect of your API doesn't mean that you're absolved from responsibility when you choose to change it. If you know for a fact that many users rely on it and you choose to break it, you need a good reason. That kind of balancing act is part of your job. If you don't respect your users, perhaps development wasn't the right career choice.
As developers we're of course constantly tempted to rename things that we named poorly, or change a schema that is no longer optimal. But we must always take a step back and think about the downstream impact.
> I better make sure that all future versions of it also always return an even number of characters, just in case some moron decided to bank their application's functionality on that?
Oh yes, this does happen. There's even a name for that: ossification (https://en.wikipedia.org/wiki/Protocol_ossification). You can't change your API/protocol, because "some moron" started depending on implementation details.
It's easy to say "your application deserves to break" from an ivory tower, but it's often not easy or viable to fix it (for instance, it might have different owners, it might no longer be maintained, it might be more expensive to change, etc). And the change which broke that application was not in it; the blame naturally goes to what was changed last.
Hey, I'm just the messenger here, if you don't like it, take it up with Hyrum ;)
But seriously: If you can afford to break your user's applications if they "deserve to be broken", sure. Many API maintainers can't, or at least don't want to.
In the latter case (which is honestly the norm rather than the exception, at least for public APIs), yes, you should better think about all implicit API contracts your API shape might be projecting. That guideline has served me very well through my career, at least.
> It's purely a consistency check. The security parts are elsewhere
Sorry if the video answers this, but how does commit signing work if it doesn't rely on the hash algorithm being resistant to at least second-preimage attacks?
It was a mistake to assume a fixed algorithm in the repository format and client-server protocol. I remember being surprised when I learned about that choice, being familiar with cryptographic protocols and formats where the hash algorithm is usually a parameter that can vary for each concrete hash.
Cryptographic protocols have been moving towards something of a compromise in flexibility. "Everything flexible" is a security risk, especially when "everything" includes "fallback to nothing secure". "No flexibility" is a security risk because you can't upgrade. The middle path is something like "version numbers" with hard breakpoints. "I only support v2 of this cryptographic protocol and will not fallback to v1."
Which is sort of the hash algorithm approach git is taking with incompatible versions and a version break.
No, the mistake is to not restrict the allowed algorithm suites in a given deployment and in default configurations. However, for the allowed algorithms to be able to change over time, algorithm agility is needed. For example, the migration from RSA to ECDSA (and variants) to PQC algorithms, and from smaller to larger key sizes, would be vastly more difficult without algorithm agility.
All modern formats, such as JOSE and COSE, continue to be built on algorithm agility, and that’s unlikely to change.
Older protocol elements that had SHA-1 or SHA-256 hardcoded have invariably been replaced or supplemented with elements using an algorithm parameter.
> It was a mistake to assume a fixed algorithm in the repository format and client-server protocol.
See also perhaps Wireguard, which touts itself as not having "cryptographic agility" because they wanted to avoid all (perceived) problems and complications of IPsec. But now that PQC is (allegedly) approaching there's no easy to update things because (AIUI) there's no negotiation possible in the protocol; you're basically standing up a 'Wireguard 2.0' that runs separately than the original.
Wireguard is secure against a quantum computer though, via an additional pre-shared key.
> If an additional layer of symmetric-key crypto is required (for, say, post-quantum resistance), WireGuard also supports an optional pre-shared key that is mixed into the public key cryptography.
Yeah, in 2005, SHA-1 was just about the best you can do given the constraints of the time (without picking something much more esoteric, much slower, etc.). Using SHA-256 at that time would have been noticeably slower on the computers of the time, and made repo metadata take up a lot more space.
Have you seen algorithm-agnostic protocols, like TLS v1.2 and IPsec? It always turns out to be a bad idea. Future upgradability is fine but you really don't want implementations of the protocol to be incompatible with each other and you don't want attackers to have any chance of tricking you to using insecure protocols.
Flexibility made sense in 1995 when nobody was sure which algorithms would stand the test of time. Even in 2005 it was unnecessary and in 2015 it was an outright liability. If you have a good algorithm just specify the good algorithm, don't let the parties negotiate either a good one or a bad one.
Your argument is weird because it assumes we can know if a hash function will be secure forever. Assuming git would use SHA1 forever seems shortsighted.
That was true in 2007, but it stopped being true once people started signing commits and tags. A GPG/SSH signature on a commit covers the commit object, which names its tree and parents by SHA-1, so the signature is exactly as strong as SHA-1's collision resistance. If someone can prepare two trees with the same hash, a signed release tag vouches for both of them.
SHA-1DC blocks the known SHAttered/Shambles-style attacks, which is a good stopgap, but it detects known techniques; it isn't a hash you can reason about.
Code signing went through the same thing. Authenticode signatures with SHA-1 digests are effectively distrusted on Windows now, and that migration hurt precisely because it was put off until it was urgent.
Linus is one of the last remaining champions of rationality in large-scale software projects. Otherwise, it’s filled with devs who love to leave their brains out when it comes to practical scenarios. Anyone who thinks there is a security issue here is an absolute moron.
Rationality is the key point. A lot of devs approach their work in ways that are not rational or practical. Like the dev who wants to build a gold filigree decorated elevator that can handle ten thousand pounds of cargo and moves with the smoothness of a magnetic levitation rail in order to reach the second floor when all you really need is a ladder for the 2 people that will need access.
> I believe Web codecs should be purpose-built, efficient, and narrowly scoped to the needs of the Web.
The post downplays the usefulness of versatility. I disagree. I'd prefer not to play the "which image format is best for this image and this use case" game and having to transcode between them. For instance, it would be great if I could have an HTML gallery showing pictures of my files as I store them on harddisk. Today these are JPEG, because it's the lowest common denominator. WEBP, AVIF are not supported photography tools (e.g. https://support.captureone.com/hc/en-us/articles/36000262921...) and I don't expect support to ever be added since it is not formats intended for photography.
I got an impression JPEG XL is not a single format, but many formats put under one brand (same as webp), you still need to choose these formats and transcode between them.
I personally find AVIF more versatile. I just throw images at it, and it does a great job. As the article identifies, JPEG XL performs worse than AVIF in general, but it's particularly bad at things like illustrations and screenshots. With AVIF I don't need to worry about that.
I've always found it annoying how most cameras only let you save their photos as some combination of JPG/PNG/HEIC/RAW, often without any adjustable quality settings or option to save several copies in different formats.
It would be great if their behavior could be customized in a more modern web-friendly way, like "Save the original photo as a 95% quality AVIF in this folder, and also as an 70% quality resized WebP in this other folder".
The camera's I've owned (Canon and, in more recent years, Olympus/OM System) all could do RAW, JPG, or RAW+JPG, or in some cases cRAW+JPG, with several quality settings available for the JPG side.
But remember, on a camera you're wanting to maximize battery life, image quality and certain key performance metrics. The OM-1 Mk II can burst up to 120fps of 20 megapixel images with locked focus or 50fps with continuous AF. Thats a huge amount of data to capture, process and write to media. I think we want cameras to optimize for that. It's trivial to dump the resulting files on your computer and then convert between formats to your hearts content.
> During discovery in the case, Will Moye, one of the plaintiffs’ attorneys, found a five-page document called “Citation Overlay,” which appeared to have been generated by AI. Moye recognized the Citation Overlay document as being from ChatGPT, and demanded all of the prompts Autenrieth used from 3M’s lawyers. The deposition was paused for three hours while they were gathered, and Moye was given 350 pages of ChatGPT conversations that Autenrieth had when creating the report.
reply