Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 921431

Summary: app-portage/gentoolkit-0.6.3-r1: eclean-package support for Local XPAK packages
Product: Portage Development Reporter: inkflaw <xiangzhedev>
Component: Binary packages supportAssignee: Portage team <dev-portage>
Status: RESOLVED CANTFIX    
Severity: major CC: tools-portage
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---

Description inkflaw 2024-01-06 01:48:43 UTC
As follow the new of 'Gentoo goes Binary!', I enabled the `binpkg-request-signature` as suggest.

Reproducible: Always

Actual Results:  
I had set the signature for self-made packages and use `sudo rm -rf /var/cache/binpkgs/` to clean local binpkgs, but when I use `sudo eclean --deep packages`, it will show me the warning:
```
 * Building file list for packages cleaning...
Local XPAK packages are ignored due to 'binpkg-request-signature'.
 * Your packages directory was already clean.
```


My make.conf as below:
```
# These settings were set by the catalyst build script that automatically
# built this stage.
# Please consult /usr/share/portage/config/make.conf.example for a more
# detailed example.
# $N refers to the amount of threads used during LTO, one option is to be set to the value of $(nproc)
COMMON_FLAGS="-O2 -pipe -march=native"
CFLAGS="${COMMON_FLAGS}"
CXXFLAGS="${COMMON_FLAGS}"
FCFLAGS="${COMMON_FLAGS}"
FFLAGS="${COMMON_FLAGS}"

# NOTE: This stage was built with the bindist Use flag enabled

# This sets the language of build output to English.
# Please keep this setting intact when reporting bugs.
LC_MESSAGES=C.utf8

# If left undefined, Portage's default behavior is to set the MAKEOPTS value to the same number of threads returned by `nproc`
#MAKEOPTS="--jobs 12 --load-average 14"

FEATURES="buildpkg binpkg-signing"
FEATURES="${FEATURES} getbinpkg binpkg-request-signature"

BINPKG_GPG_SIGNING_GPG_HOME="/etc/portage/gnupg"
BINPKG_GPG_SIGNING_KEY="6DC2BB5F632859FEE1ED25971D1482A20084AAB0"
FEATURES="${FEATURES} gpg-keepalive"

#USE="elogind -systemd wayland nls lto pgo man verify-sig"
ACCEPT_LICENSE="* -@EULA"

VIDEO_CARDS="intel"

## (Add in the LINGUAS variable. For instance, for German, Finnish and English:)
LINGUAS="en zh zh_CN"
## (Add in the L10N variable. For instance, for German and Brazilian Portuguese:)
L10N="zh-CN zh"
GRUB_PLATFORMS="efi-64"
GENTOO_MIRRORS="https://mirror.lzu.edu.cn/gentoo \
    https://mirrors.ustc.edu.cn/gentoo/"
```
Comment 1 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2024-01-06 08:25:22 UTC
This is mentioned at https://www.gentoo.org/news/2023/12/29/Gentoo-binary.html under 'I’ve made binary packages myself and portage refuses to use them now!'.

The probblem is that xpak does not support signing but to be secure, you need your Portage to require signatures in binpkgs.

Otherwise, an attacker could just inject xpaks into the binhost and then you'd fetch and install them with no verification...

I don't think we can really do anything here. I recommend you switch your local binpkg creation to gpkg and sign them instead.

If you have a suggestion which wouldn't compromise the above, let us know though.
Comment 2 Zac Medico gentoo-dev 2024-01-07 22:16:14 UTC
(In reply to Sam James from comment #1)
> Otherwise, an attacker could just inject xpaks into the binhost and then
> you'd fetch and install them with no verification...

We could add a binrepos.conf option to specify all packages from a particular binhost must be signed, and then at download/verification time simply reject any remote packages from that binhost that do not have a valid signature.
Comment 3 inkflaw 2024-01-10 07:28:03 UTC
(In reply to Sam James from comment #1)
> This is mentioned at
> https://www.gentoo.org/news/2023/12/29/Gentoo-binary.html under 'I’ve made
> binary packages myself and portage refuses to use them now!'.
> 
> The probblem is that xpak does not support signing but to be secure, you
> need your Portage to require signatures in binpkgs.
> 
> Otherwise, an attacker could just inject xpaks into the binhost and then
> you'd fetch and install them with no verification...
> 
> I don't think we can really do anything here. I recommend you switch your
> local binpkg creation to gpkg and sign them instead.
> 
> If you have a suggestion which wouldn't compromise the above, let us know
> though.

But I had add binpkg-signing and BINPKG_GPG_SIGNING_GPG_HOME="/etc/portage/gnupg" BINPKG_GPG_SIGNING_KEY in my make.conf, that's why I confuse here