Bug 1299508

Description of problem:

This has been previously covered in bug 998 as well as subsequent "duplicates" like bug 1090682, however it got always mixed up with importing the keys into the installed system, transport-level security (https) or other "chicken & egg" issues.
This bug tries to propose a more generic and technically doable and verifiable solution to the problem.

First, **this bug doesn't care about the keys on the installed system**, these should be provided by one or more of the packages under installation and are out of the scope of anaconda (presumably).

Second, this bug addresses a possible security issue where a mirror/distributor could alter an install-time package - since signatures are not currently checked during installation, the user would get a potentially malicious package.

Starting from the "egg", the anaconda liveimg / kernel+initrd / bootloader, this could be - and already is - checksummed with a strong hash, the user can therefore easily verify the validity of the anaconda environment.
It should be thus possible to store/ship the necessary keys as part of the anaconda image, making it possible to verify even the base installation (which may be - and often is - an untrusted network mirror).

I assume the core of this issue is *how*, as such mechanism could be considered a hard-to-maintain hack. One possible solution is to make a more generic "API" (ie. a directory in /etc/pki) that users/companies could use during generation of their custom ISO images, adding their own keys, re-distributing the ISO under a new checksum to their users/employees.
The same mechanism would be used by Fedora/RHEL, providing release keys in what would hopefully be a documented and organized way.

This bug therefore requests such a feature (with no restrictions on implementation details) and its use by Fedora.

--------------
David Cantrell mentioned (in bug 1090682):

> The core issue that I think you're getting at is the same as the discussion
> that has been going on in bug #998 for a long time.  It's a bootstrapping
> issue.  We cannot provide GPG keys on the install media in order to check
> signatures on packages because there's no way to trust those keys.  We have
> to provide the GPG keys externally and insist that users add them to their
> local RPM configuration before signature verification can work.

As shown above, this is depends on how one looks at things - the installation medium can be trusted as it can be easily verified to be intact, as opposed to trusting the entire Everything repository (and more) which the user would have to download to check all RPM signatures externally, not knowing which packages anaconda selects for installation.


Version-Release number of selected component (if applicable):
anaconda-24.9-1.fc24


Additional info:
It would be useful to optionally utilize the keyring for the 'repo' kickstart command (ie. with something like --gpgcheck), although this can be filed separately.