2 ms·

That's a good step in the right direction. Curious if they will ever remove the PGP keys out of the public mirrors. That would be my next step. RPM's can be

by Bender 1y ago

That's a good step in the right direction. Curious if they will ever remove the PGP keys out of the public mirrors. That would be my next step. RPM's can be resigned with any keys and said keys can be replaced in a mirror. It would eventually be caught but I prefer not to have people accustom to these dark patterns in the first place. Keys used to validate RPMs need to be served from locked down servers and companies with internal mirrors must find a secure way to cache and serve them internally.

westurner 1y ago
From https://man7.org/linux/man-pages/man5/yum.conf.5.html https://man7.org/linux/man-pages/man5/yum.conf.5.html : [ $ man yum.conf | grep -C 5 -i gpg ] gpgkey list of strings URLs of a GPG key files that can be used for signing metadata and packages of this repository, empty by default. If a file can not be verified using the already imported keys, import of keys from this option is attempted and the keys are then used for verification. gpgkey_dns_verification Should the dnf attempt to automatically verify GPG verification keys using the DNS system. This option requires the unbound python module (python3-unbound) to be installed on the client system. This system has two main features. The first one is to check if any of the already installed keys have been revoked. Automatic removal of the key is not yet available, so it is up to the user, to remove revoked keys from the system. The second feature is automatic verification of new keys when a repository is added to the system. In interactive mode, the result is written to the output as a suggestion to the user. In non-interactive mode (i.e. when -y is used), this system will automatically accept keys that are available in the DNS and are correctly signed using DNSSEC. It will also accept keys that do not exist in the DNS system and their NON-existence is cryptographically proven using DNSSEC. This is mainly to preserve backward compatibility. Default is False. RPM packages' GPG key(s) can be specified in a .repo file, which can be updated by an RPM package from a repo with or without mandatory signing configured. Typically, all packages in a repo are built with CI build containers that all share the same signing key. How to bootstrap the [Sigstore [TLS] pubkey, HKP (TLS) pubkey], to verify the [Sigstore hash, GPG .asc signature] of the manifest containing the [Sigstore, SHA-X] hash for each package and/or package file?

by Bender 1y ago

westurner 1y ago

From https://man7.org/linux/man-pages/man5/yum.conf.5.html https://man7.org/linux/man-pages/man5/yum.conf.5.html : [ $ man yum.conf | grep -C 5 -i gpg ] gpgkey list of strings URLs of a GPG key files that can be used for signing metadata and packages of this repository, empty by default. If a file can not be verified using the already imported keys, import of keys from this option is attempted and the keys are then used for verification. gpgkey_dns_verification Should the dnf attempt to automatically verify GPG verification keys using the DNS system. This option requires the unbound python module (python3-unbound) to be installed on the client system. This system has two main features. The first one is to check if any of the already installed keys have been revoked. Automatic removal of the key is not yet available, so it is up to the user, to remove revoked keys from the system. The second feature is automatic verification of new keys when a repository is added to the system. In interactive mode, the result is written to the output as a suggestion to the user. In non-interactive mode (i.e. when -y is used), this system will automatically accept keys that are available in the DNS and are correctly signed using DNSSEC. It will also accept keys that do not exist in the DNS system and their NON-existence is cryptographically proven using DNSSEC. This is mainly to preserve backward compatibility. Default is False. RPM packages' GPG key(s) can be specified in a .repo file, which can be updated by an RPM package from a repo with or without mandatory signing configured. Typically, all packages in a repo are built with CI build containers that all share the same signing key. How to bootstrap the [Sigstore [TLS] pubkey, HKP (TLS) pubkey], to verify the [Sigstore hash, GPG .asc signature] of the manifest containing the [Sigstore, SHA-X] hash for each package and/or package file?