[OE-core] [Openembedded-architecture] OE-Core/Yocto Project's first CVE (CVE-2017-9731)

[Paul Eggleton]

On Tuesday, 20 June 2017 3:27:15 PM CEST you wrote:
> On 2017-06-20 04:30 AM, Paul Eggleton wrote:
> > On Monday, 19 June 2017 5:31:10 PM CEST Sean Hudson wrote:
> >> On 2017-06-19 09:05 AM, Mark Hatle wrote:
> >>> It would be reasonable to write up a 'best practices' type document. 
> >>> Explaining that simply due to the nature of building many of these
> >>> things will be 'leaked' and where some of them are leaked through.
> >>> (Package generation, compilation, etc for instance.)
> >>
> >> That sounds reasonable, although, TBH, if someone is adding credentials
> >> to their SRC_URIs, I would expect that a best practice would be ignored.
> >>  Perhaps adding a detection routine that emitted a warning during
> >> parsing for credentials in the SRC_URI might be warranted?  Thoughts?
> > 
> > This might be useful yes. I think the stumbling block is that at the
> > moment we would have to have it off by default and then the user is almost
> > certainly not going to know to turn it on. Perhaps this is another thing 
> > that we might check in a "production" vs. "development" mode where the
> > user can easily switch to the former to enable a set of more stringent 
> > checks.
> 
> I'm not sure I follow.  What would prevent us from turning on a warning
> that detected credentials in a SRC_URI by default?  Even with Richard's
> change to prevent the information from propagating into the .ipk, it
> seems useful to notify the user.  Personally, I'd like to know if one of
> the recipes I'm using has such information in it regardless of whether
> I'm generating a development or a production image.

You might, sure, but if you're in an environment where during development your 
source is on a server requiring such credentials then it's going to be a bit 
annoying to keep seeing that warning.

Anyway, there's certainly no harm in adding such a check, whether it's on by 
default or not is a separate issue.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre