You start exactly a couple of steps.
No, no.
Hi, everyone.
I'm Citroen.
Unfortunately, my colleague Thomas could be here today,
so we're presenting the LCS program for Bidwood.
So in the nutshell, what's Bidwood?
It's an embedded build system for Linux devices.
Very easy, based on make and kick on fix,
so you just make a different pick,
then simply customize your build.
Finally, make and obtain a flushable image for your embedded Linux device.
How it works?
It's a mailing list-based contribution workflow,
so you write patches on your computer,
then send them on the mailing list.
They will be reviewed by the maintainers,
and ultimately, apply to the master branch,
which is maybe a flatter process than the Linux kernel.
So historically,
the Bidwood development has four release per year,
one in February, just after first them,
and then one in May, August and November.
And the one from February was supported from one year,
which is kind of an LCS already.
And all of this, like releasing and trying to keep the release up to date's work,
was carried by one maintainer.
So he was doing a lot of things on this free time.
Yeah, lots of work.
So we thought that works from the Gid perspective,
so we tag a release on master,
and then as security fixes land on master,
we carry big them on the LCS or on the branches,
and tag new release ahead.
But since February 25,
the two, we know have an LCS support for three years,
so we have longer-term support release.
So the objectives of this program is first of all,
having a longer-term support release,
and having one year of all-appearance period,
so we have one new three-year LCS every two years.
Also, we have no systematic capability tracking
and reporting for all the Bidwood packages.
And also, we have some sponsors, LCS two-ups,
who gets actually release on a Bid-time to work on that program.
And also, these people will make sure that if there's a security fix,
that's not an inversion or something,
this security fix could be but bought it,
accordingly, in the affected packages.
So this gives us the following recycling.
So we are going to pick the 25-the-two cycle.
All the other ones are quarterly,
and we can expect that in the 27,
we will have the 26-the-two, yeah, the following one.
How would that work?
In the back of this, I would say.
So every Monday, one of us will tag one,
the latest commercial master,
so we have a referendum point,
all the commits to review for that switch.
Then, by the beginning of the week,
we review all commits, one by one,
that have been applied to master.
And we annotate them using Gitnotes.
So this is a distributed workflow.
So to know which one should be,
cherry picks into which branches,
according to which secret fix are in there,
or which one are applicable.
Then, one maintainer will synchronize that
and upstream it on the LCS branch.
And as soon as it's data,
we have some automatic workflows
that will date the vulnerability status of the roots.
So if you want to help us maintain the LCS in good shape,
there are a few gay lines I could say.
So if you have a security bump for instance,
please mark it explicitly in the back,
you sent to the mailing list.
This makes the LCS maintenance a lot easier.
And also, if you know that there's CV number
or a vulnerability reference,
you can link, please put it in the commit message.
Again, this is very helpful to move forward
and avoid losing some information.
This is also a general idea.
So it's applicable to any project that if you have a commit
that fix an issue, which is not a vulnerability,
but something that comes from the project itself,
please link them in the commit message as well.
Also, this is useful, but general guideline.
Do this in every project actually.
And finally, if you have a package bump,
so you bump to a newer version which introduces new features,
but still, one previous version had fixed and security issue.
Please try to split the patch into,
so it's again easier for us to backport the correct
secretifix in the correct branches.
So, I mentioned that we also have some systematic vulnerability reporting.
So since 25 to 2, we have a tool called Generate Cycle Index,
which, if you give it a good information of your build,
it will give you a nest bump in Cycle Index format.
And since the latest, if the two release,
we also have improved the CV check inside the root.
Which is an existing script.
Such that it can enrich directly the Cycle Index S1
to include all the very, very thin information.
And with all this tuning, we have,
now we can have all the branches from the root that are supported.
We patch them through the S1 Generator, CV check,
then with some custom cooking, we create a website,
which is hosted on security.dood.org.
And this is a data to every day.
So you get an up to date representation of all the packages in the root,
and what's the version, what are the known vulnerabilities,
and stuff like that.
So, why should you sponsor the early test program then?
So, first we will help ensure that there are some long-term sustainability
for the build root project, that you can get some reliable packages
that are supported.
You get some contact with the LTS2 routes, so me and other people.
Also, you can get some personalized security reports,
which are companies interested into that,
and also you get a recognition of your sponsorship on the LTS2 sites.
Just a small graph.
In one year, we reviewed approximately almost 4,000 commits.
Of them, about a third, has been chirping into one of the LTS
or quarterly support branch,
and this allows us to fix more than 300 vulnerabilities.
So we see the graph on the right.
This is just on the horizontal axis.
You have the commit date, so when the commit was made on Master,
and then you have the number of commits backported on the branch,
and the vertical lines indicate a bit root releases.
So the big root LTS2 reduces.
So you can see there's a constant inflow of commits.
Some of them are actually happening around large conferences,
but you see the general idea that there's some activity there.
So thanks everyone for attending first.
Thanks to a sponsor that make this program possible.
If you want to know more, we can visit those websites.
Also, if you think that you're employer or company,
whatever would be interested to help in this program,
I have some business cards.
We can take home and spread the message.
Thank you very much.