nfpm: Signed RPMs failed to install via yum/dnf on RHEL7/CentOS7

I also just wanted to mention that in general that generated package is strange and missing all manner of regular, important and even required tags. No released version of rpm produces packages like this.

For instance it’s missing SHA1HEADER and SIGMD5 tags, the latter being required by LSB for example. RHEL 7 rpm doesn’t support the SHA256 digests that are present in the package, and while the signature that is there is technically supported, it’s a header+payload signature which cannot be used during installation (rpmsign creates both a header-only and header+payload signatures), so there’s no supported means to verify it!

So just FYI.

Cisco.

So nfpm receives the data which needs to be signed from https://github.com/google/rpmpack and sends an armored detached signature created with /x/crypto/openpgp back to rpmpack which then embeds it in the rpm.

I can’t reproduce the behaviour with freshly generated keys. For me it just works on centos7 and centos8. However, I used RSA keys and we also just test with RSA keys. The output of your last message shows that the package signed with rpm was also signed with RSA keys and your broken packages was signed with DSA keys. I also found this serverfault thread that mentions that rpm can be picky with different key algorithms and key sizes https://serverfault.com/questions/624888/bad-signatures-or-nokey-errors-on-rpms-i-just-signed. So I guess the problem is your key.

Could you please test it with an RSA key? I would also generally recommend not to use DSA keys anymore (read https://buttondown.email/cryptography-dispatches/archive/557475c5-9781-47e0-a640-5734bc849bc7 for more information).

If the key algorithm is indeed the problem, we should document it an check the key algorithm in internal/sign.

I found some differences. The first one was signed with rpm on centos7, the second one with goreleaser:

rpm -Kv create-go-app-0.7.3-1.x86_64.rpm 
create-go-app-0.7.3-1.x86_64.rpm:
    Header V4 RSA/SHA1 Signature, key ID f8427f69: NOKEY
    Header SHA1 digest: OK (f836250b71747d741d673ce21bf03ccf50a8be64)
    V4 RSA/SHA1 Signature, key ID f8427f69: NOKEY
    MD5 digest: OK (e6f2d85b628144c9f49ba427004d5697)
[root@601e401c62bc tmp]# rpm -Kv lslbgen-0.0.3.x86_64.rpm         
lslbgen-0.0.3.x86_64.rpm:
    V4 DSA/SHA256 Signature, key ID 499702cb: NOKEY

Need to remove the replace once google/rpmpack#53 is merged… will leave this issue open until then 😃

Thanks @djgilcrease @erikgeiser @zbindenren 🚀

@djgilcrease you said you were working on a fix? Do you already have an idea what might be the cause?

My best would be either a bug in rpm or a policy difference between downloads and local installs where different digest/signature tags in the rpm are checked/required. No real evidence to support that guess though. But if this is indeed the case it would probably have to be fixed in rpmpack.

I think the issue could be fixed in nfpm. Changing the PGPSigner to use MD5 fixes the issue, which just tells me we are not setting a field properly to set the Algo used to verify the pgp. Will keep digging to see if I can find the field and value that needs to be set.

func PGPSigner(keyFile, passphrase string) func([]byte) ([]byte, error) {
	return func(data []byte) ([]byte, error) {
		key, err := readSigningKey(keyFile, passphrase)
		if err != nil {
			return nil, &nfpm.ErrSigningFailure{Err: err}
		}

		var signature bytes.Buffer

		err = openpgp.DetachSign(&signature, key, bytes.NewReader(data), &packet.Config{
			DefaultHash: crypto.MD5,
		})
		if err != nil {
			return nil, &nfpm.ErrSigningFailure{Err: err}
		}

		return signature.Bytes(), nil
	}
}