[oe] [ALERT] Security vulnerability with recent OE bitbake.conf changes
papercrane at gmail.com
Mon May 7 06:29:26 CEST 2007
On 5/3/07, Richard Purdie <rpurdie at rpsys.net> wrote:
> On Thu, 2007-05-03 at 15:47 +0300, Paul Sokolovsky wrote:
> > Hello openembedded-devel,
> > A commit made some time ago,
> > http://lists.linuxtogo.org/pipermail/openembedded-commits/2007-April/004912.html
> > introduced a hole which may lead to unnoticed security vulnerabilities
> > slipping into the packages/images produced. Specifically, it defines a
> > random application of a random suite to be used for resolving patching
> > conflicts/failures. If you don't happen to have that random tool,
> > patching failure will be silently swallowed, leading to any adverse
> > effects imaginable - from compile failure to the mentioned security
> > vulnerabilities.
> Patch failure should not be silently swallowed, the builds should abort.
> If they don't, we need to fix that underlying problem.
> FWIW, your first solution using SHELLRCCMD won't actually work due to
> the way IO redirection is done in recent bitbake.
> Your second solution of adding the DEPENDS is impractical due to the
> amount of -native packages it would require.
> So we need to find the real problem and fix that, probably somewhere in
> patch.bbclass an error code isn't being propagated at a guess.
> I will also hint at the use of PATCH_RESOLVER = "noop" which means the
> user gets the old behaviour of patch failure aborts the build with no
> help from any resolver. It should have always been the default but
> wasn't. I'm not sure what the current default is but we can change it to
> that if its not.
Ummm...where? I tried that in my local.conf and it did nothing. I've
also grepped for PATCH_RESOLVER in both bitbake and oe and found
Please, let's remove the gnome-terminal default, it makes no sense to
assume that the lowest common denominator is running bitbake from X...
More information about the Openembedded-devel