Skip to content

data/repositories/rhel-8*.json: don't include the "auxiliary key 2" (HMS-5915) - #1330

Merged
achilleas-k merged 1 commit into
osbuild:mainfrom
thozza:RHEL-71397
Mar 17, 2025
Merged

data/repositories/rhel-8*.json: don't include the "auxiliary key 2" (HMS-5915)#1330
achilleas-k merged 1 commit into
osbuild:mainfrom
thozza:RHEL-71397

Conversation

@thozza

@thozza thozza commented Mar 17, 2025 •
edited by schutzbot
Loading

Copy link
Copy Markdown
Member

The osbuild/images go module supports distro cross-building. This means that you can build images for a different distribution than the one you are running on. For example, you can build a RHEL-8 image on RHEL-9. Nevertheless, the supported combinations are controlled by the end users of the osbuild/images go module.

The rhel-8*.json repository definitions have been modified to contain only the 4096R/199e2f91fd431d51 (2009-10-22): Red Hat, Inc. (release key 2) <security@redhat.com> as specified at Red Hat Product Signing keys page. The4096R/F76F66C3D4082792 (2018-06-27): Red Hat, Inc. (auxiliary key 2) <security@redhat.com> is completely omitted from the rhel-8*.json repository definitions. The reasons are:

  • The Red Hat, Inc. (auxiliary key 2) is signed only with RSA-SHA1, which is not allowed by the default crypto-policy on RHEL-9 and newer. This means that importing such key when bootstrapping the RHEL-8 buildroot on RHEL-9 and newer would fail.
  • The Red Hat, Inc. (auxiliary key 2) is not commonly used for signing the RHEL-8 RPMs. It is a disaster recovery key that would be used in the unlikely event Red Hat loses the ability to sign with the master hardware keys. The key file uses a sub-key, that would be most probably used to sign RPMs in this unlikely event, so that the main key can be stored offline. Previously, we used to ship only the auxiliary key, without the sub-key in rhel-8*.json configurations on RHEL-9, because only the sub-key's signature was causing issues when importing it on RHEL-9 with the default crypto-policy. However, given the purpose of the sub-key, there's no reason to include the main key in the rhel-8*.json configurations without the sub-key.
  • None of the projects that use the repository definitions in the osbuild/images go module (osbuild-composer, image-builder-cli, etc.) are being released or updated in RHEL-8. The rhel-8*.json repository definitions are used only for cross-building RHEL-8 images on RHEL-9 and newer.

JIRA: HMS-5915

@thozza
data/repositories/rhel-8*.json: don't include the "auxiliary key 2"
5ec9f5a 
The `osbuild/images` go module supports distro cross-building. This
means that you can build images for a different distribution than the
one you are running on. For example, you can build a RHEL-8 image on
RHEL-9. Nevertheless, the supported combinations are controlled by the
end users of the `osbuild/images` go module.

The `rhel-8*.json` repository definitions have been modified to contain
only the [`4096R/199e2f91fd431d51 (2009-10-22): Red Hat, Inc. (release
key 2) <security@redhat.com>`](
https://security.access.redhat.com/data/fd431d51.txt) as specified at
[Red Hat Product Signing keys page](
https://access.redhat.com/security/team/key). The
[`4096R/F76F66C3D4082792 (2018-06-27): Red Hat, Inc. (auxiliary key 2)
<security@redhat.com>`](
https://security.access.redhat.com/data/d4082792.txt) is completely
omitted from the `rhel-8*.json` repository definitions. The reasons
are:
 * The `Red Hat, Inc. (auxiliary key 2)` is signed only with RSA-SHA1,
   which is not allowed by the default crypto-policy on RHEL-9 and
   newer. This means that importing such key when bootstrapping the
   RHEL-8 buildroot on RHEL-9 and newer would fail.
 * The `Red Hat, Inc. (auxiliary key 2)` is not commonly used for
   signing the RHEL-8 RPMs. It is a disaster recovery key that would
   be used in the unlikely event Red Hat loses the ability to sign with
   the master hardware keys. The key file uses a sub-key, that would be
   most probably used to sign RPMs in this unlikely event, so that the
   main key can be stored offline. Previously, we used to ship only the
   auxiliary key, without the sub-key in `rhel-8*.json` configurations
   on RHEL-9, because only the sub-key's signature was causing issues
   when importing it on RHEL-9 with the default crypto-policy. However,
   given the purpose of the sub-key, there's no reason to include the
   main key in the `rhel-8*.json` configurations without the sub-key.
 * None of the projects that use the repository definitions in the
   `osbuild/images` go module (`osbuild-composer`, `image-builder-cli`,
   etc.) are being released or updated in RHEL-8. The `rhel-8*.json`
   repository definitions are used only for cross-building RHEL-8
   images on RHEL-9 and newer.

Signed-off-by: Tomáš Hozza <thozza@redhat.com>
@thozza
thozza requested a review from a team as a code owner March 17, 2025 10:12
supakeen
supakeen approved these changes Mar 17, 2025
View reviewed changes

@supakeen supakeen left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some nice detective work (and documentation).

achilleas-k
achilleas-k approved these changes Mar 17, 2025
View reviewed changes

@achilleas-k achilleas-k left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!! Great to finally know what's going on here :)

@achilleas-k
achilleas-k added this pull request to the merge queue Mar 17, 2025
Merged via the queue into osbuild:main with commit 6d56359 Mar 17, 2025
@thozza
thozza deleted the RHEL-71397 branch March 17, 2025 17:29
@thozza thozza changed the title data/repositories/rhel-8*.json: don't include the "auxiliary key 2" (RHEL-71397) data/repositories/rhel-8*.json: don't include the "auxiliary key 2" Apr 3, 2025
@thozza

thozza commented Apr 3, 2025

Copy link
Copy Markdown
Member Author

/jira-epic COMPOSER-2473

@schutzbot schutzbot changed the title data/repositories/rhel-8*.json: don't include the "auxiliary key 2" data/repositories/rhel-8*.json: don't include the "auxiliary key 2" (HMS-5915) Apr 3, 2025
croissanne added a commit to croissanne/image-builder-crc that referenced this pull request Mar 3, 2026
@croissanne
distributions/rhel-8.10: don't include the "auxiliary key 2"
5e8a449 
This is based on osbuild/image-builder#1330.

The `rhel-8*.json` repository definitions have been modified to contain
only the [`4096R/199e2f91fd431d51 (2009-10-22): Red Hat, Inc. (release
key 2) <security@redhat.com>`](
https://security.access.redhat.com/data/fd431d51.txt) as specified at
[Red Hat Product Signing keys page](
https://access.redhat.com/security/team/key). The
[`4096R/F76F66C3D4082792 (2018-06-27): Red Hat, Inc. (auxiliary key 2)
<security@redhat.com>`](
https://security.access.redhat.com/data/d4082792.txt) is completely
omitted from the `rhel-8*.json` repository definitions. The reasons
are:
 * The `Red Hat, Inc. (auxiliary key 2)` is signed only with RSA-SHA1,
   which is not allowed by the default crypto-policy on RHEL-9 and
   newer. This means that importing such key when bootstrapping the
   RHEL-8 buildroot on RHEL-9 and newer would fail.
 * The `Red Hat, Inc. (auxiliary key 2)` is not commonly used for
   signing the RHEL-8 RPMs. It is a disaster recovery key that would
   be used in the unlikely event Red Hat loses the ability to sign with
   the master hardware keys. The key file uses a sub-key, that would be
   most probably used to sign RPMs in this unlikely event, so that the
   main key can be stored offline. Previously, we used to ship only the
   auxiliary key, without the sub-key in `rhel-8*.json` configurations
   on RHEL-9, because only the sub-key's signature was causing issues
   when importing it on RHEL-9 with the default crypto-policy. However,
   given the purpose of the sub-key, there's no reason to include the
   main key in the `rhel-8*.json` configurations without the sub-key.
 * None of the projects that use the repository definitions in the
   `osbuild/images` go module (`osbuild-composer`, `image-builder-cli`,
   etc.) are being released or updated in RHEL-8. The `rhel-8*.json`
   repository definitions are used only for cross-building RHEL-8
   images on RHEL-9 and newer.
@croissanne croissanne mentioned this pull request Mar 3, 2026
Merged
croissanne added a commit to croissanne/image-builder-crc that referenced this pull request Mar 3, 2026
@croissanne
distributions/rhel-8.10: don't include the "auxiliary key 2"
0585279 
This is based on osbuild/image-builder#1330.

The `rhel-8*.json` repository definitions have been modified to contain
only the [`4096R/199e2f91fd431d51 (2009-10-22): Red Hat, Inc. (release
key 2) <security@redhat.com>`](
https://security.access.redhat.com/data/fd431d51.txt) as specified at
[Red Hat Product Signing keys page](
https://access.redhat.com/security/team/key). The
[`4096R/F76F66C3D4082792 (2018-06-27): Red Hat, Inc. (auxiliary key 2)
<security@redhat.com>`](
https://security.access.redhat.com/data/d4082792.txt) is completely
omitted from the `rhel-8*.json` repository definitions. The reasons
are:
 * The `Red Hat, Inc. (auxiliary key 2)` is signed only with RSA-SHA1,
   which is not allowed by the default crypto-policy on RHEL-9 and
   newer. This means that importing such key when bootstrapping the
   RHEL-8 buildroot on RHEL-9 and newer would fail.
 * The `Red Hat, Inc. (auxiliary key 2)` is not commonly used for
   signing the RHEL-8 RPMs. It is a disaster recovery key that would
   be used in the unlikely event Red Hat loses the ability to sign with
   the master hardware keys. The key file uses a sub-key, that would be
   most probably used to sign RPMs in this unlikely event, so that the
   main key can be stored offline. Previously, we used to ship only the
   auxiliary key, without the sub-key in `rhel-8*.json` configurations
   on RHEL-9, because only the sub-key's signature was causing issues
   when importing it on RHEL-9 with the default crypto-policy. However,
   given the purpose of the sub-key, there's no reason to include the
   main key in the `rhel-8*.json` configurations without the sub-key.
 * None of the projects that use the repository definitions in the
   `osbuild/images` go module (`osbuild-composer`, `image-builder-cli`,
   etc.) are being released or updated in RHEL-8. The `rhel-8*.json`
   repository definitions are used only for cross-building RHEL-8
   images on RHEL-9 and newer.
croissanne added a commit to osbuild/image-builder-crc that referenced this pull request Mar 3, 2026
@croissanne
distributions/rhel-8.10: don't include the "auxiliary key 2"
ae1d08f 
This is based on osbuild/image-builder#1330.

The `rhel-8*.json` repository definitions have been modified to contain
only the [`4096R/199e2f91fd431d51 (2009-10-22): Red Hat, Inc. (release
key 2) <security@redhat.com>`](
https://security.access.redhat.com/data/fd431d51.txt) as specified at
[Red Hat Product Signing keys page](
https://access.redhat.com/security/team/key). The
[`4096R/F76F66C3D4082792 (2018-06-27): Red Hat, Inc. (auxiliary key 2)
<security@redhat.com>`](
https://security.access.redhat.com/data/d4082792.txt) is completely
omitted from the `rhel-8*.json` repository definitions. The reasons
are:
 * The `Red Hat, Inc. (auxiliary key 2)` is signed only with RSA-SHA1,
   which is not allowed by the default crypto-policy on RHEL-9 and
   newer. This means that importing such key when bootstrapping the
   RHEL-8 buildroot on RHEL-9 and newer would fail.
 * The `Red Hat, Inc. (auxiliary key 2)` is not commonly used for
   signing the RHEL-8 RPMs. It is a disaster recovery key that would
   be used in the unlikely event Red Hat loses the ability to sign with
   the master hardware keys. The key file uses a sub-key, that would be
   most probably used to sign RPMs in this unlikely event, so that the
   main key can be stored offline. Previously, we used to ship only the
   auxiliary key, without the sub-key in `rhel-8*.json` configurations
   on RHEL-9, because only the sub-key's signature was causing issues
   when importing it on RHEL-9 with the default crypto-policy. However,
   given the purpose of the sub-key, there's no reason to include the
   main key in the `rhel-8*.json` configurations without the sub-key.
 * None of the projects that use the repository definitions in the
   `osbuild/images` go module (`osbuild-composer`, `image-builder-cli`,
   etc.) are being released or updated in RHEL-8. The `rhel-8*.json`
   repository definitions are used only for cross-building RHEL-8
   images on RHEL-9 and newer.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@achilleas-k achilleas-k achilleas-k approved these changes
@supakeen supakeen supakeen approved these changes
@mvo5 mvo5 Awaiting requested review from mvo5 mvo5 is a code owner automatically assigned from osbuild/osbuild-reviewers
@schuellerf schuellerf Awaiting requested review from schuellerf schuellerf is a code owner automatically assigned from osbuild/osbuild-reviewers

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@thozza @achilleas-k @supakeen