[Buildroot] [PATCH v5 0/3] Add tainting support to buildroot

[Angelo Compagnucci]

Yann, All
On Sun, Sep 9, 2018 at 3:20 PM Yann E. MORIN <yann.morin.1998 at free.fr> wrote:
>
> Angelo, All,
>
> On 2018-09-09 14:44 +0100, Angelo Compagnucci spake thusly:
> > On Sun, Sep 9, 2018 at 2:33 PM Yann E. MORIN <yann.morin.1998 at free.fr> wrote:
> > > On 2018-09-09 13:25 +0100, Angelo Compagnucci spake thusly:
> > > > On Sun, Sep 9, 2018 at 1:10 PM Thomas Petazzoni
> > > > <thomas.petazzoni at bootlin.com> wrote:
> > > [--SNIP--]
> > > > Thomas said evrithing exceptionally well, but I would like to
> > > > underling another thing: automated building infrastructures like
> > > > continuos integration.
> > > >
> > > > If a project hasa nedd of reproducibility, the countinous integration
> > > > could check if a random developer introduced something not
> > > > reproducible and mark the build as invalid. I think this is really a
> > > > big plus of this solution.
> > >
> > > I do understand the concern, trust me, I do.
> > >
> > > What I am saying is that the solution you propose will not allow that,
> > > because there is no way to decide whether a specific .config is or is
> > > not reproducible, as per the examples I provided in the nodejs case.
> > >
> > > If a build is imprperly marked as tainted, then users will just
> > > disregard that information and never consult it, and just not use it in
> > > their automated buildsystemsd (jenkins, gitlab-ci, whatever). And even
> > > if they do have a job doing the check, that job can detect a change from
> > > "not tainted" to "tainted" because the job will always report "tainted".
> >
> > My concern here is that you start from a reproducible build, add your
> > packages right and so maintain your build reproducible, buildroot will
> > work as before.
>
> So you are, like I am, in fact arguing that we should have actual packages
> for such external modules? ;-)

I can't see any value on having hundreds of npm packages probably
outdated at wich you should add hundreds of php composer packages, go
modules, cargo packages and so on.

>> > As soon you use a package manager tainting will be
> > signaled.
>
> This is where I disagree.
>
> Using such package managers does not imply that the build is tainted.
> This is a false dichotomy.

Probably it is but my experience says not, anyway, if you are dealing
with a complex php software for example you can:
* call php composer manually on the modules you are sure being
reproducible in your .mk and live happy
* use the package host-composer distributed with buildroot asking it
to do a "composer install" living with the fact that it could do
anything and you build will be tainted.

> > Taint is mean to signal that there is a potential problem, and if you
> > don't want to slip into it, you can always do the right thing and
> > package your software and packaging also it's dependencies.
>
> And what I am saying is that the heuristic you suggest to decide whether
> a build should be considered tainted or not is incorrect.

It's not an heuristic, it's a rule: you ask to a package manager to
resolve your dependencies, your build _could_ be tainted. You want to
be sure: you write your own rule.
If you write a clean mk that does everything right you shouldn't add
FOO_TAINTS, that's it.

I can agree with you that some packages could be considered first
class citizens, the others based on package managers could not be as
good as first ones. But at least, you give the tools to developers who
wants to add a non trivial web package or similar to buildroot.

What I'm saying here is that we don't have such a rule we simply
cannot add any time soon any software based on package managers.

Probably there is some other smarter way to do it that I cannot see ...

I'm open to suggestions!

>
> > As soon as you do this, the taint disappear. I thin it could even be a
> > deterrent to package the software randomly!
>
> Regards,
> Yann E. MORIN.
>
> --
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
> | +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
> '------------------------------^-------^------------------^--------------------'