Howto properly set up mock (and certificates) to build OpenSuse RPMs

RaumZeit · 2026-10-23 12:22:37

Hi,

I've been using mock (https://aur.archlinux.org/packages/mock) for quite some time to pre-build binary packages for a larger software project. This was so far all going well, since I've been using a machine with Fedora as OS.

Now, I want to do the same with my workstation at home that runs Arch Linux, but I can't even get the chroot to properly initialize. The issue seems to be related to how Arch Linux is dealing with PGP and SSL certificates in contrast to (most) RPM based Linux distributions. In particular, there are two problems I've already identified:

1. certificates are stored under /etc/ca-certificates/ in Arch Linux whereas they are located under /etc/pki in Fedora, RedHat, etc. Those certificates are copied from the host machine to the target chroot to populate it with some initially trusted keys. Unfortunately, mock expects the host keys under /etc/pki and therefore fails to copy them to the target chroot. Nevertheless, I've already patched my local mock instance to also look for certificate bundles in /etc/ca-certificates and this seems to be working, as they are properly copied to the target chroot now.

2. mock relies on dnf as an installer tool to initially set up the chroot. Luckily, dnf is available in Arch Linux, so this is working. However, for some target distributions, such as OpenSuse 16.1, packages are still signed with SHA1, so I get the following error:

DEBUG: Importing GPG key 0x09D9EA69:
DEBUG:  Userid     : "ALP Package Signing Key <build-alp@suse.de>"
DEBUG:  Fingerprint: 1C59 D66F CD52 563A 1693 3DBC FEC2 8EAF 09D9 EA69
DEBUG:  From       : /usr/share/distribution-gpg-keys/suse/RPM-GPG-KEY-SuSE-ALP-Main
DEBUG: error: Certificate FEC28EAF09D9EA69:
DEBUG:   Policy rejects FEC28EAF09D9EA69: No binding signature at time 2026-10-23T11:39:27Z, because Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance, because SHA1 is not considered secure since 2023-02-01T00:00:00Z

I've already tried deactivating gpgcheck via mock and in /etc/dnf/dnf.conf, but it will be turned on again in the chroot due to RPM security policy:

DEBUG: Warning: Enforcing GPG signature check globally as per active RPM security policy (see 'gpgcheck' in dnf.conf(5) for how to squelch this message)

I don not see these problems in a fresh Fedora 44 installation, where all configs for mock and dnf are virtually the same.
I suspect it has something to do with how crypto policies are handled in Linux distributions other than Arch Linux. In Fedora and OpenSuse, the crypto-policy is set to DEFAULT, which basically points to a configuration like this:

# A reasonable default for today's standards. It should provide
# 112-bit security with the exception of SHA1 signatures in DNSSec.
# SHA1 is allowed in HMAC where collision attacks do not matter.
# OpenSSL distrusts signatures using SHA-1 (Changes/OpenSSLDistrustSHA1SigVer).

# MACs: all HMAC with SHA1 or better + all modern MACs (Poly1305 etc)
# Curves: all prime >= 255 bits (including Bernstein curves)
# Signature algorithms: with SHA-256 hash or better (no DSA)
# TLS Ciphers: >= 128-bit key, >= 128-bit block (AES, ChaCha20, including AES-CBC)
# non-TLS Ciphers: as TLS Ciphers with added Camellia
# key exchange: ECDHE, RSA, DHE (no DHE-DSS)
# DH params size: >= 2048
# RSA params size: >= 2048
# TLS protocols: TLS >= 1.2, DTLS >= 1.2

mac = AEAD HMAC-SHA2-256 HMAC-SHA1 UMAC-128 HMAC-SHA2-384 HMAC-SHA2-512
mac@Kerberos = HMAC-SHA2-384 HMAC-SHA2-256 AEAD UMAC-128 HMAC-SHA2-512 HMAC-SHA1

group = MLKEM768-X25519 P256-MLKEM768 P384-MLKEM1024 MLKEM1024-X448 \
        X25519 SECP256R1 X448 SECP521R1 SECP384R1 \
        FFDHE-2048 FFDHE-3072 FFDHE-4096 FFDHE-6144 FFDHE-8192

hash = SHA2-256 SHA2-384 SHA2-512 SHA3-256 SHA3-384 SHA3-512 SHA2-224 SHA3-224 \
       SHAKE-256

hash@DNSSec = SHA1+  # SHA1 is still prevalent in DNSSec

sign = MLDSA44 MLDSA65 MLDSA87 \
       ECDSA-SHA3-256 ECDSA-SHA2-256 ECDSA-SHA2-256-FIDO \
       ECDSA-SHA3-384 ECDSA-SHA2-384 \
       ECDSA-SHA3-512 ECDSA-SHA2-512 \
       EDDSA-ED25519 EDDSA-ED25519-FIDO EDDSA-ED448 \
       RSA-PSS-SHA3-256 RSA-PSS-SHA2-256 \
       RSA-PSS-SHA3-384 RSA-PSS-SHA2-384 \
       RSA-PSS-SHA3-512 RSA-PSS-SHA2-512 \
       RSA-PSS-RSAE-SHA3-256 RSA-PSS-RSAE-SHA2-256 \
       RSA-PSS-RSAE-SHA3-384 RSA-PSS-RSAE-SHA2-384 \
       RSA-PSS-RSAE-SHA3-512 RSA-PSS-RSAE-SHA2-512 \
       RSA-SHA3-256 RSA-SHA2-256 \
       RSA-SHA3-384 RSA-SHA2-384 \
       RSA-SHA3-512 RSA-SHA2-512 \
       ECDSA-SHA2-224 RSA-PSS-SHA2-224 RSA-SHA2-224 \
       ECDSA-SHA3-224 RSA-PSS-SHA3-224 RSA-SHA3-224
sign@DNSSec = RSA-SHA1+ ECDSA-SHA1+  # SHA1 is still prevalent in DNSSec
# Standardized in RFC 9980 (OpenPGP)
sign@{sequoia,RPM} = MLDSA65-ED25519+ MLDSA87-ED448+ \
    SLHDSA-SHAKE-128S+ SLHDSA-SHAKE-128F+ SLHDSA-SHAKE-256S+

cipher = AES-256-GCM AES-256-CCM CHACHA20-POLY1305 CAMELLIA-256-GCM \
    AES-256-CTR AES-256-CBC CAMELLIA-256-CBC AES-128-GCM AES-128-CCM \
    CAMELLIA-128-GCM AES-128-CTR AES-128-CBC CAMELLIA-128-CBC

cipher@TLS = AES-256-GCM AES-256-CCM CHACHA20-POLY1305 AES-256-CBC \
    AES-128-GCM AES-128-CCM AES-128-CBC

cipher@{sequoia,RPM} = AES-256-CFB AES-256-GCM AES-256-OCB AES-256-EAX \
    AES-128-CFB AES-128-GCM AES-128-OCB AES-128-EAX CAMELLIA-256-CFB CAMELLIA-128-CFB

# CBC ciphers in SSH are considered vulnerable to plaintext recovery attacks
# and disabled in client OpenSSH 7.6 (2017) and server OpenSSH 6.7 (2014).
cipher@SSH = -*-CBC

# 'RSA' is intentionally before DHE ciphersuites, as the DHE ciphersuites have
# interoperability issues in TLS.
key_exchange = KEM-ECDH ECDHE RSA DHE DHE-RSA PSK DHE-PSK ECDHE-PSK RSA-PSK ECDHE-GSS DHE-GSS

protocol@TLS = TLS1.3 TLS1.2 DTLS1.2
protocol@IKE = IKEv2

cipher@pkcs12 = AES-256-CBC AES-128-CBC
cipher@pkcs12-import = 3DES-CBC+ RC2-CBC+
cipher@smime = AES-256-CBC AES-128-CBC 3DES-CBC
cipher@smime-import = RC2-CBC+
hash@{pkcs12,smime} = SHA2-256 SHA2-384 SHA2-512 SHA3-256 SHA3-384 SHA3-512 \
    SHA2-224 SHA3-224
hash@{pkcs12-import,smime} = SHA1+
key_exchange@smime = RSA DH ECDH

# Parameter sizes
min_dh_size = 2048
min_dsa_size = 2048
min_rsa_size = 2048

# GnuTLS only for now
sha1_in_certs = 0

arbitrary_dh_groups = 1
ssh_certs = 1
etm@SSH = ANY

# https://pagure.io/fesco/issue/2960
# "RPM must accept SHA-1 hashes and DSA keys for Fedora 38"
sign@RPM = DSA-SHA1+
hash@RPM = SHA1+
min_dsa_size@RPM = 1024

In this file (at the very end), one can see, that SHA1 is explicitly allowed for RPM signing, so everything is fine. But Arch Linux doesn't have an equivalent to update-crypto-policies, as far as I understand.

So, my question is basically:

Is it possible for the dnf as installed in my Arch Linux host system to allow for SHA1 signed RPMs? And if so, how do I do that.

Any help is appreciated!

Cheers,
Ronny

P.S.: Building RPM packages for Fedora or older OpenSUSE (15.6) does work, though.
P.S.S.: Upstream issue filed under https://github.com/rpm-software-managem … ssues/1828 but it seems to be Arch Linux specific, this is why I'm posting it here as well....

Last edited by RaumZeit (2026-10-23 12:26:50)

Lone_Wolf · 2026-10-24 10:07:15

You have looked at https://wiki.archlinux.org/title/Creati … tributions ?

Note that mock is only mentioned for building fedora stuff.

Moderator Note
Moving to AUR Issues, Discussion & PKGBUILD Requests as is standard for issues with packages from AUR

Arch Linux

#1 2026-10-23 12:22:37

Howto properly set up mock (and certificates) to build OpenSuse RPMs

#2 2026-10-24 10:07:15

Re: Howto properly set up mock (and certificates) to build OpenSuse RPMs

Board footer