[Buildroot] [PATCH v5 0/3] Add tainting support to buildroot
Angelo Compagnucci
angelo.compagnucci at gmail.com
Mon Sep 10 17:10:30 UTC 2018
Yann, All,
Il giorno lun 10 set 2018 alle ore 17:00 Yann E. MORIN
<yann.morin.1998 at 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
More information about the buildroot
mailing list