We've had concerns about the default behaviours of tools like git and how
they'll handle the default branch names going forward. There are also concerns
about what providers like github may do, and the potential impact on our tools
like recipetool.
A bug was filed about some of this:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14185
I am frustrated not much has moved forward with some of the inclusive language
work and this bug is languishing too.
We do aim to be explicit with our SRC_URI entries so having the branch specified
would seem to be the overall best thing to do here. I have done what was
suggested in the bug and sent out patches to add a warning to the fetcher and
updated the urls in OE-Core to include the branch name.
The harder part of these changes is discussing and explaining them and putting
transition plans in place. I am trying to do that here (and I will also mention
in the next tech call and in the weekly status report).
In the patch I've proposed there is a script, similar to the overrides
conversion one which converts metadata to add the branch name explicitly. It is
far from perfect but should probably help in the majority of cases.
If there aren't objections I'll likely merge the core change. The warning change
will follow in a week or two once at least the layers being tested on the
autobuilder have updated. I'm worried a ton of warnings suddenly showing up
would mask out other real issues.

I suspect we'll see selftest failures as the dict of url parameters may lead to
non-deterministic urls from recipetool but as ever, I'll try and work through
the issues.
Cheers,
Richard

On 29.10.21 15:09, Richard Purdie wrote:

We've had concerns about the default behaviours of tools like git and how
they'll handle the default branch names going forward. There are also concerns
about what providers like github may do, and the potential impact on our tools
like recipetool.

A bug was filed about some of this:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=14185

I am frustrated not much has moved forward with some of the inclusive language
work and this bug is languishing too.

We do aim to be explicit with our SRC_URI entries so having the branch specified
would seem to be the overall best thing to do here. I have done what was
suggested in the bug and sent out patches to add a warning to the fetcher and
updated the urls in OE-Core to include the branch name.

The harder part of these changes is discussing and explaining them and putting
transition plans in place. I am trying to do that here (and I will also mention
in the next tech call and in the weekly status report).

In the patch I've proposed there is a script, similar to the overrides
conversion one which converts metadata to add the branch name explicitly. It is
far from perfect but should probably help in the majority of cases.

If there aren't objections I'll likely merge the core change. The warning change
will follow in a week or two once at least the layers being tested on the
autobuilder have updated. I'm worried a ton of warnings suddenly showing up
would mask out other real issues.

Although the situation is a bit unfortunate I like the proposal and the
script will likely make the transition less painful.
Are you planning to turn the warning into an error at some point?

There is even bigger issue with git repos from github.com now:

Hi,

On Tue, 2 Nov 2021, at 10:32, Martin Jansa wrote:

There is even bigger issue with git repos from github.com now:

I don't think this is a bigger issue because I don't see this warranting a default change. It is just an upstream protocol support change and we will update the respective recipes. If we don't, January will force us to. Maybe, we should have a warning in git fetcher for GitLab on the git protocol? I reckon it is reasonable to push people to update their recipes.

Hi,

On Tue, 2 Nov 2021, at 10:32, Martin Jansa wrote:

There is even bigger issue with git repos from github.com now:


I don't think this is a bigger issue because I don't see this warranting a default change. It is just an upstream protocol support change and we will update the respective recipes. If we don't, January will force us to. Maybe, we should have a warning in git fetcher for GitLab on the git protocol? I reckon it is reasonable to push people to update their recipes.

Regards,
Andrei

There is even bigger issue with git repos from github.com now:

https://github.blog/2021-09-01-improving-git-protocol-security-github/#no-more-unauthenticated-git

bitbake git fetcher uses git:// protocol by default and as of today you can
experience "short brownouts" and on January 11 it will all fail to fetch (and
only fully populated PREMIRRORS can save you for a while, until SRCREV is
updated).

Short statistics from current oe-core/master:
martin@jama:/OE/openembedded-core$ git grep git://github.* | grep -v protocol=
| wc -l
52
martin@jama:/OE/openembedded-core$ git grep git://github.*protocol=https | wc
-l
20
martin@jama:/OE/openembedded-core$ git grep git://github.*protocol=git | wc -l
2

54 from 74 recipes will fail to fetch in oe-core only.

On Tue, Nov 2, 2021 at 12:46 PM Richard Purdie <richard.purdie@...> wrote:

On Tue, 2021-11-02 at 11:32 +0100, Martin Jansa wrote:

> There is even bigger issue with git repos from github.com now:

>

> https://github.blog/2021-09-01-improving-git-protocol-security-github/#no-more-unauthenticated-git

>

> bitbake git fetcher uses git:// protocol by default and as of today you can

> experience "short brownouts" and on January 11 it will all fail to fetch (and

> only fully populated PREMIRRORS can save you for a while, until SRCREV is

> updated).

>

> Short statistics from current oe-core/master:

> martin@jama:/OE/openembedded-core$ git grep git://github.* | grep -v protocol=

> | wc -l

> 52

> martin@jama:/OE/openembedded-core$ git grep git://github.*protocol=https | wc

> -l

> 20

> martin@jama:/OE/openembedded-core$ git grep git://github.*protocol=git | wc -l

> 2

>

> 54 from 74 recipes will fail to fetch in oe-core only.

Thanks for reporting this, it helps to know this is happening as we'll probably

start seeing odd error reports for the brownouts.

The brownouts are already happening, got 20+ failed jenkins jobs over night, because they failed to fetch various metadata layers over git:// from github. And hopefully my understanding of the announcement is correct and git:// brownouts are planned only for today.

 

I've updated the conversion script I mentioned earlier in this thread to handle

remapping the github.com urls too and also fixed the few corner cases I found

after the first conversion. I've sent those patches to OE-Core.

Thanks!, looks good to me.

For the older releases, rather than trying to rewrite all the urls, I think we

may want to patch bitbake to correctly handle the github urls specifically.

Considering how many people I've seen complaining about new overrides syntax breaking their just updated oe-core/dunfell build, just because they don't update bitbake revision it might be safer to do both (so that at least the maintained layers get the explicit protocol=https in SRC_URIs and the not-so-well-maintained layers could be saved by git fetcher changing the protocol automagically).

On Tue, 2 Nov 2021, at 11:52, Martin Jansa wrote:

On Tue, Nov 2, 2021 at 12:46 PM Richard Purdie
<richard.purdie@...> wrote:

On Tue, 2021-11-02 at 11:32 +0100, Martin Jansa wrote:
 > There is even bigger issue with git repos from github.com now:
 >
 >
https://github.blog/2021-09-01-improving-git-protocol-security-github/#no-more-unauthenticated-git
 >
 > bitbake git fetcher uses git:// protocol by default and as of today you
can
 > experience "short brownouts" and on January 11 it will all fail to
fetch (and
 > only fully populated PREMIRRORS can save you for a while, until SRCREV
is
 > updated).
 >
 > Short statistics from current oe-core/master:
 > martin@jama:/OE/openembedded-core$ git grep git://github.* | grep -v
protocol=
 > | wc -l
 > 52
 > martin@jama:/OE/openembedded-core$ git grep
git://github.*protocol=https | wc
 > -l
 > 20
 > martin@jama:/OE/openembedded-core$ git grep git://github.*protocol=git
| wc -l
 > 2
 >
 > 54 from 74 recipes will fail to fetch in oe-core only.
 
 Thanks for reporting this, it helps to know this is happening as we'll
probably
 start seeing odd error reports for the brownouts.

The brownouts are already happening, got 20+ failed jenkins jobs over night,
because they failed to fetch various metadata layers over git:// from
github. And hopefully my understanding of the announcement is correct and
git:// brownouts are planned only for today.
 

I've updated the conversion script I mentioned earlier in this thread to
handle
 remapping the github.com urls too and also fixed the few corner cases I
found
 after the first conversion. I've sent those patches to OE-Core.

Thanks!, looks good to me.

For the older releases, rather than trying to rewrite all the urls, I
think we
 may want to patch bitbake to correctly handle the github urls
specifically.

Considering how many people I've seen complaining about new overrides syntax
breaking their just updated oe-core/dunfell build, just because they don't
update bitbake revision it might be safer to do both (so that at least the
maintained layers get the explicit protocol=https in SRC_URIs and the not-
so-well-maintained layers could be saved by git fetcher changing the
protocol automagically).

I totally agree with that. I still think we should also warn out so we don't
have to maintain this magic quirk forever.

On Tue, 2021-11-02 at 11:56 +0000, Andrei Gherzan wrote:

On Tue, 2 Nov 2021, at 11:52, Martin Jansa wrote:

On Tue, Nov 2, 2021 at 12:46 PM Richard Purdie
<richard.purdie@...> wrote:

On Tue, 2021-11-02 at 11:32 +0100, Martin Jansa wrote:
 > There is even bigger issue with git repos from github.com now:
 >
 >
https://github.blog/2021-09-01-improving-git-protocol-security-github/#no-more-unauthenticated-git
 >
 > bitbake git fetcher uses git:// protocol by default and as of today you
can
 > experience "short brownouts" and on January 11 it will all fail to
fetch (and
 > only fully populated PREMIRRORS can save you for a while, until SRCREV
is
 > updated).
 >
 > Short statistics from current oe-core/master:
 > martin@jama:/OE/openembedded-core$ git grep git://github.* | grep -v
protocol=
 > | wc -l
 > 52
 > martin@jama:/OE/openembedded-core$ git grep
git://github.*protocol=https | wc
 > -l
 > 20
 > martin@jama:/OE/openembedded-core$ git grep git://github.*protocol=git

wc -l

 > 2
 >
 > 54 from 74 recipes will fail to fetch in oe-core only.
 
 Thanks for reporting this, it helps to know this is happening as we'll
probably
 start seeing odd error reports for the brownouts.

The brownouts are already happening, got 20+ failed jenkins jobs over night,
because they failed to fetch various metadata layers over git:// from
github. And hopefully my understanding of the announcement is correct and
git:// brownouts are planned only for today.
 

I've updated the conversion script I mentioned earlier in this thread to
handle
 remapping the github.com urls too and also fixed the few corner cases I
found
 after the first conversion. I've sent those patches to OE-Core.

Thanks!, looks good to me.

For the older releases, rather than trying to rewrite all the urls, I
think we
 may want to patch bitbake to correctly handle the github urls
specifically.

Considering how many people I've seen complaining about new overrides syntax
breaking their just updated oe-core/dunfell build, just because they don't
update bitbake revision it might be safer to do both (so that at least the
maintained layers get the explicit protocol=https in SRC_URIs and the not-
so-well-maintained layers could be saved by git fetcher changing the
protocol automagically).

I totally agree with that. I still think we should also warn out so we don't
have to maintain this magic quirk forever.

I think we put a warning on master and forwards but not older bitbakes.

On Tue, 2021-11-02 at 12:32 +0000, Richard Purdie via lists.openembedded.org
wrote:

On Tue, 2021-11-02 at 11:56 +0000, Andrei Gherzan wrote:

On Tue, 2 Nov 2021, at 11:52, Martin Jansa wrote:

On Tue, Nov 2, 2021 at 12:46 PM Richard Purdie
<richard.purdie@...> wrote:

On Tue, 2021-11-02 at 11:32 +0100, Martin Jansa wrote:
> There is even bigger issue with git repos from github.com now:
>
>
https://github.blog/2021-09-01-improving-git-protocol-security-github/#no-more-unauthenticated-git
>
> bitbake git fetcher uses git:// protocol by default and as of today you
can
> experience "short brownouts" and on January 11 it will all fail to
fetch (and
> only fully populated PREMIRRORS can save you for a while, until SRCREV
is
> updated).
>
> Short statistics from current oe-core/master:
> martin@jama:/OE/openembedded-core$ git grep git://github.* | grep -v
protocol=
> | wc -l
> 52
> martin@jama:/OE/openembedded-core$ git grep
git://github.*protocol=https | wc
> -l
> 20
> martin@jama:/OE/openembedded-core$ git grep git://github.*protocol=git

wc -l

> 2
>
> 54 from 74 recipes will fail to fetch in oe-core only.

Thanks for reporting this, it helps to know this is happening as we'll
probably
start seeing odd error reports for the brownouts.

The brownouts are already happening, got 20+ failed jenkins jobs over night,
because they failed to fetch various metadata layers over git:// from
github. And hopefully my understanding of the announcement is correct and
git:// brownouts are planned only for today.

I've updated the conversion script I mentioned earlier in this thread to
handle
remapping the github.com urls too and also fixed the few corner cases I
found
after the first conversion. I've sent those patches to OE-Core.

Thanks!, looks good to me.

For the older releases, rather than trying to rewrite all the urls, I
think we
may want to patch bitbake to correctly handle the github urls
specifically.

Considering how many people I've seen complaining about new overrides syntax
breaking their just updated oe-core/dunfell build, just because they don't
update bitbake revision it might be safer to do both (so that at least the
maintained layers get the explicit protocol=https in SRC_URIs and the not-
so-well-maintained layers could be saved by git fetcher changing the
protocol automagically).

I totally agree with that. I still think we should also warn out so we don't
have to maintain this magic quirk forever.

I think we put a warning on master and forwards but not older bitbakes.

I've sent out a couple of patches for bitbake, one which does the remapping and
a second which adds the warning. Testing would be appreciated before I merge
them (I need to focus on master first).

Cheers,

Richard

Can we change bitbake fetcher to default to https instead git
anonymous protocol as fallback? this will be good security measure
too.

On Tue, 2021-11-02 at 08:16 -0700, Khem Raj wrote:

Can we change bitbake fetcher to default to https instead git
anonymous protocol as fallback? this will be good security measure
too.

Some servers out there (e.g. our own git.yoctoproject.org) have slightly
different git and https urls so this isn't as simple as you'd think.

The security offered by https isn't as great as it first sounds when you
consider most of our recipes do have the revisions coded into them so whilst you
can break into a protocol stream, you do also have to correctly spoof the
revision too which is much harder. As such, only floating SRCREV recipes are at
risk from the connection encryption in our case.

Whether we should switch more of our urls over to https is a different question.
There is an open bug asking for this to happen for all the git.yoctoproject.org
urls since https is easier on firewalls but I've never really wanted to do make
the change, believing that people do need to get their network setup correctly
anyway. I did also think that the git protocol could be more efficient in some
cases although how true that is now I'm not sure. github is a little different
in that they don't use the standard git server code so the optimisations there
are different.

Cheers,

Richard

On Tue, Nov 2, 2021 at 10:32 AM Richard Purdie
<richard.purdie@...> wrote:

On Tue, 2021-11-02 at 08:16 -0700, Khem Raj wrote:

Can we change bitbake fetcher to default to https instead git
anonymous protocol as fallback? this will be good security measure
too.

Some servers out there (e.g. our own git.yoctoproject.org) have slightly
different git and https urls so this isn't as simple as you'd think.