[oe] [ALERT] Security vulnerability with recent OE bitbake.conf changes

[Justin Patrin]

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

Please, let's remove the gnome-terminal default, it makes no sense to
assume that the lowest common denominator is running bitbake from X...

-- 
Justin Patrin