The 'Raspberry Pi Archive Signing Key':

pub   rsa2048 2012-06-17 [SC]
      CF8A 1AF5 02A2 AA2D 763B  AE7E 82B1 2992 7FA3 303E
uid           [ unknown] Raspberry Pi Archive Signing Key
sub   rsa2048 2012-06-17 [E]
      DE5C 1FD2 8F18 8253 91E9  2B58 F7BB 0489 EDD8 3D6C

as included in stage0/files/raspberrypi.gpg use SHA-1 signatures (exclusively).

This is probably not too problematic security-wise if you copied the proper key (i.e. the one with CF8A1AF502A2AA2D763BAE7E82B129927FA3303E fingerprint). The subkey is used only for encryption, which is not a function used by an Archive key.

Yet, it's enough to make debootstrap fail on a modern OS:

Begin /root/pi-gen/stage0/prerun.sh
I: Target architecture can be executed
I: Retrieving InRelease 
I: Checking Release signature
E: Invalid Release signature

debootstrap.log shows:

Signing key on A0DA38D0D76E8B5D638872819165938D90FDDD2E is not bound:
           No binding signature at time 2025-08-23T22:30:30Z
  because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resista
nce
  because: SHA1 is not considered secure since 2023-02-01T00:00:00Z

Steps to reproduce:

• Run pi-gen on a vanilla trixie image for armhf architecture
  (oddly, it does validate it in the arm64)

Steps to fix it:

gpg -u A0DA38D0D76E8B5D638872819165938D90FDDD2E --force-sign-key  --quick-sign-key A0DA38D0D76E8B5D638872819165938D90FDDD2E

gpg -o raspberrypi.gpg --export A0DA38D0D76E8B5D638872819165938D90FDDD2E
gpg --armor -o raspberrypi.gpg.key --export A0DA38D0D76E8B5D638872819165938D90FDDD2E

Ideally, the final trixie images would ship already with the updated key.

The raspberrypi-archive-keyring already has the updated keys, so it should be just a matter of updating stage0/files/raspberrypi.gpg on pi-gen repository (and, while we are at it, http://archive.raspberrypi.com/debian/raspberrypi.gpg.key which is the same version that was in the repo)

I have confirmed that updating stage0/files/raspberrypi.gpg from raspberrypi-archive-keyring` solves the issue.

PS: It is also possible to workaround this by changing the crypto policy to always trust sha1, but the real fix is to update the key signature, which is harmless (in comparison, an upgrade to a bigger rsa key would be much more complicated).