public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: "Frank Ch. Eigler" <fche@redhat.com>
To: koji-devel@lists.fedorahosted.org
Cc: elfutils-devel@sourceware.org
Subject: preservation of signed rpms
Date: Thu, 26 Jan 2023 14:37:44 -0500	[thread overview]
Message-ID: <20230126193744.GA6496@redhat.com> (raw)

Hi -

Recently, fedora koji has started applying per-file (IMA) signatures
to RPMs it has built.  This is in addition to the overall GPG
signature of the RPM payload as a whole.  While this extra capability
is not yet fully developed in userspace, we do have one ready user
(elfutils debuginfod [1]), which is unfortunately frustrated by a
policy in the koji code base.

That policy problem is the periodic pruning of signed RPMs.  That is,
"koji prune-signed-copies" is run on the fedora infra every now and
then.  This operation nukes data/signed/KEYHEX/ARCH/N-V-R.rpm files.
While it leaves behind data/sigcache/ARCH/*, those files appear not to
include the IMA signature content.  That means the IMA signatures are
simply lost, like tears in rain.

We'd like to correct this somehow - to make the IMA signatures
available indefinitely - at least as long as the built RPMs stay of
any interest.  (That means: not restricted to the most-recent-update
of a given fedora release.) 

But how?

1) have the pruning operate by replacing the unsigned binaries with the
   signed ones (hardlink or rename)?

2) have the pruning operate on the unsigned binaries, preserving the
   signed ones?

3) preserve the IMA signature content somewhere nearby (sigcache?)
   to give us a chance at finding the data there after a prune

4) ---> some other way? <---


[1] https://fedoraproject.org/wiki/Debuginfod


- FChE


                 reply	other threads:[~2023-01-26 19:37 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230126193744.GA6496@redhat.com \
    --to=fche@redhat.com \
    --cc=elfutils-devel@sourceware.org \
    --cc=koji-devel@lists.fedorahosted.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).