Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: epytest, use NO_COLOR rather than NOCOLOR

2023-12-11 Thread Toralf Förster 

On 12/11/23 21:38, Ulrich Mueller wrote:


The standard is defined by sno-color.org.


http://no-color.org

--
Toralf
PGP 23217DA7 9B888F45



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: epytest, use NO_COLOR rather than NOCOLOR

2023-12-11 Thread Ulrich Mueller 
> On Mon, 11 Dec 2023, Eli Schwartz wrote:

>> "Command-line software which adds ANSI color to its output by default
>> should check for a NO_COLOR environment variable that, when present
>> and not an empty string (regardless of its value), prevents the
>> addition of ANSI color." -- https://no-color.org/

> Again, not according to pytest itself. ;)

> Given the commit message says:

> """
> Adjust it to correctly check whether it is set at all rather than to a
> specific value, to match the behavior of pytest itself.
> """

The standard is defined by sno-color.org. If pytest does something
different then it is a bug.

Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: epytest, use NO_COLOR rather than NOCOLOR

2023-12-11 Thread Eli Schwartz 
On 12/11/23 2:27 PM, Michał Górny wrote:
> That looks wrong.  Per [1]:
> 
>> […] NO_COLOR environment variable that, when present and not an empty
> string (regardless of its value), prevents the addition of ANSI color.
> 
> So hey, I'm actually fixing pytest ;-).
> 
> [1] https://no-color.org/


When you say you are fixing pytest, do you mean you are submitting a PR
to pytest to make its behavior align with the (tbh reasonable) behavior
you expected and want?


-- 
Eli Schwartz

Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: epytest, use NO_COLOR rather than NOCOLOR

2023-12-11 Thread Eli Schwartz 
On 12/11/23 2:30 PM, Ulrich Mueller wrote:
>> On Mon, 11 Dec 2023, Eli Schwartz wrote:
> 
>>> +   local color=yes
>>> +   [[ ${NO_COLOR} ]] && color=no
> 
>> [[ -v NO_COLOR ]]
> 
> No, this would give the wrong result if NO_COLOR is set to an empty
> value. [[ ${NO_COLOR} ]] or [[ -n ${NO_COLOR} ]] is the correct test:
> 
>"Command-line software which adds ANSI color to its output by default
>should check for a NO_COLOR environment variable that, when present
>and not an empty string (regardless of its value), prevents the
>addition of ANSI color." -- https://no-color.org/


Again, not according to pytest itself. ;)

Given the commit message says:

"""
Adjust it to correctly check whether it is set at all rather than to a
specific value, to match the behavior of pytest itself.
"""


-- 
Eli Schwartz

Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: epytest, use NO_COLOR rather than NOCOLOR

2023-12-11 Thread Ulrich Mueller 
> On Mon, 11 Dec 2023, Eli Schwartz wrote:

>> +local color=yes
>> +[[ ${NO_COLOR} ]] && color=no

> [[ -v NO_COLOR ]]

No, this would give the wrong result if NO_COLOR is set to an empty
value. [[ ${NO_COLOR} ]] or [[ -n ${NO_COLOR} ]] is the correct test:

   "Command-line software which adds ANSI color to its output by default
   should check for a NO_COLOR environment variable that, when present
   and not an empty string (regardless of its value), prevents the
   addition of ANSI color." -- https://no-color.org/


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: epytest, use NO_COLOR rather than NOCOLOR

2023-12-11 Thread Michał Górny 
On Mon, 2023-12-11 at 13:57 -0500, Eli Schwartz wrote:
> On 12/2/23 7:44 AM, Michał Górny wrote:
> > Update epytest to respect the modern NO_COLOR variable rather than
> > Portage's old NOCOLOR.  Adjust it to correctly check whether it is set
> > at all rather than to a specific value, to match the behavior of pytest
> > itself.
> > 
> > Signed-off-by: Michał Górny 
> > ---
> >  eclass/python-utils-r1.eclass | 11 ++-
> >  1 file changed, 2 insertions(+), 9 deletions(-)
> > 
> > diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
> > index 394f64a5d139..da9cb820840f 100644
> > --- a/eclass/python-utils-r1.eclass
> > +++ b/eclass/python-utils-r1.eclass
> > @@ -1336,15 +1336,8 @@ epytest() {
> > _python_check_EPYTHON
> > _python_check_occluded_packages
> >  
> > -   local color
> > -   case ${NOCOLOR} in
> > -   true|yes)
> > -   color=no
> > -   ;;
> > -   *)
> > -   color=yes
> > -   ;;
> > -   esac
> > +   local color=yes
> > +   [[ ${NO_COLOR} ]] && color=no
> 
> 
> [[ -v NO_COLOR ]]
> 
> This is processed by the pytest code:
> 
> ```
> if "NO_COLOR" in os.environ:
> return False
> ```
> 

That looks wrong.  Per [1]:

> […] NO_COLOR environment variable that, when present and not an empty
string (regardless of its value), prevents the addition of ANSI color.

So hey, I'm actually fixing pytest ;-).

[1] https://no-color.org/

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: epytest, use NO_COLOR rather than NOCOLOR

2023-12-11 Thread Eli Schwartz 
On 12/2/23 7:44 AM, Michał Górny wrote:
> Update epytest to respect the modern NO_COLOR variable rather than
> Portage's old NOCOLOR.  Adjust it to correctly check whether it is set
> at all rather than to a specific value, to match the behavior of pytest
> itself.
> 
> Signed-off-by: Michał Górny 
> ---
>  eclass/python-utils-r1.eclass | 11 ++-
>  1 file changed, 2 insertions(+), 9 deletions(-)
> 
> diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
> index 394f64a5d139..da9cb820840f 100644
> --- a/eclass/python-utils-r1.eclass
> +++ b/eclass/python-utils-r1.eclass
> @@ -1336,15 +1336,8 @@ epytest() {
>   _python_check_EPYTHON
>   _python_check_occluded_packages
>  
> - local color
> - case ${NOCOLOR} in
> - true|yes)
> - color=no
> - ;;
> - *)
> - color=yes
> - ;;
> - esac
> + local color=yes
> + [[ ${NO_COLOR} ]] && color=no


[[ -v NO_COLOR ]]

This is processed by the pytest code:

```
if "NO_COLOR" in os.environ:
return False
```


>  
>   local args=(
>   # verbose progress reporting and tracebacks


-- 
Eli Schwartz

Re: [gentoo-dev] heads up: codeberg changed gzip impls (?) for ${REPO}/archive/${TAG}.tar.gz files

2023-12-11 Thread Eli Schwartz 
On 12/11/23 5:47 AM, Arsen Arsenović wrote:
> hi,
> 
> it seems that codeberg has changed how they produce their archives on
> URLs like  leading
> to digest failures like , as implied by
> the following checks:
> 
>   ~$ diff <( <(   ~$ diff <( <(   Binary files /dev/fd/63 and /dev/fd/62 differ
> 
> the above shows that compressed content differs while decompressed
> content remains identical.
> 
> (dls/foot-1.16.2.tar.gz is downloaded from the master distfiles mirror,
> /var/cache/distfiles/foot-1.16.2.tar.gz is fetched from codeberg at
> around two in the morning last night)
> 
> you might want to regenerate manifests for projects fetching from
> /archive/ urls on codeberg.
> 
> Daniel, thank you for working on foot.  may I ask that you attach 'meson
> dist'-generated files to releases?  you could also use that opportunity
> to hash or sign them, if you so desire.
> 
> in either case, thank you again.
> 
> have a lovely day, all!


It sounds like they completely failed to get the memo about:
https://github.com/orgs/community/discussions/46034

However, I really do wish tremendously that they *would* change all
tarball checksums... for a good reason!

Namely, they need to fix https://github.com/go-gitea/gitea/issues/18078
because currently gitea-based software forges kind of suck and I'd
rather no one used them for anything, lol.

It does appear that since last year when they fixed an unrelated issue,
closed *this* issue as "not fixed but sometime in the future we'll fix
it, we pinky promise"...

... that they've fixed the issue for manually uploaded release assets
where the download url was based on an unpredictable uuid.

So that's sort of kind of a little bit good at least.



-- 
Eli Schwartz

Re: [gentoo-dev] heads up: codeberg changed gzip impls (?) for ${REPO}/archive/${TAG}.tar.gz files

2023-12-11 Thread Arsen Arsenović 

Arsen Arsenović  writes:

> hi,
>
> it seems that codeberg has changed how they produce their archives on
> URLs like  leading
> to digest failures like , as implied by
> the following checks:
>
>   ~$ diff <( <(   ~$ diff <( <(   Binary files /dev/fd/63 and /dev/fd/62 differ
>
> the above shows that compressed content differs while decompressed
> content remains identical.
>
> (dls/foot-1.16.2.tar.gz is downloaded from the master distfiles mirror,
> /var/cache/distfiles/foot-1.16.2.tar.gz is fetched from codeberg at
> around two in the morning last night)
>
> you might want to regenerate manifests for projects fetching from
> /archive/ urls on codeberg.

ps, also filed https://codeberg.org/Codeberg/Community/issues/1366 per
ulms suggestion.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH v4] kernel-build.eclass: work around permissions issue with module signing

2023-12-11 Thread Michał Górny 
On Mon, 2023-12-11 at 12:28 +0100, Andrew Ammerlaan wrote:
> > > diff --git a/eclass/kernel-build.eclass b/eclass/kernel-build.eclass
> > > index f5529c319f9fc..94b499f82fc1e 100644
> > > --- a/eclass/kernel-build.eclass
> > > +++ b/eclass/kernel-build.eclass
> > > @@ -114,6 +114,13 @@ kernel-build_pkg_setup() {
> > >       python-any-r1_pkg_setup
> > >       if [[ ${KERNEL_IUSE_MODULES_SIGN} ]]; then
> > >       secureboot_pkg_setup
> > > + if [[ -e ${MODULES_SIGN_KEY} && ${MODULES_SIGN_KEY} != pkcs11:* 
> > > ]]; then
> > > + if [[ -e ${MODULES_SIGN_CERT} && ${MODULES_SIGN_CERT} !=
> > > ${MODULES_SIGN_KEY} ]]; then
> > > + MODULES_SIGN_KEY_CONTENTS="$(cat 
> > > "${MODULES_SIGN_CERT}"
> > > "${MODULES_SIGN_KEY}" || die)"
> > 
> > You can use $(<...) builtin instead of calling cat(1).
> > 
> 
> 
> I don't have a strong preference, but I used cat here for esthetic 
> symmetry reasons with the line above. Anyway, here's v4:
> 
>  From 3890c558ff93b9cdb608a3bbcf4c3039f456b571 Mon Sep 17 00:00:00 2001
> From: Violet Purcell 
> Date: Mon, 27 Nov 2023 12:12:09 -0500
> Subject: [PATCH] kernel-build.eclass: work around permissions issue with
>   module signing
> 
> Currently, using a custom path for MODULES_SIGN_KEY requires the key to
> be readable by portage:portage. This is not ideal for security, since
> the file has to be either owned by portage:portage or readable by all
> users in this case. Instead, export the contents of MODULES_SIGN_KEY to
> a variable in pkg_setup, and then create a temporary file with it in
> src_configure to ensure that the temporary key is readable by the user
> that the kernel is being built as. The variable is then unset so it does
> not end up in the final environment file.
> 
> Co-authored-by: Andrew Ammerlaan 
> Signed-off-by: Violet Purcell 
> ---
>   eclass/kernel-build.eclass | 18 --
>   1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/eclass/kernel-build.eclass b/eclass/kernel-build.eclass
> index f5529c319f9fc..6b692dc4f9a08 100644
> --- a/eclass/kernel-build.eclass
> +++ b/eclass/kernel-build.eclass
> @@ -114,6 +114,13 @@ kernel-build_pkg_setup() {
>   python-any-r1_pkg_setup
>   if [[ ${KERNEL_IUSE_MODULES_SIGN} ]]; then
>   secureboot_pkg_setup
> + if [[ -e ${MODULES_SIGN_KEY} && ${MODULES_SIGN_KEY} != pkcs11:* 
> ]]; then
> + if [[ -e ${MODULES_SIGN_CERT} && ${MODULES_SIGN_CERT} 
> != 
> ${MODULES_SIGN_KEY} ]]; then
> + MODULES_SIGN_KEY_CONTENTS="$(cat 
> "${MODULES_SIGN_CERT}" 
> "${MODULES_SIGN_KEY}" || die)"
> + else
> + MODULES_SIGN_KEY_CONTENTS="$(< 
> "${MODULES_SIGN_KEY}")"
> + fi
> + fi
>   fi
>   }
> 
> @@ -422,12 +429,11 @@ kernel-build_merge_configs() {
>   CONFIG_MODULE_SIG_FORCE=y
>   CONFIG_MODULE_SIG_${MODULES_SIGN_HASH^^}=y
>   EOF
> - if [[ -e ${MODULES_SIGN_KEY} && -e ${MODULES_SIGN_CERT} 
> &&
> - ${MODULES_SIGN_KEY} != ${MODULES_SIGN_CERT} &&
> - ${MODULES_SIGN_KEY} != pkcs11:* ]]
> - then
> - cat "${MODULES_SIGN_CERT}" 
> "${MODULES_SIGN_KEY}" > 
> "${T}/kernel_key.pem" || die
> - MODULES_SIGN_KEY="${T}/kernel_key.pem"
> + if [[ -n ${MODULES_SIGN_KEY_CONTENTS} ]]; then
> + (umask 066 && touch "${T}/kernel_key.pem" || 
> die)
> + echo "${MODULES_SIGN_KEY_CONTENTS}" > 
> "${T}/kernel_key.pem" || die
> + unset MODULES_SIGN_KEY_CONTENTS
> + export MODULES_SIGN_KEY="${T}/kernel_key.pem"
>   fi
>   if [[ ${MODULES_SIGN_KEY} == pkcs11:* || -r 
> ${MODULES_SIGN_KEY} ]]; 
> then
>   echo 
> "CONFIG_MODULE_SIG_KEY=\"${MODULES_SIGN_KEY}\"" \

LGTM but I didn't test it.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [PATCH v2] kernel-install.eclass: fix test phase on systemd systems

2023-12-11 Thread Michał Górny 
On Mon, 2023-12-11 at 12:22 +0100, Andrew Ammerlaan wrote:
> > > + # Initrd images with systemd require some os-release file
> > > + cat <<-EOT >> "${imageroot}/etc/os-release" || die
> > > + NAME=Gentoo
> > > + ID=gentoo
> > > + PRETTY_NAME="Gentoo Linux"
> > > + ANSI_COLOR="1;32"
> > > + HOME_URL="https://www.gentoo.org/;
> > > + SUPPORT_URL="https://www.gentoo.org/support/;
> > > + BUG_REPORT_URL="https://bugs.gentoo.org/;
> > > + VERSION_ID="dist-kernel testing"
> > > + EOT
> > > 
> > 
> > Can't we just copy it from host?
> > 
> I guess we can, we would be assuming that the host has a valid one but 
> this shouldn't be a problem since at least for systemd systems you can 
> apparently not boot at all if it is not valid. v2:
> 
>  From 0a22dcc93c8ba16cdb450f2443ad256e56111d6e Mon Sep 17 00:00:00 2001
> From: Andrew Ammerlaan 
> Date: Mon, 11 Dec 2023 08:36:58 +0100
> Subject: [PATCH] kernel-install.eclass: fix test phase on systemd systems
> 
> On systemd systems the dracut systemd modules are included automatically.
> Systemd insists our dummy root has some valid /etc/os-release file, 
> otherwise
> it refuses the switch root operation. However, with this fix it still 
> does not
> boot up correctly on systemd systems, it gets stuck in an infinite boot 
> loop.
> Presumably the reason has something to do with our dummy root not having 
> a real
> systemd init to switch root to. We add the systemd dracut modules to the 
> omit
> list to prevent the problem and ensure the test phase behaves the same on
> systemd and non-systemd systems.
> 
> Signed-off-by: Andrew Ammerlaan 
> ---
>   eclass/kernel-install.eclass | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/eclass/kernel-install.eclass b/eclass/kernel-install.eclass
> index b4d84f3986c0d..e244f6d51a9cd 100644
> --- a/eclass/kernel-install.eclass
> +++ b/eclass/kernel-install.eclass
> @@ -231,6 +231,8 @@ kernel-install_create_qemu_image() {
>   # some layout needed to pass dracut's usable_root() validation
>   mkdir -p "${imageroot}"/{bin,dev,etc,lib,proc,root,sbin,sys} || die
>   touch "${imageroot}/lib/ld-fake.so" || die
> + # Initrd images with systemd require some os-release file
> + cp /etc/os-release "${imageroot}/etc/os-release" || die

This should probably be BROOT.

> 
>   kernel-install_create_init "${imageroot}/sbin/init"
> 
> @@ -263,6 +265,7 @@ kernel-install_test() {
>   plymouth # hangs, or sometimes steals output
>   rngd # hangs or segfaults sometimes
>   i18n # copies all the fonts from /usr/share/consolefonts
> + dracut-systemd systemd systemd-initrd # gets stuck in boot loop
>   )
> 
>   # NB: if you pass a path that does not exist or is not a regular
> 
> 

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [PATCH v4] kernel-build.eclass: work around permissions issue with module signing

2023-12-11 Thread Andrew Ammerlaan 

diff --git a/eclass/kernel-build.eclass b/eclass/kernel-build.eclass
index f5529c319f9fc..94b499f82fc1e 100644
--- a/eclass/kernel-build.eclass
+++ b/eclass/kernel-build.eclass
@@ -114,6 +114,13 @@ kernel-build_pkg_setup() {
python-any-r1_pkg_setup
if [[ ${KERNEL_IUSE_MODULES_SIGN} ]]; then
secureboot_pkg_setup
+   if [[ -e ${MODULES_SIGN_KEY} && ${MODULES_SIGN_KEY} != pkcs11:* 
]]; then
+   if [[ -e ${MODULES_SIGN_CERT} && ${MODULES_SIGN_CERT} !=
${MODULES_SIGN_KEY} ]]; then
+   MODULES_SIGN_KEY_CONTENTS="$(cat 
"${MODULES_SIGN_CERT}"
"${MODULES_SIGN_KEY}" || die)"


You can use $(<...) builtin instead of calling cat(1).




I don't have a strong preference, but I used cat here for esthetic 
symmetry reasons with the line above. Anyway, here's v4:


From 3890c558ff93b9cdb608a3bbcf4c3039f456b571 Mon Sep 17 00:00:00 2001
From: Violet Purcell 
Date: Mon, 27 Nov 2023 12:12:09 -0500
Subject: [PATCH] kernel-build.eclass: work around permissions issue with
 module signing

Currently, using a custom path for MODULES_SIGN_KEY requires the key to
be readable by portage:portage. This is not ideal for security, since
the file has to be either owned by portage:portage or readable by all
users in this case. Instead, export the contents of MODULES_SIGN_KEY to
a variable in pkg_setup, and then create a temporary file with it in
src_configure to ensure that the temporary key is readable by the user
that the kernel is being built as. The variable is then unset so it does
not end up in the final environment file.

Co-authored-by: Andrew Ammerlaan 
Signed-off-by: Violet Purcell 
---
 eclass/kernel-build.eclass | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/eclass/kernel-build.eclass b/eclass/kernel-build.eclass
index f5529c319f9fc..6b692dc4f9a08 100644
--- a/eclass/kernel-build.eclass
+++ b/eclass/kernel-build.eclass
@@ -114,6 +114,13 @@ kernel-build_pkg_setup() {
python-any-r1_pkg_setup
if [[ ${KERNEL_IUSE_MODULES_SIGN} ]]; then
secureboot_pkg_setup
+   if [[ -e ${MODULES_SIGN_KEY} && ${MODULES_SIGN_KEY} != pkcs11:* 
]]; then
+			if [[ -e ${MODULES_SIGN_CERT} && ${MODULES_SIGN_CERT} != 
${MODULES_SIGN_KEY} ]]; then
+MODULES_SIGN_KEY_CONTENTS="$(cat "${MODULES_SIGN_CERT}" 
"${MODULES_SIGN_KEY}" || die)"

+   else
+   MODULES_SIGN_KEY_CONTENTS="$(< 
"${MODULES_SIGN_KEY}")"
+   fi
+   fi
fi
 }

@@ -422,12 +429,11 @@ kernel-build_merge_configs() {
CONFIG_MODULE_SIG_FORCE=y
CONFIG_MODULE_SIG_${MODULES_SIGN_HASH^^}=y
EOF
-   if [[ -e ${MODULES_SIGN_KEY} && -e ${MODULES_SIGN_CERT} 
&&
-   ${MODULES_SIGN_KEY} != ${MODULES_SIGN_CERT} &&
-   ${MODULES_SIGN_KEY} != pkcs11:* ]]
-   then
-cat "${MODULES_SIGN_CERT}" "${MODULES_SIGN_KEY}" > 
"${T}/kernel_key.pem" || die

-   MODULES_SIGN_KEY="${T}/kernel_key.pem"
+   if [[ -n ${MODULES_SIGN_KEY_CONTENTS} ]]; then
+   (umask 066 && touch "${T}/kernel_key.pem" || 
die)
+   echo "${MODULES_SIGN_KEY_CONTENTS}" > 
"${T}/kernel_key.pem" || die
+   unset MODULES_SIGN_KEY_CONTENTS
+   export MODULES_SIGN_KEY="${T}/kernel_key.pem"
fi
 			if [[ ${MODULES_SIGN_KEY} == pkcs11:* || -r ${MODULES_SIGN_KEY} ]]; 
then

echo 
"CONFIG_MODULE_SIG_KEY=\"${MODULES_SIGN_KEY}\"" \

Re: [gentoo-dev] [PATCH v2] kernel-install.eclass: fix test phase on systemd systems

2023-12-11 Thread Andrew Ammerlaan 

+   # Initrd images with systemd require some os-release file
+   cat <<-EOT >> "${imageroot}/etc/os-release" || die
+   NAME=Gentoo
+   ID=gentoo
+   PRETTY_NAME="Gentoo Linux"
+   ANSI_COLOR="1;32"
+   HOME_URL="https://www.gentoo.org/;
+   SUPPORT_URL="https://www.gentoo.org/support/;
+   BUG_REPORT_URL="https://bugs.gentoo.org/;
+   VERSION_ID="dist-kernel testing"
+   EOT



Can't we just copy it from host?

I guess we can, we would be assuming that the host has a valid one but 
this shouldn't be a problem since at least for systemd systems you can 
apparently not boot at all if it is not valid. v2:


From 0a22dcc93c8ba16cdb450f2443ad256e56111d6e Mon Sep 17 00:00:00 2001
From: Andrew Ammerlaan 
Date: Mon, 11 Dec 2023 08:36:58 +0100
Subject: [PATCH] kernel-install.eclass: fix test phase on systemd systems

On systemd systems the dracut systemd modules are included automatically.
Systemd insists our dummy root has some valid /etc/os-release file, 
otherwise
it refuses the switch root operation. However, with this fix it still 
does not
boot up correctly on systemd systems, it gets stuck in an infinite boot 
loop.
Presumably the reason has something to do with our dummy root not having 
a real
systemd init to switch root to. We add the systemd dracut modules to the 
omit

list to prevent the problem and ensure the test phase behaves the same on
systemd and non-systemd systems.

Signed-off-by: Andrew Ammerlaan 
---
 eclass/kernel-install.eclass | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/eclass/kernel-install.eclass b/eclass/kernel-install.eclass
index b4d84f3986c0d..e244f6d51a9cd 100644
--- a/eclass/kernel-install.eclass
+++ b/eclass/kernel-install.eclass
@@ -231,6 +231,8 @@ kernel-install_create_qemu_image() {
# some layout needed to pass dracut's usable_root() validation
mkdir -p "${imageroot}"/{bin,dev,etc,lib,proc,root,sbin,sys} || die
touch "${imageroot}/lib/ld-fake.so" || die
+   # Initrd images with systemd require some os-release file
+   cp /etc/os-release "${imageroot}/etc/os-release" || die

kernel-install_create_init "${imageroot}/sbin/init"

@@ -263,6 +265,7 @@ kernel-install_test() {
plymouth # hangs, or sometimes steals output
rngd # hangs or segfaults sometimes
i18n # copies all the fonts from /usr/share/consolefonts
+   dracut-systemd systemd systemd-initrd # gets stuck in boot loop
)

# NB: if you pass a path that does not exist or is not a regular

Re: [gentoo-dev] [PATCH v3] kernel-build.eclass: work around permissions issue with module signing

2023-12-11 Thread Michał Górny 
On Mon, 2023-12-11 at 09:00 +0100, Andrew Ammerlaan wrote:
> v3:
> 
>  From dbf92605437b4a457bad2da92f69baab23fcfa44 Mon Sep 17 00:00:00 2001
> From: Violet Purcell 
> Date: Mon, 27 Nov 2023 12:12:09 -0500
> Subject: [PATCH] kernel-build.eclass: work around permissions issue with
>   module signing
> 
> Currently, using a custom path for MODULES_SIGN_KEY requires the key to
> be readable by portage:portage. This is not ideal for security, since
> the file has to be either owned by portage:portage or readable by all
> users in this case. Instead, export the contents of MODULES_SIGN_KEY to
> a variable in pkg_setup, and then create a temporary file with it in
> src_configure to ensure that the temporary key is readable by the user
> that the kernel is being built as. The variable is then unset so it does
> not end up in the final environment file.
> 
> Co-authored-by: Andrew Ammerlaan 
> Signed-off-by: Violet Purcell 
> ---
>   eclass/kernel-build.eclass | 18 --
>   1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/eclass/kernel-build.eclass b/eclass/kernel-build.eclass
> index f5529c319f9fc..94b499f82fc1e 100644
> --- a/eclass/kernel-build.eclass
> +++ b/eclass/kernel-build.eclass
> @@ -114,6 +114,13 @@ kernel-build_pkg_setup() {
>   python-any-r1_pkg_setup
>   if [[ ${KERNEL_IUSE_MODULES_SIGN} ]]; then
>   secureboot_pkg_setup
> + if [[ -e ${MODULES_SIGN_KEY} && ${MODULES_SIGN_KEY} != pkcs11:* 
> ]]; then
> + if [[ -e ${MODULES_SIGN_CERT} && ${MODULES_SIGN_CERT} 
> != 
> ${MODULES_SIGN_KEY} ]]; then
> + MODULES_SIGN_KEY_CONTENTS="$(cat 
> "${MODULES_SIGN_CERT}" 
> "${MODULES_SIGN_KEY}" || die)"

You can use $(<...) builtin instead of calling cat(1).

> + else
> + MODULES_SIGN_KEY_CONTENTS="$(cat 
> "${MODULES_SIGN_KEY}" || die)"
> + fi
> + fi
>   fi
>   }
> 
> @@ -422,12 +429,11 @@ kernel-build_merge_configs() {
>   CONFIG_MODULE_SIG_FORCE=y
>   CONFIG_MODULE_SIG_${MODULES_SIGN_HASH^^}=y
>   EOF
> - if [[ -e ${MODULES_SIGN_KEY} && -e ${MODULES_SIGN_CERT} 
> &&
> - ${MODULES_SIGN_KEY} != ${MODULES_SIGN_CERT} &&
> - ${MODULES_SIGN_KEY} != pkcs11:* ]]
> - then
> - cat "${MODULES_SIGN_CERT}" 
> "${MODULES_SIGN_KEY}" > 
> "${T}/kernel_key.pem" || die
> - MODULES_SIGN_KEY="${T}/kernel_key.pem"
> + if [[ -n "${MODULES_SIGN_KEY_CONTENTS}" ]]; then

No quoting is needed here.

> + (umask 066; touch "${T}/kernel_key.pem" || die)

'&&' instead of ';', even if umask shouldn't really fail here.

> + echo "${MODULES_SIGN_KEY_CONTENTS}" > 
> "${T}/kernel_key.pem" || die
> + unset MODULES_SIGN_KEY_CONTENTS
> + export MODULES_SIGN_KEY="${T}/kernel_key.pem"
>   fi
>   if [[ ${MODULES_SIGN_KEY} == pkcs11:* || -r 
> ${MODULES_SIGN_KEY} ]]; 
> then
>   echo 
> "CONFIG_MODULE_SIG_KEY=\"${MODULES_SIGN_KEY}\"" \
> 

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [PATCH] kernel-install.eclass: fix test phase on systemd systems

2023-12-11 Thread Michał Górny 
On Mon, 2023-12-11 at 08:43 +0100, Andrew Ammerlaan wrote:
> Patch is part of https://github.com/gentoo/gentoo/pull/34024
> 
> Best regards,
> Andrew
> 
>  From 03e17149eef9eba08f8c8bf32845c18106d32290 Mon Sep 17 00:00:00 2001
> From: Andrew Ammerlaan 
> Date: Mon, 11 Dec 2023 08:36:58 +0100
> Subject: [PATCH] kernel-install.eclass: fix test phase on systemd systems
> 
> On systemd systems the dracut systemd modules are included automatically.
> Systemd insists our dummy root has some valid /etc/os-release file, 
> otherwise
> it refuses the switch root operation. However, with this fix it still 
> does not
> boot up correctly on systemd systems, it gets stuck in an infinite boot 
> loop.
> Presumably the reason has something to do with our dummy root not having 
> a real
> systemd init to switch root to. We add the systemd dracut modules to the 
> omit
> list to prevent the problem and ensure the test phase behaves the same on
> systemd and non-systemd systems.
> 
> Signed-off-by: Andrew Ammerlaan 
> ---
>   eclass/kernel-install.eclass | 12 
>   1 file changed, 12 insertions(+)
> 
> diff --git a/eclass/kernel-install.eclass b/eclass/kernel-install.eclass
> index b4d84f3986c0d..f2a6ec75f2a88 100644
> --- a/eclass/kernel-install.eclass
> +++ b/eclass/kernel-install.eclass
> @@ -231,6 +231,17 @@ kernel-install_create_qemu_image() {
>   # some layout needed to pass dracut's usable_root() validation
>   mkdir -p "${imageroot}"/{bin,dev,etc,lib,proc,root,sbin,sys} || die
>   touch "${imageroot}/lib/ld-fake.so" || die
> + # Initrd images with systemd require some os-release file
> + cat <<-EOT >> "${imageroot}/etc/os-release" || die
> + NAME=Gentoo
> + ID=gentoo
> + PRETTY_NAME="Gentoo Linux"
> + ANSI_COLOR="1;32"
> + HOME_URL="https://www.gentoo.org/;
> + SUPPORT_URL="https://www.gentoo.org/support/;
> + BUG_REPORT_URL="https://bugs.gentoo.org/;
> + VERSION_ID="dist-kernel testing"
> + EOT
> 

Can't we just copy it from host?

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part

[gentoo-dev] heads up: codeberg changed gzip impls (?) for ${REPO}/archive/${TAG}.tar.gz files

2023-12-11 Thread Arsen Arsenović 
hi,

it seems that codeberg has changed how they produce their archives on
URLs like  leading
to digest failures like , as implied by
the following checks:

  ~$ diff <(

signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH v3] kernel-build.eclass: work around permissions issue with module signing

2023-12-11 Thread Andrew Ammerlaan 

v3:

From dbf92605437b4a457bad2da92f69baab23fcfa44 Mon Sep 17 00:00:00 2001
From: Violet Purcell 
Date: Mon, 27 Nov 2023 12:12:09 -0500
Subject: [PATCH] kernel-build.eclass: work around permissions issue with
 module signing

Currently, using a custom path for MODULES_SIGN_KEY requires the key to
be readable by portage:portage. This is not ideal for security, since
the file has to be either owned by portage:portage or readable by all
users in this case. Instead, export the contents of MODULES_SIGN_KEY to
a variable in pkg_setup, and then create a temporary file with it in
src_configure to ensure that the temporary key is readable by the user
that the kernel is being built as. The variable is then unset so it does
not end up in the final environment file.

Co-authored-by: Andrew Ammerlaan 
Signed-off-by: Violet Purcell 
---
 eclass/kernel-build.eclass | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/eclass/kernel-build.eclass b/eclass/kernel-build.eclass
index f5529c319f9fc..94b499f82fc1e 100644
--- a/eclass/kernel-build.eclass
+++ b/eclass/kernel-build.eclass
@@ -114,6 +114,13 @@ kernel-build_pkg_setup() {
python-any-r1_pkg_setup
if [[ ${KERNEL_IUSE_MODULES_SIGN} ]]; then
secureboot_pkg_setup
+   if [[ -e ${MODULES_SIGN_KEY} && ${MODULES_SIGN_KEY} != pkcs11:* 
]]; then
+			if [[ -e ${MODULES_SIGN_CERT} && ${MODULES_SIGN_CERT} != 
${MODULES_SIGN_KEY} ]]; then
+MODULES_SIGN_KEY_CONTENTS="$(cat "${MODULES_SIGN_CERT}" 
"${MODULES_SIGN_KEY}" || die)"

+   else
+   MODULES_SIGN_KEY_CONTENTS="$(cat 
"${MODULES_SIGN_KEY}" || die)"
+   fi
+   fi
fi
 }

@@ -422,12 +429,11 @@ kernel-build_merge_configs() {
CONFIG_MODULE_SIG_FORCE=y
CONFIG_MODULE_SIG_${MODULES_SIGN_HASH^^}=y
EOF
-   if [[ -e ${MODULES_SIGN_KEY} && -e ${MODULES_SIGN_CERT} 
&&
-   ${MODULES_SIGN_KEY} != ${MODULES_SIGN_CERT} &&
-   ${MODULES_SIGN_KEY} != pkcs11:* ]]
-   then
-cat "${MODULES_SIGN_CERT}" "${MODULES_SIGN_KEY}" > 
"${T}/kernel_key.pem" || die

-   MODULES_SIGN_KEY="${T}/kernel_key.pem"
+   if [[ -n "${MODULES_SIGN_KEY_CONTENTS}" ]]; then
+   (umask 066; touch "${T}/kernel_key.pem" || die)
+   echo "${MODULES_SIGN_KEY_CONTENTS}" > 
"${T}/kernel_key.pem" || die
+   unset MODULES_SIGN_KEY_CONTENTS
+   export MODULES_SIGN_KEY="${T}/kernel_key.pem"
fi
 			if [[ ${MODULES_SIGN_KEY} == pkcs11:* || -r ${MODULES_SIGN_KEY} ]]; 
then

echo 
"CONFIG_MODULE_SIG_KEY=\"${MODULES_SIGN_KEY}\"" \


On 27/11/2023 18:50, Michał Górny wrote:

On Mon, 2023-11-27 at 12:12 -0500, Violet Purcell wrote:

Currently, using a custom path for MODULES_SIGN_KEY requires the key to
be readable by portage:portage. This is not ideal for security, since
the file has to be either owned by portage:portage or readable by all
users in this case. Instead, export the contents of MODULES_SIGN_KEY to
a variable in pkg_setup, and then create a temporary file with it in
src_configure to ensure that the temporary key is readable by the user
that the kernel is being built as. The variable is then unset so it does
not end up in the final environment file.

Signed-off-by: Violet Purcell 
---
  eclass/kernel-build.eclass | 19 +--
  1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/eclass/kernel-build.eclass b/eclass/kernel-build.eclass
index 4f7e4d047739..cf958c86ff29 100644
--- a/eclass/kernel-build.eclass
+++ b/eclass/kernel-build.eclass
@@ -114,6 +114,13 @@ kernel-build_pkg_setup() {
python-any-r1_pkg_setup
if [[ ${KERNEL_IUSE_MODULES_SIGN} ]]; then
secureboot_pkg_setup
+   if [[ -e ${MODULES_SIGN_KEY} && ${MODULES_SIGN_KEY} != pkcs11:* 
]]; then
+   if [[ -e ${MODULES_SIGN_CERT} && ${MODULES_SIGN_CERT} 
!= ${MODULES_SIGN_KEY} ]]; then
+   export MODULES_SIGN_KEY_CONTENTS="$(cat "${MODULES_SIGN_CERT}" 
"${MODULES_SIGN_KEY}")"
+   else
+   export MODULES_SIGN_KEY_CONTENTS="$(< 
"${MODULES_SIGN_KEY}")"


You don't need to export it.  Unexported variables are also preserved.


+   fi
+   fi
fi
  }
  
@@ -427,12 +434,12 @@ kernel-build_merge_configs() {

CONFIG_MODULE_SIG_FORCE=y
CONFIG_MODULE_SIG_${MODULES_SIGN_HASH^^}=y
EOF
-   if [[ -e ${MODULES_SIGN_KEY} && -e ${MODULES_SIGN_CERT} 
&&
-