All of lore.kernel.org
 help / color / mirror / Atom feed
From: Angelo Compagnucci <angelo.compagnucci@gmail.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v5 0/3] Add tainting support to buildroot
Date: Mon, 10 Sep 2018 19:10:30 +0200	[thread overview]
Message-ID: <CA+TH9Vm1m+xUC3NydquYNw67SCFLNYvi_rqufxVw3BTtmOS=xQ@mail.gmail.com> (raw)
In-Reply-To: <20180910150009.GA2674@scaer>

Yann, All,
Il giorno lun 10 set 2018 alle ore 17:00 Yann E. MORIN
<yann.morin.1998@free.fr> ha scritto:
>
> Angelo, All,
>
> On 2018-09-10 09:50 +0200, Angelo Compagnucci spake thusly:
> > > Last one, I promise!
> [--SNIP--]
> > I just pushed o POC on my local branch if you want to have a look.
> > It's what I mean for tainting applied to a package with a more robust
> > ad correct approach that the npm case:
> > https://github.com/angeloc/buildroot/commits/watchtower
>
> So, here is my last stance on the subject, in which I tried to summarise
> my position.
>
> Why would the "tainted" flag be set?
>
>   - unknown licensing information: it is better to use the existing
>     licensing infrastructure, which is made for this very purpose:
>     FOO_LICENSE := $(FOO_LICENSE), Unknown (external data used)
>
>   - non-reproducible packages in Buildroot: I don't think we should
>     accept packages in Buildroot that would taint the build; and if we
>     were, we could hide them behind !BR2_REPRODUCIBLE (with or without
>     a comment stating "foo is not reproducible");
>
>   - packages that are in a br2-external, or in a private fork: I believe
>     that people who do non-reproducible packages either don't care,
>     have no choice, or both. If they did care, they would not create
>     tainting packages; if they did care but still had no choice, they
>     could also decide to hide them behind !BR2_REPRODUCIBLE;
>
>   - packages with a list of external resources, like we have for
>     nodejs/npm: we can't know if that list references reproducible
>     resources or not.
>
> That last point is very important: there *are* people that do care about
> the reproduciblity of a build, and thus have already taken care that
> BR2_PACKAGE_NODEJS_MODULES_ADDITIONAL *does* point to stable and
> reproducible set of nodejs modules [0]. Patch 3 in the series would mark
> for them that the build is tainted when it is not; since those people do
> care, the tainted flag would be most important to them, but by always
> marking their build as tainted, the flag becomes useless to the very
> people that do care...
>
> Yes, a lot of people will just use a non-stable list, and they even
> probably do not care either. I do not want to have to impose that
> limitation unto those who know what they are doing.
>
> So, I still conclude that we do not need to have a tainted flag.

I can agree with you, but what do you propose for handling package
managers: Simply put a !BR2_REPRODUCIBLE for a package that needs
dependencies resolved and cannot handle dependencies cleanly?

>
> [0] For example, consider an explicit and complete list such as (spitted
>     for readability):
>         BR2_PACKAGE_NODEJS_MODULES_ADDITIONAL="
>             http://internal-server/node/mod-1
>             http://internal-server/node/mod-2
>             http://internal-server/node/mod-3
>             http://internal-server/node/mod-4
>         "
>     and that all the dependencies of those modules *are* present in that
>     list, leaving npm no chance to download anything.

As I said previously, hiding npm inside nodejs is wrong. What if you
have a couple nodejs based software and for one you have a clear
picture of dependencies but not for the other?
Npm should decoupled and used each time a nodejs software needs it.

This is what I did with watchtower:

+################################################################################
+#
+# watchtower
+#
+################################################################################
+
+WATCHTOWER_VERSION = v0.3.0
+WATCHTOWER_SITE = $(call github,v2tec,watchtower,$(WATCHTOWER_VERSION))
+WATCHTOWER_LICENSE = Apache-2.0
+WATCHTOWER_LICENSE_FILES = LICENSE.md
+WATCHTOWER_DEPENDENCIES = host-glide
+WATCHTOWER_TAINTS = YES
+
+define WATCHTOWER_RESOLVE_DEPS
+cd $(WATCHTOWER_SRC_PATH) && GOPATH="$(@D)/$(WATCHTOWER_WORKSPACE)"
$(HOST_DIR)/usr/bin/glide install
+endef
+
+WATCHTOWER_POST_CONFIGURE_HOOKS = WATCHTOWER_RESOLVE_DEPS
+
+$(eval $(golang-package))

This clearly mark watchtower as a tainting package, but it doesn't
harm any other package that could use host-glide.


>
> 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.  |
> '------------------------------^-------^------------------^--------------------'
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot



-- 
Profile: http://it.linkedin.com/in/compagnucciangelo

  parent reply	other threads:[~2018-09-10 17:10 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-05 22:22 [Buildroot] [PATCH v5 0/3] Add tainting support to buildroot Angelo Compagnucci
2018-09-05 22:22 ` [Buildroot] [PATCH v5 1/3] Makefile: add tainting support Angelo Compagnucci
2018-09-06  7:44   ` Thomas Petazzoni
2018-09-06  7:46     ` Angelo Compagnucci
2018-09-05 22:22 ` [Buildroot] [PATCH v5 2/3] docs/manual: adding infos about tainting Angelo Compagnucci
2018-09-09  8:00   ` Yann E. MORIN
2018-09-05 22:22 ` [Buildroot] [PATCH v5 3/3] package/nodejs: taint the build on external modules Angelo Compagnucci
2018-09-09  7:49   ` Yann E. MORIN
2018-09-09 12:17     ` Angelo Compagnucci
2018-09-09 13:01       ` Yann E. MORIN
2018-09-09 13:29         ` Angelo Compagnucci
2018-09-06  7:42 ` [Buildroot] [PATCH v5 0/3] Add tainting support to buildroot Thomas Petazzoni
2018-09-09  7:36 ` Yann E. MORIN
2018-09-09 12:10   ` Thomas Petazzoni
2018-09-09 12:25     ` Angelo Compagnucci
2018-09-09 13:33       ` Yann E. MORIN
2018-09-09 13:44         ` Angelo Compagnucci
2018-09-09 14:20           ` Yann E. MORIN
2018-09-09 16:58             ` Angelo Compagnucci
2018-09-09 18:55               ` Yann E. MORIN
2018-09-09 20:18                 ` Angelo Compagnucci
2018-09-10  7:50                   ` Angelo Compagnucci
2018-09-10 15:00                     ` Yann E. MORIN
2018-09-10 15:37                       ` Yann E. MORIN
2018-09-10 17:10                       ` Angelo Compagnucci [this message]
2018-09-10 18:07                         ` Yann E. MORIN
2018-09-10 19:17                           ` Angelo Compagnucci
2018-09-10 19:43                             ` Yann E. MORIN
2018-09-10 20:03                               ` Angelo Compagnucci
2018-09-10 20:26                                 ` Yann E. MORIN
2018-09-11  6:20                                   ` Angelo Compagnucci
2018-09-10 19:37                           ` Thomas Petazzoni
2018-09-10 19:55                             ` Angelo Compagnucci
2018-09-10 20:37                             ` Yann E. MORIN
2018-09-09 13:27     ` Yann E. MORIN
2018-11-01 12:14 ` Arnout Vandecappelle
2018-11-01 12:25   ` Yann E. MORIN

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+TH9Vm1m+xUC3NydquYNw67SCFLNYvi_rqufxVw3BTtmOS=xQ@mail.gmail.com' \
    --to=angelo.compagnucci@gmail.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.