WEBVTT

00:00.000 --> 00:10.000
You start exactly a couple of steps.

00:10.000 --> 00:12.000
No, no.

00:12.000 --> 00:14.000
Hi, everyone.

00:14.000 --> 00:15.000
I'm Citroen.

00:15.000 --> 00:17.000
Unfortunately, my colleague Thomas could be here today,

00:17.000 --> 00:21.000
so we're presenting the LCS program for Bidwood.

00:21.000 --> 00:23.000
So in the nutshell, what's Bidwood?

00:23.000 --> 00:26.000
It's an embedded build system for Linux devices.

00:26.000 --> 00:29.000
Very easy, based on make and kick on fix,

00:29.000 --> 00:32.000
so you just make a different pick,

00:32.000 --> 00:34.000
then simply customize your build.

00:34.000 --> 00:39.000
Finally, make and obtain a flushable image for your embedded Linux device.

00:39.000 --> 00:41.000
How it works?

00:41.000 --> 00:43.000
It's a mailing list-based contribution workflow,

00:43.000 --> 00:46.000
so you write patches on your computer,

00:46.000 --> 00:48.000
then send them on the mailing list.

00:48.000 --> 00:50.000
They will be reviewed by the maintainers,

00:50.000 --> 00:52.000
and ultimately, apply to the master branch,

00:52.000 --> 00:56.000
which is maybe a flatter process than the Linux kernel.

00:57.000 --> 01:00.000
So historically,

01:00.000 --> 01:04.000
the Bidwood development has four release per year,

01:04.000 --> 01:06.000
one in February, just after first them,

01:06.000 --> 01:11.000
and then one in May, August and November.

01:11.000 --> 01:16.000
And the one from February was supported from one year,

01:16.000 --> 01:19.000
which is kind of an LCS already.

01:19.000 --> 01:24.000
And all of this, like releasing and trying to keep the release up to date's work,

01:24.000 --> 01:27.000
was carried by one maintainer.

01:27.000 --> 01:31.000
So he was doing a lot of things on this free time.

01:31.000 --> 01:33.000
Yeah, lots of work.

01:33.000 --> 01:36.000
So we thought that works from the Gid perspective,

01:36.000 --> 01:39.000
so we tag a release on master,

01:39.000 --> 01:42.000
and then as security fixes land on master,

01:42.000 --> 01:46.000
we carry big them on the LCS or on the branches,

01:46.000 --> 01:49.000
and tag new release ahead.

01:50.000 --> 01:53.000
But since February 25,

01:53.000 --> 01:56.000
the two, we know have an LCS support for three years,

01:56.000 --> 02:00.000
so we have longer-term support release.

02:00.000 --> 02:03.000
So the objectives of this program is first of all,

02:03.000 --> 02:05.000
having a longer-term support release,

02:05.000 --> 02:08.000
and having one year of all-appearance period,

02:08.000 --> 02:12.000
so we have one new three-year LCS every two years.

02:12.000 --> 02:15.000
Also, we have no systematic capability tracking

02:15.000 --> 02:18.000
and reporting for all the Bidwood packages.

02:18.000 --> 02:22.000
And also, we have some sponsors, LCS two-ups,

02:22.000 --> 02:27.000
who gets actually release on a Bid-time to work on that program.

02:27.000 --> 02:32.000
And also, these people will make sure that if there's a security fix,

02:32.000 --> 02:34.000
that's not an inversion or something,

02:34.000 --> 02:36.000
this security fix could be but bought it,

02:36.000 --> 02:39.000
accordingly, in the affected packages.

02:39.000 --> 02:42.000
So this gives us the following recycling.

02:42.000 --> 02:46.000
So we are going to pick the 25-the-two cycle.

02:46.000 --> 02:49.000
All the other ones are quarterly,

02:49.000 --> 02:53.000
and we can expect that in the 27,

02:53.000 --> 02:58.000
we will have the 26-the-two, yeah, the following one.

02:58.000 --> 03:01.000
How would that work?

03:01.000 --> 03:03.000
In the back of this, I would say.

03:03.000 --> 03:06.000
So every Monday, one of us will tag one,

03:06.000 --> 03:08.000
the latest commercial master,

03:08.000 --> 03:10.000
so we have a referendum point,

03:10.000 --> 03:13.000
all the commits to review for that switch.

03:13.000 --> 03:16.000
Then, by the beginning of the week,

03:16.000 --> 03:18.000
we review all commits, one by one,

03:18.000 --> 03:20.000
that have been applied to master.

03:20.000 --> 03:23.000
And we annotate them using Gitnotes.

03:23.000 --> 03:25.000
So this is a distributed workflow.

03:25.000 --> 03:28.000
So to know which one should be,

03:28.000 --> 03:30.000
cherry picks into which branches,

03:30.000 --> 03:32.000
according to which secret fix are in there,

03:32.000 --> 03:34.000
or which one are applicable.

03:34.000 --> 03:38.000
Then, one maintainer will synchronize that

03:38.000 --> 03:41.000
and upstream it on the LCS branch.

03:41.000 --> 03:43.000
And as soon as it's data,

03:43.000 --> 03:45.000
we have some automatic workflows

03:45.000 --> 03:50.000
that will date the vulnerability status of the roots.

03:50.000 --> 03:55.000
So if you want to help us maintain the LCS in good shape,

03:55.000 --> 03:59.000
there are a few gay lines I could say.

03:59.000 --> 04:01.000
So if you have a security bump for instance,

04:01.000 --> 04:03.000
please mark it explicitly in the back,

04:03.000 --> 04:04.000
you sent to the mailing list.

04:04.000 --> 04:09.000
This makes the LCS maintenance a lot easier.

04:09.000 --> 04:12.000
And also, if you know that there's CV number

04:12.000 --> 04:15.000
or a vulnerability reference,

04:15.000 --> 04:17.000
you can link, please put it in the commit message.

04:17.000 --> 04:20.000
Again, this is very helpful to move forward

04:20.000 --> 04:23.000
and avoid losing some information.

04:23.000 --> 04:26.000
This is also a general idea.

04:26.000 --> 04:29.000
So it's applicable to any project that if you have a commit

04:29.000 --> 04:32.000
that fix an issue, which is not a vulnerability,

04:32.000 --> 04:36.000
but something that comes from the project itself,

04:36.000 --> 04:39.000
please link them in the commit message as well.

04:39.000 --> 04:42.000
Also, this is useful, but general guideline.

04:42.000 --> 04:44.000
Do this in every project actually.

04:44.000 --> 04:47.000
And finally, if you have a package bump,

04:47.000 --> 04:51.000
so you bump to a newer version which introduces new features,

04:51.000 --> 04:55.000
but still, one previous version had fixed and security issue.

04:55.000 --> 04:58.000
Please try to split the patch into,

04:58.000 --> 05:01.000
so it's again easier for us to backport the correct

05:01.000 --> 05:04.000
secretifix in the correct branches.

05:05.000 --> 05:10.000
So, I mentioned that we also have some systematic vulnerability reporting.

05:10.000 --> 05:15.000
So since 25 to 2, we have a tool called Generate Cycle Index,

05:15.000 --> 05:19.000
which, if you give it a good information of your build,

05:19.000 --> 05:24.000
it will give you a nest bump in Cycle Index format.

05:24.000 --> 05:29.000
And since the latest, if the two release,

05:29.000 --> 05:33.000
we also have improved the CV check inside the root.

05:33.000 --> 05:36.000
Which is an existing script.

05:36.000 --> 05:40.000
Such that it can enrich directly the Cycle Index S1

05:40.000 --> 05:44.000
to include all the very, very thin information.

05:44.000 --> 05:47.000
And with all this tuning, we have,

05:47.000 --> 05:51.000
now we can have all the branches from the root that are supported.

05:51.000 --> 05:55.000
We patch them through the S1 Generator, CV check,

05:55.000 --> 05:58.000
then with some custom cooking, we create a website,

05:58.000 --> 06:01.000
which is hosted on security.dood.org.

06:02.000 --> 06:04.000
And this is a data to every day.

06:04.000 --> 06:07.000
So you get an up to date representation of all the packages in the root,

06:07.000 --> 06:10.000
and what's the version, what are the known vulnerabilities,

06:10.000 --> 06:13.000
and stuff like that.

06:13.000 --> 06:16.000
So, why should you sponsor the early test program then?

06:16.000 --> 06:20.000
So, first we will help ensure that there are some long-term sustainability

06:20.000 --> 06:24.000
for the build root project, that you can get some reliable packages

06:24.000 --> 06:25.000
that are supported.

06:25.000 --> 06:29.000
You get some contact with the LTS2 routes, so me and other people.

06:30.000 --> 06:33.000
Also, you can get some personalized security reports,

06:33.000 --> 06:35.000
which are companies interested into that,

06:35.000 --> 06:41.000
and also you get a recognition of your sponsorship on the LTS2 sites.

06:41.000 --> 06:43.000
Just a small graph.

06:43.000 --> 06:48.000
In one year, we reviewed approximately almost 4,000 commits.

06:48.000 --> 06:52.000
Of them, about a third, has been chirping into one of the LTS

06:52.000 --> 06:54.000
or quarterly support branch,

06:54.000 --> 06:58.000
and this allows us to fix more than 300 vulnerabilities.

06:58.000 --> 07:00.000
So we see the graph on the right.

07:00.000 --> 07:03.000
This is just on the horizontal axis.

07:03.000 --> 07:06.000
You have the commit date, so when the commit was made on Master,

07:06.000 --> 07:10.000
and then you have the number of commits backported on the branch,

07:10.000 --> 07:13.000
and the vertical lines indicate a bit root releases.

07:13.000 --> 07:16.000
So the big root LTS2 reduces.

07:16.000 --> 07:20.000
So you can see there's a constant inflow of commits.

07:20.000 --> 07:24.000
Some of them are actually happening around large conferences,

07:24.000 --> 07:30.000
but you see the general idea that there's some activity there.

07:30.000 --> 07:33.000
So thanks everyone for attending first.

07:33.000 --> 07:36.000
Thanks to a sponsor that make this program possible.

07:36.000 --> 07:39.000
If you want to know more, we can visit those websites.

07:39.000 --> 07:42.000
Also, if you think that you're employer or company,

07:42.000 --> 07:45.000
whatever would be interested to help in this program,

07:45.000 --> 07:46.000
I have some business cards.

07:46.000 --> 07:49.000
We can take home and spread the message.

07:49.000 --> 07:50.000
Thank you very much.

07:50.000 --> 07:55.000
Thank you very much.