[Buildroot] Buildroot LTS?

[Buildroot] Buildroot LTS?

[Chris Simmonds]

Hi,

Is there a long term support policy for Buildroot? For example, when the
next significant bug like heartbleed or shellshock comes along, how do I
best incorporate the fix in my Buildroot project?

Looking through the commit history, I gather that Buildroot is a
"rolling release". There are stable releases several times per year, but
there are few updates once it is released. So, the way to get security
fixes would be to update to the latest stable release: is that correct?
The downside is that that will bring in many changes in addition to
fixing security bugs and I may have to go through a new QA cycle.

I would be interested in any comments on the above. What do Buildroot
users do in practice? Does any 3rd party offer LTS support for Buildroot?

Best regards,
Chris Simmonds

[Buildroot] Buildroot LTS?

[Thomas Petazzoni]

Hello Chris,

On Fri, 30 Oct 2015 09:22:38 +0000, Chris Simmonds wrote:

> Is there a long term support policy for Buildroot? For example, when the
> next significant bug like heartbleed or shellshock comes along, how do I
> best incorporate the fix in my Buildroot project?
> 
> Looking through the commit history, I gather that Buildroot is a
> "rolling release". There are stable releases several times per year, but
> there are few updates once it is released. So, the way to get security
> fixes would be to update to the latest stable release: is that correct?
> The downside is that that will bring in many changes in addition to
> fixing security bugs and I may have to go through a new QA cycle.
> 
> I would be interested in any comments on the above. What do Buildroot
> users do in practice? Does any 3rd party offer LTS support for Buildroot?

There is currently no long term support policy for the community
maintained Buildroot. We have discussed this topic a few times during
our meetings, as I remember raising the question of whether we should
maintain for a longer period certain specific releases of Buildroot, at
least to take care of the security problems.

So far, our common reaction was that it is rather time-consuming to do
and also not very exciting for volunteers to do. It is the type of
topic that would really be helped if there was some funding from
companies.

That being said, if there is sufficient interest for this, and
developers willing to look at the security issues and submit the
corresponding patches, I'm sure we'd be happy to create such LTS
releases from time to time.

Currently, Buildroot users have two options:

 * Stick to a given Buildroot version, and take care of the security
   updates themselves.

 * Update their Buildroot version, but this as you said has the
   consequence of updating many components in the system, even when the
   update is not strictly necessary from a security point of view.

I would personally be happy to take patches against a given fixed
version of Buildroot, and do regularly some point releases based on
this version. But there need to be some involvement from the interested
users.

As far as security updates provided by third party companies, I guess
several embedded Linux services company would probably be willing to
provide such services. But there is no formal/public offering as far as
I know.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Buildroot LTS?

[Arnout Vandecappelle]

On 30-10-15 14:58, Thomas Petazzoni wrote:
> Hello Chris,
> 
> On Fri, 30 Oct 2015 09:22:38 +0000, Chris Simmonds wrote:
> 
>> Is there a long term support policy for Buildroot? For example, when the
>> next significant bug like heartbleed or shellshock comes along, how do I
>> best incorporate the fix in my Buildroot project?
[snip]
>> I would be interested in any comments on the above. What do Buildroot
>> users do in practice? Does any 3rd party offer LTS support for Buildroot?
> 
> There is currently no long term support policy for the community
> maintained Buildroot. We have discussed this topic a few times during
> our meetings, as I remember raising the question of whether we should
> maintain for a longer period certain specific releases of Buildroot, at
> least to take care of the security problems.
[snip]
> I would personally be happy to take patches against a given fixed
> version of Buildroot, and do regularly some point releases based on
> this version. But there need to be some involvement from the interested
> users.
> 
> As far as security updates provided by third party companies, I guess
> several embedded Linux services company would probably be willing to
> provide such services. But there is no formal/public offering as far as
> I know.

 We (Mind) would be happy to do that. The problem is that you need a certain
critical mass of paying customers before it becomes affordable. Also, it's not
only about security updates, but also a certain level of QA would be required.
Also, most packages don't have stable security branches but just apply security
updates to their single release branch, so the question is if we would do a
complete version bump or maintain patches like real distroes do.

 Another question is if we would take along Buildroot infrastructural changes or
not. These normally only have an impact on the build process, not the runtime,
so it should be OK to take them along in long term support. And it is often
useful because it adds development features, like the BR2_EXTERNAL support. But
of course, it's extra effort to include those as well.

 Regards,
 Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] Buildroot LTS?

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 >> I would be interested in any comments on the above. What do Buildroot
 >> users do in practice? Does any 3rd party offer LTS support for Buildroot?

 > There is currently no long term support policy for the community
 > maintained Buildroot. We have discussed this topic a few times during
 > our meetings, as I remember raising the question of whether we should
 > maintain for a longer period certain specific releases of Buildroot, at
 > least to take care of the security problems.

 > So far, our common reaction was that it is rather time-consuming to do
 > and also not very exciting for volunteers to do. It is the type of
 > topic that would really be helped if there was some funding from
 > companies.

Indeed, so far nobody has volunteered to do such work.

 > That being said, if there is sufficient interest for this, and
 > developers willing to look at the security issues and submit the
 > corresponding patches, I'm sure we'd be happy to create such LTS
 > releases from time to time.

Certainly. We already do bugfix releases (like 2015.08.1) for important
issues discovered after release. I have no problems doing more of those,
but people have to submit patches and/or point out what patches on
master also applies to the bugfix release.

-- 
Bye, Peter Korsgaard

[Buildroot] Buildroot LTS?

[Gustavo Zacarias]

On 31/10/15 06:01, Peter Korsgaard wrote:

>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
>
> Hi,
>
>   >> I would be interested in any comments on the above. What do Buildroot
>   >> users do in practice? Does any 3rd party offer LTS support for Buildroot?
>
>   > There is currently no long term support policy for the community
>   > maintained Buildroot. We have discussed this topic a few times during
>   > our meetings, as I remember raising the question of whether we should
>   > maintain for a longer period certain specific releases of Buildroot, at
>   > least to take care of the security problems.
>
>   > So far, our common reaction was that it is rather time-consuming to do
>   > and also not very exciting for volunteers to do. It is the type of
>   > topic that would really be helped if there was some funding from
>   > companies.
>
> Indeed, so far nobody has volunteered to do such work.

Hi.
A bit late to the talk, but still relevant i think.
I think this is the biggest issue, at least for me it doesn't sound too 
interesting, i generally live with the bleeding-edge (master), and 
recommend people to use the latest release or master.
It's the fact that it's all volunteer work that makes LTS releases a 
tough cookie to deliver.

>   > That being said, if there is sufficient interest for this, and
>   > developers willing to look at the security issues and submit the
>   > corresponding patches, I'm sure we'd be happy to create such LTS
>   > releases from time to time.
>
> Certainly. We already do bugfix releases (like 2015.08.1) for important
> issues discovered after release. I have no problems doing more of those,
> but people have to submit patches and/or point out what patches on
> master also applies to the bugfix release.

Security bumps are, in general, well tagged with i think my defacto 
standard:

$ git log --grep="security bump"|grep Author|sort|uniq
Author: Baruch Siach <xxx>
Author: Bernd Kuhls <xxx>
Author: Gustavo Zacarias <xxx>
Author: J?rg Krause <xxx>
Author: Peter Korsgaard <xxx>
Author: Yann E. MORIN <xxx>

That being said it's just a first step towards LTS releases.
Though some other security fixes might sneak-in via regular bumps 
without being tagged or looking close enough at the release notes.
With some previous experience with these things it depends very much on 
the package and how long-term the release support window is to choose if 
it's best to patch or bump.
And also what would constitute grounds for a release? One security fix? 
If it's periodic it might be too late for a security fix, hence possibly 
some cumulative periodic release plus some way of notifying when patches 
are applied (separate ML? rss feed? users checking the git repo?).
Too many things to say at once :)
Regards.

[Buildroot] Buildroot LTS?

[Thomas Petazzoni]

Hello,

On Fri, 6 Nov 2015 12:35:47 -0300, Gustavo Zacarias wrote:

> A bit late to the talk, but still relevant i think.
> I think this is the biggest issue, at least for me it doesn't sound too 
> interesting, i generally live with the bleeding-edge (master), and 
> recommend people to use the latest release or master.

Right, but it's very often not do-able to real-life projects/products.
I gave a Buildroot training this week for a company, and they are stuck
with Buildroot 2012.05. No BR2_EXTERNAL, no dependency graph, no legal
info, none of the goodness we've added over the last 3 years. And of
course, almost no security updates (though they fixed some of the big
ones).

> Security bumps are, in general, well tagged with i think my defacto 
> standard:
> 
> $ git log --grep="security bump"|grep Author|sort|uniq
> Author: Baruch Siach <xxx>
> Author: Bernd Kuhls <xxx>
> Author: Gustavo Zacarias <xxx>
> Author: J?rg Krause <xxx>
> Author: Peter Korsgaard <xxx>
> Author: Yann E. MORIN <xxx>
> 
> That being said it's just a first step towards LTS releases.
> Though some other security fixes might sneak-in via regular bumps 
> without being tagged or looking close enough at the release notes.

Yes, but to me very much like how current package bumps are done, those
LTS releases could simply be based on feedback/contribution. In those
LTS releases, we do not guarantee that *all* packages have been fixed
for *all* known security problems. We only releases an updated
Buildroot which has fixes for the security issues which were reported
to the Buildroot community and for which patches were submitted.

Basically, it's just to avoid having everybody duplicating the same
work, and have a central place to push the security fixes.

> With some previous experience with these things it depends very much on 
> the package and how long-term the release support window is to choose if 
> it's best to patch or bump.
> And also what would constitute grounds for a release? One security fix? 
> If it's periodic it might be too late for a security fix, hence possibly 
> some cumulative periodic release plus some way of notifying when patches 
> are applied (separate ML? rss feed? users checking the git repo?).

I don't think it's needed to have a super strict policy on this. We
could act a bit like the LTS kernel releases: release from time to
time, unless there is some kind of urgent/major security issue, in
which case you can do a release sooner.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com