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

[Yann E. MORIN]

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? ;-)

> 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.

> 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.

> 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.  |
'------------------------------^-------^------------------^--------------------'