Now it should be working, and we are in the time to start.
Oh, and where are the time to start?
So, I'll go around both on our next speaker.
I don't know if it's a time to start.
Stimbert and he's talk about that in every world.
Hi.
No margin at all here.
So, okay.
This is my work for Wolfe's Society.
I do curl all the time.
So, anyway, ask questions, but they do it afterwards because I don't.
And that's 25 minutes.
I'm going to talk fast and hopefully you'll understand it.
So, I'm going to talk about curl, of course.
Because I always talk about curl.
Curl is a little command line tool and a library.
For internet transfer or transferring stuff over internet protocols.
And we've been going on on this project for a while.
And over time, of course, sort of raised our ambitions or what to do in the project.
So, nowadays we just have this modest aim that we do everything the best possible way.
And when it comes to both security wise and open source wise.
So, pretty much, you know, crank everything up as much as possible.
And that's sort of the ambition here.
Sometimes, maybe we fail, but I think in general, we actually do pretty good job.
And to use an old XKCD, of course, because you have to do that when you have a slide.
So, it's really no problem, right?
Because we got you.
But, and how do we do that?
And I have a fun slide that I use to show where curl runs.
And when I do show this, it's kind of fun.
Because most models can not even mention 25 operating systems, right?
Because how could you?
And usually someone can always, anyway, find a few that is not included here.
But it's kind of a fun map.
So, it runs in a lot of places.
A lot of operating systems, basically any CPU architecture you can imagine.
More than one planet.
And so much.
And on anything you have, we have that connects to the internet, everyone's in a while.
It probably runs curl already or we'll run curls soon.
You know, cars, TVs, vehicles, play, games, stuff, printers, medical devices.
Well, anything, right?
We estimate that there's somewhere in the World Park of 20 billion installations of curl.
And I think it's really low estimate.
So, it's probably more.
But, you know, a crazy amount of curl everywhere.
So, it puts a little bit of a responsibility and a challenge for us, of course.
Sure, what happens when we ship a little bug in 20 billion installations?
But, of course, we write this in the safest possible language.
So, we have 180,000 lines of C code.
And actually, sometimes people think it's a lot or not a lot.
But, what is 180,000 lines of code?
Maybe it's not that big.
Maybe it is big.
Yeah, what do you, but it is 1.14 warrant piece if you count the words.
Warren piece is actually a pretty thick novel.
So, it's actually quite a lot of code I would say for what it is.
It transfers data.
Okay.
So, how do we make sure that we actually don't break,
or we don't have our hot bleed moment, or whatever you want to call the next problem?
So, we start out, of course, we host our stuff.
So, we host downloads, and we have everything.
On the CDN, everything is of course TLS.
We have everything there.
So, we have, make sure that we have a redundant websites.
It's actually pretty reliable to get data from the Chrome website.
It's like that is 99.95% of the CDNs.
And, of course, we have the source code entirely on the served on GitHub.
So, it's, we used to have a, for everyone.
We have 17 people who cannot push code to the repository.
I think we're about four or five, actually, do it regularly.
So, that's sort of the basic setup.
And then, of course, in the source code, how do we manage 180,000 types of code?
So, of course, we have reviews for whatever anyone wants to contribute.
Something, human comments and machine tools to verify.
We have a really strict code style these days.
It's actually been sort of started out really, really leading back in the days.
Nowadays, we have, it's really, it should look, as a single author has written a code.
I think it's really convenient because it makes it easy to read a code.
It looks and feels like it's written by a single person.
It makes it easier to find debugging and read code.
And, of course, we have these data also banned a bunch of desired functions
that in C is sort of easy to use the wrong way.
So, even, it doesn't really matter how experienced you are.
Some functions in the C standard is really not advisable to use a code.
And we have those, we check for them with tools.
We banned them so you can't really sneak them in by mistake you.
We also are, well, they're called reuse, compliance.
So, we have copyright and license information in every single file in the repository.
So, we should be completely covered in sort of understanding the provenance
and who owns what and what's the legal status of everything.
And we have a lot of documentation about this source code and internal APIs and everything.
And we have had multiple audits.
And when it comes to audits, that's fun.
We had, I was, I first external audits was made in 2016.
And they found, what resulted in 7 CVEs, back then.
It's a big task and it's an expensive thing to do.
What it's, someone is going to spend a lot of expensive hours looking at code.
We did one later in 2022, ended up in two CVEs.
I think it was also much more expensive.
But it, because things go more expensive over time.
And, but the result from that, of course.
And then we had another one in 2024 or more narrow,
because not all of what it's covered everything, right, 180,000 times.
So code is too much for a single audit.
But anyway, it resulted in zero CVEs.
So it's a little bit of a trend, I would say.
So yeah, super expensive.
So it's not, it's not something that's easy to be done right for a small open source project.
You have to have someone who just have a very deep pocket of suddenly wants this to happen.
And this, or this, three, or this, they have the cost of this,
have been much more than our entire bug bounty for many years.
That has resulted in many, many, many more CVEs.
Okay, so, of course, we have all of that to make sure that the code looks and feels right.
And then we have a lot of tests.
So of course, we want to make sure that all those 20 billion installations run fine.
We have, you know, unit tests, library tests and tool tests.
And we do test that the code style is right and the intent and, you know,
spelling even in code.
And we have a fun torture test, which I'm going to explain separately because I'm so happy about it.
And of course, we have the analyzers checking code all the time.
And we have a part of the Google, was a fast project.
So they keep passing parallel nonstop on Google hardware.
Excellent thing.
And then, of course, in the documentation.
I think a big part, to really get to the next level in when it comes to the documentation.
In a project is to make sure that the documentation is correct.
And we do that a lot with tools.
Not only spelling pros and, you know, using the right words.
Like, 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.
Then you get a red CI job if you try to write that.
As stuff like that, right?
Just, we're common spelling of words.
So make sure that everything is consistent and the wording is consistent.
The English is sort of written in a way that we think it should be.
And then, for example, we do have mandatory content.
So we do, for example, in the code project, we have over 500 man pages that we ship.
And every man page right that has to have a certain number of sections.
And the sections has to be in the right order.
And it should be in the correct thing.
They all have that checked, right?
And a proper man page for reliability.
It should have an example section, right?
An example section.
It's mandatory.
It should be there.
And how do you know it works, right?
Because we compile every example in every man page in library.
To make sure that it's actually compiling.
It might still be actually wrong because we can run it.
But it's still, as many checks to make sure that it's actually pretty good.
And of course, we verify links and references across man pages and stuff like that.
This actually makes sure that most of it is in a pretty decent shape.
And I wanted to just mention also our torture tests because I think they're pretty cool.
So we have sort of a set up.
So when you build curl with debug mode, so it's special build for a testing case.
We pretty much write a rat by for every fileable function that we want to monitor.
Right.
Maloch or Caloch or FO, blah, blah, blah.
And then we build curl with that.
And then we can control that from the outside.
So we build that and then we run the test case.
And we count how many fileable functions do we actually call?
So when we want to do like, I want to get a web page from a server with curl.
It downloads something.
It's, I don't know, 100 maloch calls and blah, blah, blah, something else.
So then we make sure that we iterate over the test case and we make every one of them.
100 maloch calls fail once, right?
First one, second one, third one.
And then rerun rerun rerun.
And then make sure that whatever fileable function that fails, it should just fail.
Nicely, no memory leak, no crash and just exit with an error code.
And that's an awesome way to test exit pass really.
And make sure that we always free up stuff and clean up stuff when we exit.
Whatever.
In a library it's pretty important that we never leak memory, right?
Because it's potentially used by very long running processes and whatever.
Right? And then it actually takes forever to run this on all tests.
It's not a fast process.
So we actually have to have a weird system to just randomly run a few of them and not fail.
Everyone of them just to make sure that we can actually run through them.
Because we have thousands of tests and some of these test cases that can easily do many, many thousands of
of function calls themselves that's there.
It can be a lot.
So when we have that, we have everything that's so we have of course run everything in CI.
So we now, of course.
And once when I mentioned CI, everyone has a particular idea of what a CI is.
In our project, we run CI.
It's just fine for get VMs.
They fire up.
They build the code.
They run the test cases and then they're done.
Then we throw them away.
So we never get anything back from them.
Really other than logs from test cases.
But anyway, we have a few thousands of tests to do per job.
And we do builds on as many platforms as we can.
Really that we have, you know, it's a little bit of a,
I mentioned 100 in six operating systems and 28 CPU effectures.
Really a little bit hard to run tests on all of those.
So we don't.
We sort of focus on a bunch of primary ones and the rest just has to work.
It usually works out really well because most of the code is perfect and portable.
And it's the same code anyways.
Most of the bugs appear on all of them.
Right.
We also.
Office support with a whole lot of different third party libraries.
Right. So there's literally millions of combinations of different TLS compression libraries and SSH libraries and
IDN libraries or whatever. So it makes for a.
Really really a lot of number of combinations too, which is also sort of.
Of course adds to the complication.
And we're about to see I stuff as.
Thing which makes a little bit of fuzzing.
It just in the CI run for a short period of time.
So when we have these CI, we run now more than 200 jobs per.
PR and commit.
It's a crazy amount of tests.
And because all of them have around 2,000 each.
So we're around 400,000 tests per PR and.
And commit so it's.
Still areas that we don't test very good, but.
At least we do a lot of testing.
And.
We have.
We spread this out over a number of different CI services just to make sure that we.
And it's.
So well it's a little bit way.
So it's a main trainer sort of a maximum parallelism so that we don't get
choked up by your single service.
It has been a little bit tweaked nowadays because.
We've been sponsored by GitHub. So they have sort of.
Race to volume for our performance and GitHub. So nowadays we sort of
favor GitHub because we can run more jobs.
They're faster than some of some of the others.
really within 20 minutes, 30 minutes, something.
So we work really, really hard to optimize and tweak
so that they actually finish really fast.
Just, I think, a year ago, they could take hours,
some of them.
But it's really convenient to have them finish really fast
that if we know the state of the latest changes right now.
And so we spend about 10 CPU days per day right now
in CI, only.
Right.
And the repository, there's a question other.
How much does it cost?
It costs us nothing.
It's entirely free.
No, no.
If we would pay for it, it would cost a fortune.
That's the easy answer.
So we don't pay for it.
As I said, we have sponsors paying for this.
So they provide this service for us.
So yes, we're happy that they do that.
Otherwise, it would be a challenge.
So we also have added checks, of course, the XZ way
that we don't have any binary blobs in the repository.
We actually have to see a job now to make sure that
no one can even, you know, buy mistake at a binary blob
and then we, because that'll fail your CI.
So there should be no way to hide any encrypted payloads
in our repository anyway.
We have all our, not all our commits are signed yet,
but we're sort of going most of them are.
And we'll, of course, sign tags and we signed releases.
And we have perfectly reproducible builds since a while back.
So it's really easy to whatever we ship.
Anyone is sort of encouraged and welcome to just reproduce
it to make sure that we didn't sneakishly insert anything
the XZ way or any other way.
I still build all the releases locally,
but nowadays, I use a container to do it.
It's actually easy to, for anyone else to use the same container.
And I just wanted to show you so you can actually do this.
So this is the latest kernel release.
If you just download that and you just figure out when I did the package
because you want the exact same time start, right?
And then you can just build the same package exactly the same way
and it'll end up a binary copy, right?
It'll be identical.
And you can even use the script that I've provided.
So you can actually just download it and you verify that is actually the same thing.
Which I think is fine.
I mean, it's not even that hard once you just get yourself to do it.
But I don't think it's fine.
It helps everyone to, anyone who wants to, can verify that.
That is actually, you can make the package the same way I did it.
Or wait for it.
And of course, we get vulnerabilities.
And we fixed them as soon as we can.
We look, this goes as we should.
And we document everything really, really thoroughly.
And I have this commitment.
I work really hard to make sure that the figure out exactly when we inserted the bag
and exactly when we fixed it.
So that I can tell that to the world.
Nowadays, we'll see in a, so that we can sort of manage our own.
See if it's a little bit better.
Less crazy stuff.
Ideally.
And we have this bag bounded to.
So we're paying researchers to report stuff.
Right.
About documentation the CV is done.
We do that really thoroughly.
We provided the metadata as JSON and we.
Document everything.
Of course, we don't provide a CVS score.
Which is awesome, because then someone else will do it for us.
And I mean, it's super crazy instead.
I won't get into why, but CVS.
I hope you all agree with me.
It's totally broken system.
So we're decided pretty much to not participate in.
In that dance.
So we get forced to participate in it anyway.
But still, that's that's the way we do it.
So for example, you can do this.
You can check out a curler version on website.
And they'll show you exactly which.
Vulnerability is it contains.
From version two version.
We can even get it in a nice graphic and overview.
Those versions have those vulnerabilities over time, blah, blah, blah.
And all those are clickable, of course.
So in the background, we have this started five and a half years ago.
Approaching 60 years, I think.
So we paid out more than $85,000 by now.
A small amount compared to those audits.
I mentioned previously.
It has resulted in 76 CVS.
Soon to be 79 CVS.
So it's a pretty good system.
15% success rate, then.
Of course, some of the others that we get are just ordinary bugs.
So we're not, I mean, not everything else is crap.
But there's a fair amount of that too.
And we always sort of disclose all of them after the facts.
So that you can follow the discussion and see whatever is silly decision we made.
And of course, we have a fun race with the rest of the world right now.
With the AI slot rate, sort of increasing in this amount.
We're actually right now.
We have this about the same rate of valid reports as in AI slot reports.
It's sort of in the same ballpark somewhere around 10%
15% of the submission.
Yeah.
And of course, I could do this talk without sort of showing this book cover because it's a popular book.
No one has really finished it or I've been told many times that it only takes a weekend to rewrite it.
But apparently that weekend hasn't happened yet.
So we're not going to rewrite it in any language.
We're not going to rewrite it at all.
It's there already.
So we're just patiently, you know, it's rating and polishing over time.
So there's not going to be any rewrite.
And when it comes to rust, it's a good effort.
It's a possibly good and great language, but we're not going to use it.
But we can still use third party dependencies with the new rust, right?
So if there's a TLS library or another library that we want to make curl use as part of its functionality.
Which is a TLS library, for example, is tend to be something you use with curl.
That could be written in rust and then we could use that.
So that's the way we're going to use.
I think we're going to see more rust in that kind of aspect going forward in curl.
So that's how we try to stay less in class and when it comes to security and open source.
Thank you.
There's a question.
How do I manage dependencies?
Sorry.
How do I manage dependencies?
Well, I have a sort of a kind of a fun or unfortunate position that I don't really have dependencies in that way.
Since I ship curl as a source code table, right?
So there's actually no dependencies there.
Here's the dependencies are managed by those who build curl and get a lot of dependencies when they decide what to build curl with and use.
So it's a little bit of a way for me to say that someone else's problem.
So I build curl someone else deals with the dependence problems.
When you say all commits are signed or nearly all commits are signed.
How do you handle external plural requests?
Do you write the commits?
Or do you pull them?
I always do rebase of commits.
Just a rewritten.
So when I merge someone else's commit, it'll be put and committed by me, right?
So it's going to be signed by me.
Do you measure code coverage?
And then look at new code introduced.
Code code coverage is really hard.
Yeah, so yeah, code coverage.
That's what's a question.
So it's really hard.
Yeah, I try to for a while.
But since curl is such a mess with different backgrounds, different dependencies and different options on and off.
It turns out to be really, really hard.
What does it mean?
What is code coverage, really?
Code coverage, it's out of what?
So it turned out to be a really weird number to get.
So I actually still, because it was really hard to even explain what we measured and how to use it.
And what do we want to communicate with it?
So no, I don't do that anymore.
I'm interested in your tool to test it.
How do you function on how many advice you have?
And do you generate the rough functions like manually?
So the torture set up, they monitor a bunch of fallible functions.
And we have written manual wrapper functions for them.
But because they don't tend to increase, right?
It's the same set.
It's basically monitor the memorallications file handling.
Yeah, that's pretty much it.
So it's limited sets.
They're like eight functions or something.
So it's a pretty narrow set.
And it's perfectly fixed.
So you mentioned there are some things such as LAPNs on carol.
Can you give example?
Yeah, see functions that are banning carol.
For example, well, gets or now, since they're while back, S scan F,
we don't allow.
We don't even use string copy anymore.
We, and a few other, of course, we don't use S print either.
Some other, more natural ones that's anyone I want to think about.
The reason for S scan F and string copy are the newer ones that we sort of avoid.
Because basically, most of these, we decided to stop to use because, sort of,
by experience, we see that we don't, they don't really add much.
When we add, when we use them, it tends to lead us into the wrong fixes, wrong solutions.
So we better, we write better code, we create better solutions by sort of forcing ourselves by avoiding those functions.
So you say you have 15, maybe.
How do I get new main trainers?
I don't know.
We all age, so do you have a plan?
Okay, well, yeah, the average age of the main trainers, it increases one year every year.
So, yeah, I don't know how to do that.
I get a band, that's a universal resource problem, right?
How do we recruit new main trainers and preferably younger main trainers?
So, I don't know, I don't have any good solution or answer to that.
My time is up, I have to stop.
Thank you.