1:37 p.m.
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
1:52 p.m.
Koji instances have control over how they run prune-signed-copies. It is
possible to not run it at all
The only difference between a signed copy and the original is the signature
header, which is kept under the sigcache dir even when a signed copy is
deleted. Signed copies can be recreated with a call to writeSignedRPM,
which simply splices the requested header in to make the copy.
When I was first informed about the IMA signing plan, I was told that the
ima signatures were all in the signature header. If this is not the case,
then the whole process is deeply flawed.
On Tue, Feb 21, 2023 at 2:31 PM Frank Ch. Eigler <fche(a)redhat.com> wrote:
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
_______________________________________________
koji-devel mailing list -- koji-devel(a)lists.fedorahosted.org
To unsubscribe send an email to koji-devel-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/koji-devel@lists.fedorahoste...
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
2:02 p.m.
On Tue, Feb 21, 2023 at 02:52:49PM -0500, Michael McLean wrote:
Koji instances have control over how they run prune-signed-copies. It
is
possible to not run it at all
The only difference between a signed copy and the original is the signature
header, which is kept under the sigcache dir even when a signed copy is
deleted. Signed copies can be recreated with a call to writeSignedRPM,
which simply splices the requested header in to make the copy.
When I was first informed about the IMA signing plan, I was told that the
ima signatures were all in the signature header. If this is not the case,
then the whole process is deeply flawed.
I think they have to be... because the way our signing works, sigul
signs the rpms and imports the signatures into koji, then asks koji to
write out the signed rpm.
So, the information has to be there, there's no where else it would have
come from.
kevin
2:30 p.m.
Good point. For that matter the only way to sign rpms in koji is to upload
(only) the signature header.
So it seems we're already at option 3
On Tue, Feb 21, 2023 at 3:02 PM Kevin Fenzi <kevin(a)scrye.com> wrote:
On Tue, Feb 21, 2023 at 02:52:49PM -0500, Michael McLean wrote:
> Koji instances have control over how they run prune-signed-copies. It is
> possible to not run it at all
>
> The only difference between a signed copy and the original is the
signature
> header, which is kept under the sigcache dir even when a signed copy is
> deleted. Signed copies can be recreated with a call to writeSignedRPM,
> which simply splices the requested header in to make the copy.
>
> When I was first informed about the IMA signing plan, I was told that the
> ima signatures were all in the signature header. If this is not the case,
> then the whole process is deeply flawed.
I think they have to be... because the way our signing works, sigul
signs the rpms and imports the signatures into koji, then asks koji to
write out the signed rpm.
So, the information has to be there, there's no where else it would have
come from.
kevin
_______________________________________________
koji-devel mailing list -- koji-devel(a)lists.fedorahosted.org
To unsubscribe send an email to koji-devel-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/koji-devel@lists.fedorahoste...
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
9:06 a.m.
Dne 21. 02. 23 v 20:52 Michael McLean napsal(a):
Koji instances have control over how they run prune-signed-copies. It
is possible to not run it at all
The only difference between a signed copy and the original is the
signature header, which is kept under the sigcache dir even when a
signed copy is deleted. Signed copies can be recreated with a call to
writeSignedRPM, which simply splices the requested header in to make
the copy.
I wonder why the signed copies don't replace the originals, if there is
no difference? Why the unsigned copies are kept while the signed are
not. Why the signed copies are not directly accessible from the Koji UI?
Vít
When I was first informed about the IMA signing plan, I was told that
the ima signatures were all in the signature header. If this is not
the case, then the whole process is deeply flawed.
On Tue, Feb 21, 2023 at 2:31 PM Frank Ch. Eigler <fche(a)redhat.com> wrote:
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
_______________________________________________
koji-devel mailing list -- koji-devel(a)lists.fedorahosted.org
To unsubscribe send an email to
koji-devel-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/koji-devel@lists.fedorahoste...
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
koji-devel mailing list --koji-devel(a)lists.fedorahosted.org
To unsubscribe send an email tokoji-devel-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List
Archives:https://lists.fedorahosted.org/archives/list/koji-devel@lists.fe...
Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
9:39 a.m.
There is a difference. The signed rpms are signed. They are not the same
files. They have different checksums.
It is however a small and confined difference because of the way rpm
signing works.
We keep the originals because they are the originals. Once a build is
imported into Koji, we treat it as immutable. Also note that we support
multiple signatures, and there's really no way to do that without this kind
of separation.
On Wed, Feb 22, 2023 at 10:06 AM Vít Ondruch <vondruch(a)redhat.com> wrote:
Dne 21. 02. 23 v 20:52 Michael McLean napsal(a):
Koji instances have control over how they run prune-signed-copies. It is
possible to not run it at all
The only difference between a signed copy and the original is the
signature header, which is kept under the sigcache dir even when a signed
copy is deleted. Signed copies can be recreated with a call to
writeSignedRPM, which simply splices the requested header in to make the
copy.
I wonder why the signed copies don't replace the originals, if there is no
difference? Why the unsigned copies are kept while the signed are not. Why
the signed copies are not directly accessible from the Koji UI?
Vít
When I was first informed about the IMA signing plan, I was told that the
ima signatures were all in the signature header. If this is not the case,
then the whole process is deeply flawed.
On Tue, Feb 21, 2023 at 2:31 PM Frank Ch. Eigler <fche(a)redhat.com> wrote:
> 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
> _______________________________________________
> koji-devel mailing list -- koji-devel(a)lists.fedorahosted.org
> To unsubscribe send an email to koji-devel-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/koji-devel@lists.fedorahoste...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
_______________________________________________
koji-devel mailing list -- koji-devel(a)lists.fedorahosted.org
To unsubscribe send an email to koji-devel-leave(a)lists.fedorahosted.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/koji-devel@lists.fedorahoste...
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
koji-devel mailing list -- koji-devel(a)lists.fedorahosted.org
To unsubscribe send an email to koji-devel-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/koji-devel@lists.fedorahoste...
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
441
days inactive
468
days old
koji-devel@lists.fedorahosted.org
5 comments
4 participants
participants (4)
-
Frank Ch. Eigler -
Kevin Fenzi -
Michael McLean -
Vít Ondruch