OE-Core/Yocto Project's first CVE (CVE-2017-9731)

OE-Core/Yocto Project's first CVE (CVE-2017-9731)

[Richard Purdie]

I suspect this has been missed by some people so I want to spell it
out. We have our first CVE in OE-Core itself.

The issue is limited to binary ipks potentially exposing sensitive
information through the "Source:" field which contained the full
SRC_URI. Those urls could potentially contain sensitive information
about servers and credentials.

After discussion, I ended up changing the field to contain the recipe
filename (no path). There was talk of filtering the urls however if you
try, it becomes clear that sensitive elements can remain and no
solution is likely 100% effective. The other package backends don't do
this at all so this brings ipk more into line with them. Simply
clearing the field doesn't work with the current opkg-utils. It can be
changed but the change becomes more invasive.

This fix has been merged to master.

I also did take the decision to backport this change back to
pyro/morty/krogoth too. I appreciate this can cause some disruption to
people who rely on SRC_URI being in the Source: field however I
couldn't see any other realistic way forward.

Cheers,

Richard

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

[Philip Balister]

On 06/19/2017 06:38 AM, Richard Purdie wrote:
> I suspect this has been missed by some people so I want to spell it
> out. We have our first CVE in OE-Core itself.
> 
> The issue is limited to binary ipks potentially exposing sensitive
> information through the "Source:" field which contained the full
> SRC_URI. Those urls could potentially contain sensitive information
> about servers and credentials.

So the issue is leaking credentials, not build system paths? I mention
this because we do leak build system paths into images in other places.

Philip


> 
> After discussion, I ended up changing the field to contain the recipe
> filename (no path). There was talk of filtering the urls however if you
> try, it becomes clear that sensitive elements can remain and no
> solution is likely 100% effective. The other package backends don't do
> this at all so this brings ipk more into line with them. Simply
> clearing the field doesn't work with the current opkg-utils. It can be
> changed but the change becomes more invasive.
> 
> This fix has been merged to master.
> 
> I also did take the decision to backport this change back to
> pyro/morty/krogoth too. I appreciate this can cause some disruption to
> people who rely on SRC_URI being in the Source: field however I
> couldn't see any other realistic way forward.
> 
> Cheers,
> 
> Richard
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
> 

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

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 372 bytes --]

On 19 June 2017 at 14:20, Philip Balister <philip@balister.org> wrote:

> So the issue is leaking credentials, not build system paths? I mention
> this because we do leak build system paths into images in other places.
>

Yes, SRC_URI can contain username/passwords, and even if you filter those
out explicitly you can expose internal hostnames and so on.

Ross

[-- Attachment #2: Type: text/html, Size: 775 bytes --]

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

[Philip Balister]

On 06/19/2017 09:29 AM, Burton, Ross wrote:
> On 19 June 2017 at 14:20, Philip Balister <philip@balister.org> wrote:
> 
>> So the issue is leaking credentials, not build system paths? I mention
>> this because we do leak build system paths into images in other places.
>>
> 
> Yes, SRC_URI can contain username/passwords, and even if you filter those
> out explicitly you can expose internal hostnames and so on.

But we do expose internal host names in other places ...

Philip

> 
> Ross
> 

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

[Mark Hatle]

On 6/19/17 8:20 AM, Philip Balister wrote:
> On 06/19/2017 06:38 AM, Richard Purdie wrote:
>> I suspect this has been missed by some people so I want to spell it
>> out. We have our first CVE in OE-Core itself.
>>
>> The issue is limited to binary ipks potentially exposing sensitive
>> information through the "Source:" field which contained the full
>> SRC_URI. Those urls could potentially contain sensitive information
>> about servers and credentials.
> 
> So the issue is leaking credentials, not build system paths? I mention
> this because we do leak build system paths into images in other places.

Build systems paths would be unrelated to this, assuming I understand it properly.

Information leak of the build user, time of build, and build system paths can
all occur.  (This is part of the overall binary reproducible stuff as well.)

When it comes to information leaks, specifically build system leaks.  As long as
they don't contain credential information then it is a point of mitigation vs a
'bug' in my opinion.  We clearly want to move toward a binary reproducible build
-- doing so will further limit the leaks (or at least make them understood.)

For build user, hostname, directories and build time/date issues -- we've
already mitigated many of them.  Directory structure was done when we started to
use the compilers path replacement operations.  (It's probably not 100%
effective, but I'd say any items that are left are reasonable bug candidates.)
We've also made passes to remove many of the other items, but I'd simply
consider them regular bugs at this point...  but information leaks like this are
something people often don't think about and probably should be made aware of.

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

Controlling your 'production' build environment can mitigate many of the
potential issues here.  By using non-confidential path names (i.e. don't include
confidential 'customer', code-name, etc in build paths), changing or otherwise
managing the host name on your build system (i.e. instead of
my-product.my-company.internal.com... something like 'build-1' as a hostname can
help hide many of these things.)  Using a 'build user' who doesn't have any
network credentials, other then on the build system itself...

--Mark

> Philip
> 
> 
>>
>> After discussion, I ended up changing the field to contain the recipe
>> filename (no path). There was talk of filtering the urls however if you
>> try, it becomes clear that sensitive elements can remain and no
>> solution is likely 100% effective. The other package backends don't do
>> this at all so this brings ipk more into line with them. Simply
>> clearing the field doesn't work with the current opkg-utils. It can be
>> changed but the change becomes more invasive.
>>
>> This fix has been merged to master.
>>
>> I also did take the decision to backport this change back to
>> pyro/morty/krogoth too. I appreciate this can cause some disruption to
>> people who rely on SRC_URI being in the Source: field however I
>> couldn't see any other realistic way forward.
>>
>> Cheers,
>>
>> Richard
>> _______________________________________________
>> Openembedded-architecture mailing list
>> Openembedded-architecture@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>>
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
> 

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

[Mark Hatle]

On 6/19/17 5:38 AM, Richard Purdie wrote:
> I suspect this has been missed by some people so I want to spell it
> out. We have our first CVE in OE-Core itself.
> 
> The issue is limited to binary ipks potentially exposing sensitive
> information through the "Source:" field which contained the full
> SRC_URI. Those urls could potentially contain sensitive information
> about servers and credentials.

Does any of the 'archiver' output include copies/versions of the full SRC_URI?
Same with the license management parts... (I don't think either do) but these
would be the places I'd think the SRC_URI might also be.

--Mark

> After discussion, I ended up changing the field to contain the recipe
> filename (no path). There was talk of filtering the urls however if you
> try, it becomes clear that sensitive elements can remain and no
> solution is likely 100% effective. The other package backends don't do
> this at all so this brings ipk more into line with them. Simply
> clearing the field doesn't work with the current opkg-utils. It can be
> changed but the change becomes more invasive.
> 
> This fix has been merged to master.
> 
> I also did take the decision to backport this change back to
> pyro/morty/krogoth too. I appreciate this can cause some disruption to
> people who rely on SRC_URI being in the Source: field however I
> couldn't see any other realistic way forward.
> 
> Cheers,
> 
> Richard
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
> 

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

[Sean Hudson]

[-- Attachment #1.1: Type: text/plain, Size: 4522 bytes --]

On 2017-06-19 09:05 AM, Mark Hatle wrote:
> On 6/19/17 8:20 AM, Philip Balister wrote:
>> On 06/19/2017 06:38 AM, Richard Purdie wrote:
>>> I suspect this has been missed by some people so I want to spell it
>>> out. We have our first CVE in OE-Core itself.
>>>
>>> The issue is limited to binary ipks potentially exposing sensitive
>>> information through the "Source:" field which contained the full
>>> SRC_URI. Those urls could potentially contain sensitive information
>>> about servers and credentials.
>>
>> So the issue is leaking credentials, not build system paths? I mention
>> this because we do leak build system paths into images in other places.
> 
> Build systems paths would be unrelated to this, assuming I understand it properly.
> 
> Information leak of the build user, time of build, and build system paths can
> all occur.  (This is part of the overall binary reproducible stuff as well.)
> 
> When it comes to information leaks, specifically build system leaks.  As long as
> they don't contain credential information then it is a point of mitigation vs a
> 'bug' in my opinion.  We clearly want to move toward a binary reproducible build
> -- doing so will further limit the leaks (or at least make them understood.)
> 
> For build user, hostname, directories and build time/date issues -- we've
> already mitigated many of them.  Directory structure was done when we started to
> use the compilers path replacement operations.  (It's probably not 100%
> effective, but I'd say any items that are left are reasonable bug candidates.)
> We've also made passes to remove many of the other items, but I'd simply
> consider them regular bugs at this point...  but information leaks like this are
> something people often don't think about and probably should be made aware of.
> 
> 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?

> 
> Controlling your 'production' build environment can mitigate many of the
> potential issues here.  By using non-confidential path names (i.e. don't include
> confidential 'customer', code-name, etc in build paths), changing or otherwise
> managing the host name on your build system (i.e. instead of
> my-product.my-company.internal.com... something like 'build-1' as a hostname can
> help hide many of these things.)  Using a 'build user' who doesn't have any
> network credentials, other then on the build system itself...
> 
> --Mark
> 
>> Philip
>>
>>
>>>
>>> After discussion, I ended up changing the field to contain the recipe
>>> filename (no path). There was talk of filtering the urls however if you
>>> try, it becomes clear that sensitive elements can remain and no
>>> solution is likely 100% effective. The other package backends don't do
>>> this at all so this brings ipk more into line with them. Simply
>>> clearing the field doesn't work with the current opkg-utils. It can be
>>> changed but the change becomes more invasive.
>>>
>>> This fix has been merged to master.
>>>
>>> I also did take the decision to backport this change back to
>>> pyro/morty/krogoth too. I appreciate this can cause some disruption to
>>> people who rely on SRC_URI being in the Source: field however I
>>> couldn't see any other realistic way forward.
>>>
>>> Cheers,
>>>
>>> Richard
>>> _______________________________________________
>>> Openembedded-architecture mailing list
>>> Openembedded-architecture@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>>>
>> _______________________________________________
>> Openembedded-architecture mailing list
>> Openembedded-architecture@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>>
> 
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
> 


-- 
Sean


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Paul Eggleton]

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.

FWIW it's not quite the same thing but some of what you might want to do when
moving to production is described in this section of the manual (which, full
disclosure, I had a hand in writing):

  http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#making-images-more-secure

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

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

[Sean Hudson]

[-- Attachment #1.1: Type: text/plain, Size: 1554 bytes --]

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.


-- 
Sean


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [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

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

[Richard Purdie]

On Tue, 2017-06-20 at 08:27 -0500, Sean Hudson 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.

We can certainly do this, its technically not an issue. My worry is
that if gives false security feelings since you can easily expose
hostnames or other information as well as credentials. Where do we
stop?

We could go as far as to stop bitbake supporting usernames/passwords in
urls. There are some usecases where that is useful though...

Cheers,

Richard

Re: OE-Core/Yocto Project's first CVE (CVE-2017-9731)

[Sona Sarmadi]

Hi all,

Sorry that the fix/workaround for this vulnerability was not discussed publically. 
This vulnerability was reported by a user privately/encrypted. Yocto Security team; 
Sona, Michael Halstead and Richard handled this off-list. We decided that we provide
a quick fix/workaround before we make this vulnerability public and then change/
improve it later if necessary. 
 
> I suspect this has been missed by some people so I want to spell it out. We
> have our first CVE in OE-Core itself.

We have received a CVE from Mitre for this vulnerability, but they have changed 
our description of vulnerability of some unknown reason :) we have requested an
update/correction (see below) but they haven't changed the description yet: 
 

From: CVE Request [mailto:CVE-Request@mitre.org] 
Sent: Monday, June 19, 2017 12:09 PM
To: Sona Sarmadi <sona.sarmadi@enea.com>
Subject: CVE Request 349461 for Update Published CVE 

Thank you for your submission. It will be reviewed by a CVE Assignment Team member.
 
You have requested an update to the following published CVE:  CVE-2017-9731
 
 
Changes, additions, or updates to your request can be sent to the CVE Team by replying directly to this email.
 
Please do not change the subject line, which allows us to effectively track your request.
 
CVE Assignment Team 
M/S M300, 202 Burlington Road, Bedford, MA 01730 USA 
[A PGP key is available for encrypted communications at 
http://cve.mitre.org/cve/request_id.html]

Thanks all for your help with this vulnerability.
//Sona

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

[Scott Murray]

On Mon, 19 Jun 2017, Richard Purdie wrote:

> I suspect this has been missed by some people so I want to spell it
> out. We have our first CVE in OE-Core itself.
>
> The issue is limited to binary ipks potentially exposing sensitive
> information through the "Source:" field which contained the full
> SRC_URI. Those urls could potentially contain sensitive information
> about servers and credentials.
>
> After discussion, I ended up changing the field to contain the recipe
> filename (no path). There was talk of filtering the urls however if you
> try, it becomes clear that sensitive elements can remain and no
> solution is likely 100% effective. The other package backends don't do
> this at all so this brings ipk more into line with them. Simply
> clearing the field doesn't work with the current opkg-utils. It can be
> changed but the change becomes more invasive.
>
> This fix has been merged to master.
>
> I also did take the decision to backport this change back to
> pyro/morty/krogoth too. I appreciate this can cause some disruption to
> people who rely on SRC_URI being in the Source: field however I
> couldn't see any other realistic way forward.

I noticed that this wasn't CC'ed to the yocto-security mailing list.
Was that just an oversight, or should that mailing list be considered
defunct at this point?

Thanks,

Scott

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

[Richard Purdie]

On Wed, 2017-06-28 at 13:38 -0400, Scott Murray wrote:
> On Mon, 19 Jun 2017, Richard Purdie wrote:
> 
> > 
> > I suspect this has been missed by some people so I want to spell it
> > out. We have our first CVE in OE-Core itself.
> > 
> > The issue is limited to binary ipks potentially exposing sensitive
> > information through the "Source:" field which contained the full
> > SRC_URI. Those urls could potentially contain sensitive information
> > about servers and credentials.
> > 
> > After discussion, I ended up changing the field to contain the
> > recipe
> > filename (no path). There was talk of filtering the urls however if
> > you
> > try, it becomes clear that sensitive elements can remain and no
> > solution is likely 100% effective. The other package backends don't
> > do
> > this at all so this brings ipk more into line with them. Simply
> > clearing the field doesn't work with the current opkg-utils. It can
> > be
> > changed but the change becomes more invasive.
> > 
> > This fix has been merged to master.
> > 
> > I also did take the decision to backport this change back to
> > pyro/morty/krogoth too. I appreciate this can cause some disruption
> > to
> > people who rely on SRC_URI being in the Source: field however I
> > couldn't see any other realistic way forward.
> I noticed that this wasn't CC'ed to the yocto-security mailing list.
> Was that just an oversight, or should that mailing list be considered
> defunct at this point?

Sorry, it was oversight...

Cheers,

Richard

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

[Scott Murray]

On Thu, 29 Jun 2017, Richard Purdie wrote:

> On Wed, 2017-06-28 at 13:38 -0400, Scott Murray wrote:
> > On Mon, 19 Jun 2017, Richard Purdie wrote:
> >
> > >
> > > I suspect this has been missed by some people so I want to spell it
> > > out. We have our first CVE in OE-Core itself.
> > >
> > > The issue is limited to binary ipks potentially exposing sensitive
> > > information through the "Source:" field which contained the full
> > > SRC_URI. Those urls could potentially contain sensitive information
> > > about servers and credentials.
> > >
> > > After discussion, I ended up changing the field to contain the
> > > recipe
> > > filename (no path). There was talk of filtering the urls however if
> > > you
> > > try, it becomes clear that sensitive elements can remain and no
> > > solution is likely 100% effective. The other package backends don't
> > > do
> > > this at all so this brings ipk more into line with them. Simply
> > > clearing the field doesn't work with the current opkg-utils. It can
> > > be
> > > changed but the change becomes more invasive.
> > >
> > > This fix has been merged to master.
> > >
> > > I also did take the decision to backport this change back to
> > > pyro/morty/krogoth too. I appreciate this can cause some disruption
> > > to
> > > people who rely on SRC_URI being in the Source: field however I
> > > couldn't see any other realistic way forward.
> >
> > I noticed that this wasn't CC'ed to the yocto-security mailing list.
> > Was that just an oversight, or should that mailing list be considered
> > defunct at this point?
>
> Sorry, it was oversight...

Okay, good to know.  IMO it might be worthwhile to post it there even if
it's a bit late, just to set a precedent of that list providing such
information, but it's your call.

Cheers,

Scott