The What If Machine: Bringing the “Iffy” Future of CSS into the Present - Related to “iffy”, code, mistakes, into, stenberg

Curl’s Daniel Stenberg on Securing 180,000 Lines of C Code

In his talk for this year’s annual open source conference FOSDEM, Curl creator Daniel Stenberg promised to show his audience “Things to do in order to sleep well while having your C code in 20 billion installations.”.

Stenberg believes 20 billion is actually a low estimate for the number of Curl installations in the world,.

The number certainly gives the open source data transfer utility he single-handedly wrote, which gives the project “a little bit of a responsibility.”.

“But of course, we write this in the safest possible language,” he says, drawing a laugh — because Curl is written in the C programming language….

His talk with entertaining, informative, and ultimately reassuring.

But it also offered an inspiring example of what happens when a project commits to extra levels of high security. And how that commitment turns into execution — when the stakes are unusually high….

Toward the end of the talk, Stenberg put up a funny slide parodying an O’Reilly book cover, Rewriting Curl in Rust. A weekend project.” (The top of the book cover added the tagline “Telling others instead of doing it yourself.”).

“It’s a very popular book,” Stenberg says, while adding pointedly that “No one has really finished it.”.

Curl consists of 180,000 lines of C code. That’s [website] the length of the novel War and Peace, Stenberg tells his audience, describing it as “actually quite a lot of code… for what it is. It transfers data.” So he says emphatically, “We’re not going to re-write Curl in Rust. In any language — we’re not going to re-write it at all. It’s there already.” Stenberg acknowledges Rust is “possibly a great language” and says third-party dependencies can still be written in Rust, which he predicts there’ll be more of in the Curl project going forward.”.

But Curl’s current codebase is still written in C, and “we’re just patiently iterating and polishing over time. There’s not going to be any re-write.”.

So instead, the talk offered examples of everything else they’ve been doing to keep Curl secure….

For starters, while they’re coding in C, Stenberg says they’ve banned “a bunch of undesired functions” that are easy to use the wrong way. Someone asked for examples at the end of the talk — and Stenberg started with gets() (which one commenter on Stack Overflow calls “the devil’s tool for creating buffer overflows”), as well as scanf(), strcopy(), and sprintf().

“It doesn’t really matter how experienced you are — some functions in the C standard are really not advisable to use in code. And we check for them with tools, we ban them so you can’t really sneak them in by mistake.”.

There’s also a special “torture test” that takes place in a custom debugging build in which every function where a memory allocation could fail (like malloc or calloc) has a wrapper that lets them call that function — and keep calling it until it fails. “It should just fail nicely — no memory leak, no crash, and just exit with an error code,” Stenberg explained. “That’s an awesome way to test exit paths, really, and make sure that we always free up stuff and clean up stuff when we exit.”.

The dev team doesn’t always test them all. He says with a laugh, “It’s not a fast process,” — so they have a system that randomly tests a smaller subset. Stenberg says they’re also using Continuous Integration — which ends up running more than 400,000 tests for every pull request and commit. “Just, I think a year ago, they could take hours,” he remembers — but they’ve since optimized them, so they now run in 30 minutes. “It’s really convenient to have them finish really fast so that we know the state of the latest changes right now.”.

While you may have heard the phrase “CPU second” — a second of full-power use on a server-grade CPU — 86,400 CPU seconds add up to a full CPU day. And on average, Stenberg says “We spend about 10 CPU days per day, right now, in CI only.”.

To maintain security throughout the project, there’s also a wide variety of other tests, Stenberg says — even one that tests “that the code style is right, and the indenting and spelling even in the code.” There’s also a CI job to make sure they don’t have any binary blobs. (Although “There should be no way to hide any encrypted payloads in our repository anyway,” Stenberg says since most of their committers are already using digital cryptographic signatures.).

There’s unit tests, library tests, tool tests, “And of course, we have the analyzers checking code all the time” — both static and dynamic analyzers. Curl is also part of Google’s OSS-Fuzz project. (As Stenberg describes it, “They keep fuzzing Curl nonstop on Google hardware…”).

“We want to make sure that all those 20 billion installations run fine.”.

When it comes to vulnerabilities, “We fix them as soon as we can, we alert distros as we should, and we document everything really really thoroughly,” Stenberg says, including a JSON-formatted list of affected versions of Curl. That information is also made available on Curl’s website. The Curl program is now also an official CVE-numbering authority “so that we can manage our own CVEs a little bit advanced.”.

And they’re serious about finding vulnerabilities, Stenberg says, adding, “We have had multiple audits.”.

Stenberg remembers that their first audit in 2016 “resulted in seven CVEs,” and one in 2022 resulted in two more CVEs. But he’s proud that a more narrow audit in 2024 resulted in 0 CVEs — an encouraging trend. Audits are a big and expensive undertaking. “Someone is going to spend a lot of expensive hours looking at code… It’s not something that’s easy to be done right for a small open-source project. You have to have someone who just has a deep pocket who suddenly wants this to happen.”.

Yet he also points out that the cost of audits was still “much more than our entire bug bounty program for many years” — even though the bug bounty program ultimately found more CVEs.

That bug-bounty program is run in association with HackerOne and the Internet Bug Bounty program. Stenberg says they’ve paid out more than $85,000 since they started the program nearly six years ago in April of 2019 — and 76% of the 500 reports resulted in a CVE (more than 15% — while another 19% resulted in a non-CVE-level bug fix). “Not everything else is crap,” Stenberg says, “but there’s a fair amount of that too… We always disclose all of them after the fact so that you can follow the discussion…”.

Although the last bullet point on the “Bug bounty” slide just says “AI slop is increasing.”.

“Actually, right now, we have about the same rate of valid reports as ‘AI slop’ reports,” Stenberg says — about 10 to 15% of submissions!

The project aspires to top-level security, and that commitment seems to permeate it at every level.

All commits are carefully reviewed — by humans and by machines. And “We have a really strict code style these days,” Stenberg says, which makes the whole 180,000-line codebase look like it was written by a single author (with that consistency making it easier to read and debug).

“We have a lot of documentation about the source code and internal APIs and everything.” Later Stenberg explains there’s even documentation-checking tooling, and not just for spelling and grammar. “For example, we try to avoid contractions in the English that we write the documentation in. So ‘isn’t’ isn’t something that’s allowed in the documentation… Stuff like that… “.

The project’s development team all use two-factor authentication for accessing their GitHub-hosted source code….

GitHub has provided them with extra testing resources, which ultimately prompted some interesting discussion on Mastodon about whether other open-source projects should launch with the tightest security right from the start.

“Most open source projects I think start small and ‘easy’,” Stenberg replied, adding that “getting them all done right and properly tight from the beginning without even knowing if the project flies might not be the best priority. I think very few projects do that… [I]n the Curl project, pretty much every bolt was loose when we started…”.

Later in the discussion, Curl developer Stefan Eissing joked that the stakes sometimes feel very high. “We have ‘civilization will end on several planets if you screw this up’ FOSS projects. This is no way to run a civilization.”.

And Stenberg seemed grateful for the help they’d received from GitHub — perhaps wishing the same level of support could reach more open-source software repositories that are grapping with their own loose bolts.

“Looking around in the world, lots of projects still have a few that could use a little help…”.

I have a very bad memory, which is why I am so obsessed with having systems that make it easier for me to search for information. Many times, if I don......

In this episode, Thomas Betts speaks with Andrew Harmel-Law about his new book, Facilitating Software Architecture: Empowering Teams to Make Architect......

Transitioning Top-Layer Entries And The Display Property In CSS.

We are getting spoiled with so many new feat......

The What If Machine: Bringing the “Iffy” Future of CSS into the Present

Geoff’s post about the CSS Working Group’s decision to work on inline conditionals inspired some drama in the comments section. Some developers are excited, but it angers others, who fear it will make the future of CSS, well, if-fy. Is this a slippery slope into a hellscape overrun with rogue developers who abuse CSS by implementing excessive logic in what was meant to be a styling language? Nah. Even if some jerk did that, no mainstream blog would ever publish the ramblings of that hypothetical nutcase who goes around putting crazy logic into CSS for the sake of it. Therefore, we know the future of CSS is safe.

You say the whole world’s ending — honey, it already did.

My thesis for today’s article offers further reassurance that inline conditionals are probably not the harbinger of the end of civilization: I reckon we can achieve the same functionality right now with style queries, which are gaining pretty good browser support.

If I’m right, Lea’s proposal is more like syntactic sugar which would sometimes be convenient and allow cleaner markup. It’s amusing that any panic-mongering about inline conditionals ruining CSS might be equivalent to catastrophizing adding a ternary operator for a language that already supports if statements.

Indeed, Lea says of her proposed syntax, “Just like ternaries in JS, it may also be more ergonomic for cases where only a small part of the value varies.” She also mentions that CSS has always been conditional. Not that conditionality was ever verboten in CSS, but CSS isn’t always very good at it.

Sold! I want a conditional oompa loompa now!

Me too. And many other people, as proven by Lea’s curated list of amazingly complex hacks that people have discovered for simulating inline conditionals with current CSS. Some of these hacks are complicated enough that I’m still unsure if I understand them, but they certainly have cool names. Lea concludes: “If you’re aware of any other techniques, let me know so I can add them.”.

Hmm… surely I was missing something regarding the problems these hacks solve. I noted that Lea has a doctorate whereas I’m an idiot. So I scrolled back up and reread, but I couldn’t stop thinking: Are these people doing all this work to avoid putting an extra div around their widgets and using style queries?

It’s fair if people want to avoid superfluous elements in the DOM, but Lea’s list of hacks displays that the alternatives are super complex, so it’s worth a shot to see how far style queries with wrapper divs can take us.

Lea’s motivating examples revolve around setting a “variant” property on a callout, noting we can almost achieve what she wants with style queries, but this hypothetical syntax is sadly invalid:

.callout { @container (style(--variant: success)) { border-color: var(--color-success-30); background-color: var(--color-success-95); &::before { content: var(--icon-success); color: var(--color-success-05); } } }.

She wants to set styles on both the container itself and its descendants based on --variant . Now, in this specific example, I could get away with hacking the ::after pseudo-element with z-index to give the illusion that it’s the container. Then I could style the borders and background of that. Unfortunately, this solution is as fragile as my ego, and in this other motivating example, Lea wants to set flex-flow of the container based on the variant. In that situation, my pseudo-element solution is not good enough.

Remember, the acceptance of Lea’s proposal into the CSS spec came as her birthday gift from the universe, so it’s not fair to try to replace her gift with one of those cheap fake containers I bought on Temu. She deserves an authentic container.

One of the comments on Lea’s proposal mentions type grinding but calls it “a very (I repeat, very) convoluted but working” approach to solving the problem that inline conditionals are intended to solve. That’s not quite fair. Type grinding took me a bit to get my head around, but I think it is more approachable with fewer drawbacks than other hacks. Still, when you look at the samples, this kind of code in production would get annoying. Therefore, let’s bite the bullet and try to build an alternate version of Lea’s flexbox variant sample. My version doesn’t use type grinding or any hack, but “plain old” (not so old) style queries together with wrapper divs, to work around the problem that we can’t use style queries to style the container itself.

Comparing the code from Lea’s sample and my version can help us understand the differences in complexity.

And here are the two versions of the markup:

So, simpler CSS and slightly more markup. Maybe we are onto something.

What I like about style queries is that Lea’s proposal uses the style() function, so if and when her proposal makes it into browsers then migrating style queries to inline conditionals and removing the wrappers seems doable. This wouldn’t be a 2025 article if I didn’t mention that migrating this kind of code could be a viable use case for AI. And by the time we get inline conditionals, maybe AI won’t suck.

But we’re getting ahead of ourselves. Have you ever tried to adopt some whizz-bang JavaScript framework that looks elegant in the “to-do list” sample? If so, you will know that solutions that appear compelling in simplistic examples can challenge your will to live in a realistic example. So, let’s see how using style queries in the above manner works out in a more realistic example.

Combine my above sample with this MDN example of HTML5 Validation and Seth Jeffery’s cool demo of morphing pure CSS icons, then feed it all into the “What If” Machine to get the demo below.

All the changes you see to the callout if you make the form valid are based on one custom property. This property is never directly used in CSS property values for the callout but controls the style queries that set the callout’s border color, icon, background color, and content. We set the --variant property at the .callout-wrapper level. I am setting it using CSS, like this:

@property --variant { syntax: "error | success"; initial-value: error; inherits: true; } body:has(:invalid) .callout-wrapper { --variant: error; } body:not(:has(:invalid)) .callout-wrapper { --variant: success; }.

However, the variable could be set by JavaScript or an inline style in the HTML, like Lea’s samples. Form validation is just my way of making the demo more interactive to show that the callout can change dynamically based on --variant .

It’s off-brand for me to write an article advocating against hacks that bend CSS to our will, and I’m all for “tricking” the language into doing what we want. But using wrappers with style queries might be the simplest thing that works till we get support for inline conditionals. If we want to feel more like we are living in the future, we could use the above approach as a basis for a polyfill for inline conditionals, or some preprocessor magic using something like a Parcel plugin or a PostCSS plugin — but my trigger finger will always itch for the Delete key on such compromises. Lea acknowledges, “If you can do something with style queries, by all means, use style queries — they are almost certainly a improved solution.”.

I have convinced myself with the experiments in this article that style queries remain a cromulent option even in Lea’s motivating examples — but I still look forward to inline conditionals. In the meantime, at least style queries are easy to understand compared to the other known workarounds. Ironically, I agree with the comments questioning the need for the inline conditionals feature, not because it will ruin CSS but because I believe we can already achieve Lea’s examples with current modern CSS and without hacks. So, we may not need inline conditionals, but they could allow us to write more readable, succinct code. Let me know in the comment section if you can think of examples where we would hit a brick wall of complexity using style queries instead of inline conditionals.

Hi Buddy! Welcome back to the part 4 of the MS Rules Engine series. In this article we will be concentrating on how to use different in-built post rul......

Rust and Python are widely used programming languages in software development and data science. Rust’s adoption has grown significantly in recent year......

A little gem from Kevin Powell’s “HTML & of the Week” website, reminding us that using container queries opens up container query units for si......

The Mistakes of CSS

Surely you have seen a CSS property and thought “Why?” For example:

Why doesn’t z-index work on all elements, and why is it “- index ” anyways?

Why do we need interpolate-size to animate to auto ?

You are not alone. CSS was born in 1996 (it can legally order a beer, you know!) and was initially considered a way to style documents; I don’t think anyone imagined everything CSS would be expected to do nearly 30 years later. If we had a time machine, many things would be done differently to match conventions or to make more sense. Heck, even the CSS Working Group admits to wanting a time-traveling contraption… in the specifications!

NOTE: If we had a time machine, this property wouldn’t need to exist. CSS Values and Units Module Level 5, Section [website].

If by some stroke of opportunity, I was given free rein to rename some things in CSS, a couple of ideas come to mind, but if you want more, you can find an ongoing list of mistakes made in CSS… by the CSS Working Group! Take, for example, background-repeat :

Not quite a mistake, because it was a reasonable default for the 90s, but it would be more helpful since then if background-repeat defaulted to no-repeat .

Right now, people are questioning if CSS Flexbox and CSS Grid should share more syntax in light of the upcoming CSS Masonry layout specifications.

Why not fix them? Sadly, it isn’t as easy as fixing something. People already built their websites with these quirks in mind, and changing them would break those sites. Consider it technical debt.

This is why I think the CSS Working Group deserves an onslaught of praise. Designing new capabilities that are immutable once shipped has to be a nerve-wracking experience that involves inexact science. It’s not that we haven’t seen the specifications change or evolve in the past — they most certainly have — but the value of getting things right the first time is a beast of burden.

APIs have steadily become the backbone of AI systems, connecting data and tools seamlessly. Discover how they can drive scalable and secure training f......

Ken Stott, Field CTO of API platform Hasura, tells Ryan about the data doom loop: the concept that organizations are spending lots of money on data sy......

Ben and Ryan chat with Babak Behzad, senior engineering manager at Verkada, about running a pipeline that vectorizes 25,000 images per second into a c......