RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1209159 - GPG signature issues
Summary: GPG signature issues
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: releng
Version: 7.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Jon Disnard
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks: 1219619 1252599
TreeView+ depends on / blocked
 
Reported: 2015-04-06 14:01 UTC by Colin Walters
Modified: 2017-03-03 15:14 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-03-03 15:14:50 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1358942 0 unspecified CLOSED deployments shown as '(unsigned)' in output of 'rpm-ostree status' despite being signed 2021-02-22 00:41:40 UTC

Internal Links: 1358942

Description Colin Walters 2015-04-06 14:01:19 UTC 
TL;DR:

- Change stage candlepin to turn on GPG verifiction and test it
- Update https://access.redhat.com/articles/1366233 to describe "ostree.gpgsigs" and link to upstream changes
- Possibly in addition, actually implement above method in rel-eng (for how long?)

Longer:

Current RHELAH releases are signed using the "ostree.gpgsigs" detached metadata key, which is also what the ostree client tool is capable of verifying.

However, we presently have gpg-verify=false set via production/stage candlepin -> subscription-manager.

In order to turn on automatic verification, we need some testing in the stage environment of OSTree gpg.


Now, a further issue is that this article: https://access.redhat.com/articles/1366233 only details an alternative manual method created because in the GA version of ostree there is not a "commandline-able" way to verify the signature conveniently.  This script can do it: https://github.com/cgwalters/ostree-scripts/blob/master/ostree-script-gpgverify

Improved GPG status functionality is built into the latest version of ostree https://github.com/GNOME/ostree/pull/77
and will be in 7.1.2.

If we want the current article to work, we need to change rcm-follin https://code.engineering.redhat.com/gerrit/gitweb?p=rcm-follin.git;a=summary to implement it in addition.  (And how long do we want to carry dual signature schemes?)
Comment 1 Colin Walters 2015-04-06 14:04:02 UTC 
For clarity, let's call the two schemes "ostree.gpgsigs" and "redhatrelease2".
Comment 3 Colin Walters 2015-09-17 20:59:34 UTC 
Brendan, this one needs someone to turn it on in stage candlepin.  Would you know who to have make that happen?
Comment 5 Colin Walters 2015-09-28 13:19:04 UTC 
To verify signatures today:

# atomic host status
  TIMESTAMP (UTC)         VERSION     ID             OSNAME               REFSPEC                                                        
* 2015-07-31 13:17:47     7.1.4       23e5e89ba5     rhel-atomic-host     rhel-atomic-host-ostree:rhel-atomic-host/7/x86_64/standard     
  2015-07-24 15:03:31     7.1.3.1     34b9bb94a7     rhel-atomic-host     rhel-atomic-host-ostree:rhel-atomic-host/7/x86_64/standard     
# ostree show 23e5e89ba5
commit 23e5e89ba5ee33fbdcf76f4fb7802db16019b661ddb5dab42c24a399f02d762c
Date:  2015-07-31 13:17:47 +0000
Version: 7.1.4


Found 1 signature:

  Signature made Fri 31 Jul 2015 02:33:07 PM UTC using RSA key ID 199E2F91FD431D51
  Good signature from "Red Hat, Inc. <security>"
#
Comment 6 Alexander Todorov 2015-09-29 11:55:01 UTC 
(In reply to Colin Walters from comment #5)

> Found 1 signature:
> 
>   Signature made Fri 31 Jul 2015 02:33:07 PM UTC using RSA key ID
> 199E2F91FD431D51
>   Good signature from "Red Hat, Inc. <security>"
> #


Do we have other key IDs which QE should be aware of ? e.g. Beta and GA keys ?
Comment 7 Colin Walters 2015-09-29 14:04:15 UTC 
(In reply to Alexander Todorov from comment #6)
> (In reply to Colin Walters from comment #5)
> 
> > Found 1 signature:
> > 
> >   Signature made Fri 31 Jul 2015 02:33:07 PM UTC using RSA key ID
> > 199E2F91FD431D51
> >   Good signature from "Red Hat, Inc. <security>"
> > #
> 
> 
> Do we have other key IDs which QE should be aware of ? e.g. Beta and GA keys

I believe the ostree commit key will follow the RPM content, if the RPMs used the beta key, the ostree commit should as well.  Only RCM can answer this question definitively though.
Comment 8 Stanislav Graf 2015-09-30 11:55:37 UTC 
(In reply to Alexander Todorov from comment #6)
> Do we have other key IDs which QE should be aware of ? e.g. Beta and GA keys
> ?

Product Signing (GPG) Keys
https://access.redhat.com/security/team/key
Comment 13 Lubos Kocman 2017-03-03 15:14:50 UTC 
Closing as insufficient data. Please re-open issue if this would be still actual.

Lubos
Note You need to log in before you can comment on or make changes to this bug.