gpo.zugaina.org

Search Portage & Overlays:
RSS

Gentoo Repository News

OpenSSH RSA SHA-1 signatures - 08/10/2021 00:00 GMT

As of version 8.8, OpenSSH disables RSA signatures using the SHA-1
hash algorithm by default. This change affects both the client and
server components.

After upgrading to this version, you may have trouble connecting to
older SSH servers that do not support the newer RSA/SHA-256/SHA-512
signatures. Support for these signatures was added in OpenSSH 7.2.

As well, you may have trouble using older SSH clients to connect to a
server running OpenSSH 8.8 or higher. Some older clients do not
automatically utilize the newer hashes. For example, PuTTY before
version 0.75 is affected.

To resolve these problems, please upgrade your SSH client/server
whereever possible. If this is not feasible, support for the SHA-1
hashes may be re-enabled using the following config options:

HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa


Posted By: Mike Gilbert

Possible failure to preserve libraries - 29/09/2021 00:00 GMT

We have observed in some cases corruption of Portage's internal database
(VDB), where the libraries provided by a package are not recorded. This
can break the "preserve-libs" functionality, and thus in rare cases
break your system during much later updates (even if you do not use
"preseved-libs" now, but decide to switch it on later).

The underlying problem occurs usually when glibc has been upgraded to a
new major version, but pax-utils has not yet been upgraded to a version
compatible with it (but at that moment stays undetected).

The full technical details and investigation can be found on a Wiki page
[0] and on Bugzilla [1]. Changes have been made to prevent this happening
again both within Portage [7] (with possibly more to come [2]) and within the
glibc and pax-utils ebuilds [3][4].

To detect whether a system is affected, emerge the
app-portage/recover-broken-vdb package:
```
$ emerge --ask --verbose --oneshot app-portage/recover-broken-vdb
```
which provides two tools: recover-broken-vdb-find-broken.sh and
recover-broken-vdb.

Then run recover-broken-vdb-find-broken.sh:
```
$ recover-broken-vdb-find-broken.sh | tee broken_vdb_packages
```

This check should be run on all Gentoo systems. It is only necessary
to run this as a one-off, as changes have been made to prevent such
problems occurring in future.

If you have any output, read on.

Fixing a broken system is not always straightforward. It is strongly
recommended to take a backup of your full system before proceeding,
as well as a copy of /var/db/pkg (the VDB):

Step 1. A tool has been developed [5] to attempt to fix the consistency
  of the Portage database. Using this tool to modify the VDB is NOT
  mandatory (read the full news item before proceeding) - you can skip
  to Step 2 if you wish, but fixing the integrity of the VDB
  makes it as safe as reasonably possible to proceed with
  rebuilding packages.

  Run:
  ```
  # Take a backup of /var/db/pkg before proceeding, such as by doing:
  $ cp -a /var/db/pkg /var/db/pkg.orig

  # And then:
  $ emerge --ask --verbose --oneshot --noreplace \
  	app-portage/recover-broken-vdb

  $ recover-broken-vdb

  # The tool will output to a random temporary directory.
  # Inspect the results, and then update the real /var/db/pkg/
  # by doing either:

  $ recover-broken-vdb --output /var/db/pkg

  # Or, manually copying the new files from the temporary directory tree
  # into your real /var/db/pkg/ directory tree.
  ```

Step 2. Attempt to rebuild the affected packages, first upgrading
  app-misc/pax-utils to the latest version:
  ```
  $ emerge --ask --verbose --oneshot ">=app-misc/pax-utils-1.3.3"
  $ emerge --ask --verbose --oneshot --usepkg=n $(grep -v '#' broken_vdb_packages)
  ```

  It's possible that the relevant versions have disappeared from the tree, so
  if the emerge command fails, please attempt a normal world upgrade.

Step 3. Given that there are possible other side-effects of the corruption/bug,
  it is strongly recommended that if any corruption is detected, all
  packages on the system should be rebuilt, after following the above
  steps:
  ```
  $ emerge --ask --emptytree --usepkg=n @world
  ```

  Note that binary packages may need to be discarded given they may
  contain corrupt metadata.

  If no libraries were broken, it is likely safe to skip this step.

Please see the wiki [0] for a full description of the background
of this problem and handling corner cases such as e.g. already
being affected by system breakage [6] as a result of the bug.

[0] https://wiki.gentoo.org/wiki/Project:Toolchain/Corrupt_VDB_ELF_files
[1] https://bugs.gentoo.org/811462
[2] https://github.com/gentoo/portage/pull/744
[3] https://bugs.gentoo.org/811462#c6
[4] https://bugs.gentoo.org/811462#c7
[5] https://github.com/thesamesam/recover-broken-vdb
[6] https://wiki.gentoo.org/wiki/Fix_my_Gentoo
[7] https://gitweb.gentoo.org/proj/portage.git/commit/?id=83af7270fafbd7b1eed0031a5e06836ad1edf06d


Posted By: Hank Leininger

busybox removal from system set - 24/09/2021 00:00 GMT

The sys-apps/busybox package has been removed from the system
set (@system) in Linux profiles. It was decided that this package is not
necessary for a basic system install.

If you would like to keep this package installed, please ensure it is
present in your Portage world file.

  emerge --select --noreplace sys-apps/busybox

As well, the "static" USE flag has been disabled by default. It may be
re-enabled locally via package.use if so desired.


Posted By: Mike Gilbert

setuptools_scm-6.3.0 temporary runtime breakage - 05/09/2021 00:00 GMT

Users who upgraded to =dev-python/setuptools_scm-6.3.0 between 2021-09-03
15:42 UTC and 2021-09-03 19:03 UTC may be affected by a bug [0]. If you have not
upgraded to this version or have >=dev-python/setuptools_scm-6.3.0-r1 installed,
you are not affected.

A missing dependency in the setuptools_scm ebuild meant there was a timeframe in
which anyone who installed dev-python/setuptools_scm and dev-python/packaging in
the wrong order won't be able to build any Python package using setuptools
unless a workaround is applied.

Specifically, this affects users with =dev-python/setuptools_scm-6.3.0 installed
and where dev-python/packaging is not installed (applies separately for each/any
Python target). The bad tree state was between gentoo.git commits
8882e54abf78d3af69faed5844e3ad441482f23e and
0c76b447cd1be9cf611f649970851750304d9ca6.

Affected users will see errors similar to the following when installing Python
packages:
```
pkg_resources.DistributionNotFound: The 'packaging>=20.0' distribution was not
found and is required by the application
```

To fix this manually, you need to fully remove all dev-python/setuptools_scm
files by running the following commands:

# Necessary to obtain a fixed version of setuptools_scm
$ emerge --sync

# --unmerge is NOT advised normally, but is required to avoid setuptools picking
# up the runtime-broken setuptools_scm version when re-installing setuptools_scm
$ emerge --unmerge =dev-python/setuptools_scm-6.3.0

$ emerge --oneshot dev-python/setuptools dev-python/pyparsing dev-python/packaging
$ emerge --oneshot ">=dev-python/setuptools_scm-6.3.0-r1"

Note that the version specifiers above are not strictly necessary if you have an
up-to-date copy of the tree but provide a safety net.

[0] https://bugs.gentoo.org/811504



Posted By: Sam James

eudev retirement on 2022-01-01 - 24/08/2021 00:00 GMT

sys-fs/udev is becoming the standard provider of udev on non-systemd (e.g.
OpenRC) systems. Users of systemd will continue to use the udev services
provided by the sys-apps/systemd package itself.

The transition should be uneventful in most cases, but please
read this item in full to understand some possible corner cases.

eudev will be retired and removed from Gentoo on 2022-01-01. We will
start masking eudev on 2021-10-01 and give people 3 months to prepare
their transition. You should ensure that sys-fs/eudev is not in your
world file by running

  emerge --deselect sys-fs/eudev

in order for Portage to replace eudev with sys-fs/udev once the
package.mask is in place. We fully support udev on musl, whereas uclibc
will still have to rely on eudev before also being removed on 2022-01-01.

  **WARNING**

If you happen to have an INSTALL_MASK with a blanket "*systemd*" glob,
you will inevitably break your system. sys-fs/udev contains "systemd" in
some of its filenames, hence a blanket filter rule will likely lead to
a non-functional udev installation.

  Rationale

The integration of udev into the systemd git repo introduced numerous
problems for non-glibc systems, such as musl and uclibc.  Several
options were considered, and the one chosen was to fork and maintain udev
independent of the rest of systemd.  This was meant as a stop-gap solution
until such time as the problems with systemd on musl had been resolved.
This is now the case with patches provided by openembedded, and my original
reason for maintaining eudev is no longer relevant.

I am willing to transfer eudev to another umbrella organization or Linux
distribution that is willing to continue its maintenance, but maintaining
eudev cannot be done purely through proxy-maintaining and requires an
understanding of its internals.  This is a steep learning curve and must
be an earnest effort.  For this reason, the Base System project has decided
not to support eudev as an option going forward.


Posted By: Anthony G. Basile

>=app-misc/mc-4.8.27 to drop support for ~/.mc - 19/08/2021 00:00 GMT

app-misc/mc versions between 4.8.1 and 4.8.26, inclusive, would look
for their user configuration in two possible places:

 * if built with USE=-xdg, only the legacy directory ~/.mc is used;

 * if built with USE=xdg, mc uses appropriate XDG user directories
   (e.g. ~/.config/mc, ~/.local/share/mc) if present and attempts
   to automatically migrate the contents of ~/.mc otherwise.

However, starting with version 4.8.27 Midnight Commander will use _only
XDG user directories_ for its configuration and no longer automatically
migrate the contents of ~/.mc. For more information, see:

    https://midnight-commander.org/wiki/NEWS-4.8.27
    https://midnight-commander.org/ticket/3682

For everyone who currently uses app-misc/mc[-xdg], or has not started
mc for so long that it hasn't had a chance to migrate its configuration,
upgrading to 4.8.27 or newer will result in Midnight Commander
effectively reverting to default user configuration. In order to prevent
this from happening, make sure automatic migration is available:

    echo 'app-misc/mc xdg' >> /etc/portage/package.use
    emerge --oneshot 
		

Posted By: Marek Szuba

uClibc-ng retirement on 2022-01-01 - 18/08/2021 00:00 GMT

uClibc-ng is mostly abandoned upstream, and since my RFC in Jan 2021,
no one has volunteered to step up maintenance or expressed interest in
the uClibc-ng profiles. With this announcement we last-rite the "uclibc"
profiles, which will be removed on 2022-01-01. For parties interested in
an alternative libc, consider moving to musl, which is supported.

Gentoo continues to wholeheartedly support musl and is focusing its
efforts in that area.

Resources:
- https://wiki.gentoo.org/wiki/Project:Hardened_musl
- https://gitweb.gentoo.org/proj/musl.git/ (overlay for patches)
- #gentoo-hardened (IRC channel on irc.libera.chat) for support and discussion


Posted By: Anthony G. Basile

OAuth2 Credentials Removed from Chromium - 11/08/2021 00:00 GMT

In March of this year, Google announced that OAuth2 credentials would be revoked
for distros shipping Chromium. This was covered in multiple places at the time,
such as [1,2,3]. Around that time, with 89.0.4389.82, Gentoo removed OAuth2
credentials from its packages. However, they slipped back in shortly after.

As a result, some users [4] have found that recently Google's SSO does not
persist between browser sessions; e.g. you have to log back into GMail every
time you open your browser. This week's changes [5] restore the old behavior
we had in March, of not shipping Gentoo OAuth2 credentials.

If you find that certain Google services are no longer working, you may wish to
supply OAuth2 credentials manually, obtained by following the instructions at
[6]. However, even without supplying such credentials, Google's SSO should now
be working as expected.

There are now two options for passing these credentials to Chromium via

/etc/chromium/default:

  1. GOOGLE_DEFAULT_CLIENT_ID and GOOGLE_DEFAULT_CLIENT_SECRET environment
     variables:
       export GOOGLE_DEFAULT_CLIENT_ID=""
       export GOOGLE_DEFAULT_CLIENT_SECRET=""

  2. --oauth2-client-id and --oauth2-client-secret= command line switches:
       CHROMIUM_FLAGS+=" --oauth2-client-id="
       CHROMIUM_FLAGS+=" --oauth2-client-secret="

Alternatively these environment variables and command line switches may be given
at the command line for ad-hoc testing.

[1] https://archlinux.org/news/chromium-losing-sync-support-in-early-march/
[2] https://bodhi.fedoraproject.org/updates/FEDORA-2021-48866282e5
[3] https://hackaday.com/2021/01/26/whats-the-deal-with-chromium-on-linux-google-at-odds-with-package-maintainers/
[4] https://bugs.gentoo.org/791871
[5] https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fce48ef271bbcaee9afdf0481294da167e665a9b
[6] http://www.chromium.org/developers/how-tos/api-keys


Posted By: Jason A. Donenfeld

USE=tcpd no longer globally enabled - 01/08/2021 00:00 GMT

On 2021-11-01, we will remove USE="tcpd" from the globally default
enabled USE flags (https://bugs.gentoo.org/805077). USE="tcpd" usually
enables sys-apps/tcp-wrappers for an ad hoc firewall based on
/etc/hosts.allow and /etc/hosts.deny.

The Base System project has come to the conclusion that 24 years after
the last upstream release, tcp-wrappers is not suitable for a default
configuration in 2021 anymore. Other distributions have completely
removed support at this point. We strongly recommend you switch to more
modern packet filters, such as BPF, nftables, or iptables. If you rely
on tcp-wrappers, you can re-enable the flag, see

  https://wiki.gentoo.org/wiki//etc/portage/package.use

for package-specific ways to re-enable tcp-wrappers.


Posted By: David Seifert

migrating from glibc[crypt] to libxcrypt in ~arch - 23/07/2021 00:00 GMT

The implementation of libcrypt.so within glibc has been deprecated
for a long time and will be removed in the near future.

For this reason, we are following other distributions (where
this has been tested for years already) and switching to the 
external libxcrypt implementation, starting with ~arch 
installations.

This will be a regular update, and in nearly all cases you
will not have to take any action and not observe any problems.

We do recommend, however, that your system is *fully* up
to date first. This is a standard recommendation but in this
specific case, it is useful to have a simplified depgraph
to ensure that Portage is able to smoothly calculate
an upgrade path.

That is, please take the opportunity to fully upgrade your
systems now, before the migration occurs, to simplify matters.

This change will occur on 2021-07-14 for ~arch users. Stable
users will update at a later date.

If for whatever reason you do *not* wish to switch now -
which is only delaying the inevitable - you
need to take the following steps:
* unmask and enable the crypt USE flag of sys-libs/glibc
* mask the system USE flag of sys-libs/libxcrypt
* mask >=virtual/libcrypt-2

If you wish to manually migrate now, there are a series
of steps described on the wiki (see below), but the outline is:
* unforce the crypt USE flag of sys-libs/glibc and disable it
* unmask the system and split-usr (if applicable) USE flag of sys-libs/libxcrypt
and enable it
* unmask ~virtual/libcrypt-2

Please note that if you last changed your password before ~2008,
it may be using md5crypt or similar other weak mechanisms in /etc/shadow;
a bug in PAM [0][1] may mean that you were unable to login. We recommend
using "passwd" to change/refresh your password so it is using modern
methods. A new version of PAM has been added to the tree to resolve this issue.

In some cases, Portage may schedule a rebuild of certain packages in an
incorrect order [2]. If building a package fails, please try upgrading
libcrypt and libxcrypt first:

# emerge -v1 virtual/libcrypt sys-libs/libxcrypt

And then continue the world upgrade with Portage's "--keep-going=y".

For more information or troubleshooting tips, please see:
* https://wiki.gentoo.org/wiki/Project:Toolchain/libcrypt_implementation
* https://bugs.gentoo.org/699422

[0] https://bugs.gentoo.org/802267
[1] https://bugs.gentoo.org/802807
[2] https://bugs.gentoo.org/802210


Posted By: Sam James