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

[Paul Sokolovsky <pmiscml@gmail.com>]

Hello Richard,

Thursday, May 3, 2007, 4:16:39 PM, you 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.


[]

> Is there really any need for this?
> It doesn't encourage me to give a sensible reply, does it...

        Apparently no. But for me, it's pretty clear that even
gnome-terminal shouldn't be used by default, and in expectation of
hardnesses regarding arguing this, I tried to draw picturesquely
absurd "extension", overspiced with few buzzwords. It's of course a
mere small bug otherwise, but I truly looking for solution which won't
by default trouble KDE, other WMs, and classy console guys in favor of
GNOME crowd.


> Patch failure should not be silently swallowed, the builds should abort.
> If they don't, we need to fix that underlying problem.

        Yes, I didn't even bother to ruin my pamphlet with such
down-to-earth triviality ;-). I'd be looking into it as time permits
of course.

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

        Ack, and vote for. Let's have defaults not overloaded with
interactivity, and working along the lines of standard unix/posix
build tools. Frontends, likes one(s) you work on, can have own
config/overrides then. (And few people won't used them anyway, no
matter which potential benefits they give - and not out of
bare-commandline orthodoxy, but because they may have other frontends
relying on classical unix behavior of tools).

> Cheers,

> Richard



-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com