what happened

Recently we have tried to fix an occasional error around wget, which sometimes fails to download files via https.

Error messages:

https://www.kernel.org/pub/software/scm/git/git-2.24.1.tar.xz: HTTPS
support not compiled in.
!!! Couldn't download 'git-2.24.1.tar.xz'. Aborting.

That probably happens because wget in some catalyst stages are compiled without ssl USE flag.
If a catalyst stage is lucky enough to rebuild wget with ssl before actually fetching a file, it would work well. Though if not, it would fail.
It is not deterministic, and hard to reproduce.

So the plan was to backport the fix from upstream Gentoo. Details: https://bugs.gentoo.org/611072

However, the fix has caused other issues:

1. Build fails due to a missing keyword for ~amd64 for wget.

It is rather a low-hanging fruit. Adding a keyword should simply fix.

2. Build failed because of bindist restrict flag in openssl

Build failed like that:

!!! All ebuilds that could satisfy "dev-libs/openssl:0=" for /tmp/stage1root/ have been masked.
!!! One of the following masked packages is required to complete your request:
- dev-libs/openssl-1.0.2u::coreos (masked by: bindist in RESTRICT)

It is not trivial to fix it.
What happens is, wget started to pull in dev-libs/openssl, which has bindist in its USE flag.
The catalyst stages, however, need to install wget without bindist.
Such mismatches resulted in such bugs.

So to fix the issue, what needs to be done is basically:

ACCEPT_RESTRICT=bindist USE=-bindist emerge -pv openssl openssh

Unfortunately it is not possible to set accept_restrict configs under the coreos-overlay repo.
We need to have some time to investigate why it is so.

What we know so far

The corresponding flag ACCEPT_RESTRICT was added by commit 92523a310eb2, in 2015.
So this issue is basically an upstream Gentoo change results in opening up a can of worms created by coreos maintainers a long time ago.

Question is, can we simply remove ACCEPT_RESTRICT from the file, to follow upstream Gentoo?

If it is too invasive to remove ACCEPT_RESTRICT, can we make use of package.accept_restrict on package-basis?

If that is also not possible, is there any other workaround?