From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 5AA083858C2F for ; Thu, 26 Jan 2023 19:37:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5AA083858C2F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1674761867; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=eyfA88t0brVcc4v7LhkycynKkQAOza3HQEhEuuw764I=; b=WPP40AJjNW2DKpB7bOwZwROti0qAj2QSuX4/vzRg+7iynRXbUXFU1T5EFWlRi+57KjLlJD Z4uhPerIVrokq9nLTF8tKia9AK04wDAk2b2tuLPYIeXJMn7mV/hX8TIdIODha/YtGrCoj3 /kzV5VrFbpnPzOFdEDIs9wgEIRc9Jug= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-106-LBNsq9OnNxOvn1r3EL2DnA-1; Thu, 26 Jan 2023 14:37:45 -0500 X-MC-Unique: LBNsq9OnNxOvn1r3EL2DnA-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 7964D3C10ECC; Thu, 26 Jan 2023 19:37:45 +0000 (UTC) Received: from redhat.com (unknown [10.2.16.86]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6A143492C14; Thu, 26 Jan 2023 19:37:45 +0000 (UTC) Received: from fche by redhat.com with local (Exim 4.94.2) (envelope-from ) id 1pL848-0001t0-I9; Thu, 26 Jan 2023 14:37:44 -0500 Date: Thu, 26 Jan 2023 14:37:44 -0500 From: "Frank Ch. Eigler" To: koji-devel@lists.fedorahosted.org Cc: elfutils-devel@sourceware.org Subject: preservation of signed rpms Message-ID: <20230126193744.GA6496@redhat.com> MIME-Version: 1.0 User-Agent: Mutt/1.12.0 (2019-05-25) X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-8.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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