We can generate a keytab for you and send it via gpg. We would like you to ack that you are responsible for any actions this keytab is used for. Can you do so?

And where should I send it with what key?

We can generate a keytab for you and send it via gpg.

Thanks

We would like you to ack that you are responsible for any actions this keytab is used for. Can you do so?

Yes, but I would also like to ask @bgilbert to also say yes here and get the key sent to him as well.

And where should I send it with what key?

dusty@dustymabe.com - PGP key 3952E671

We would like you to ack that you are responsible for any actions this keytab is used for. Can you do so?

Yes, but I would also like to ask @bgilbert to also say yes here and get the key sent to him as well.

Ack.

My key is 4998ADDCD046D91D.

hey @kevin - can we do this today? also, will our bot account have a username? For example could we do something like: koji add-pkg coreos-pool htop --owner coreos-bot

Can you create a coreos-bot account in fas and set it's password? I can make it as bot and make the keytab and send it to you.

Can you create a coreos-bot account in fas and set it's password? I can make it as bot and make the keytab and send it to you.

Done - I had to use @coreosbot because it wouldn't allow for the - in the username.

I have created the keytab and mailed it (encrypted) to both of you. Make sure you store it securely.

Let us know if you need anything else.

:key:

this stopped working today:

2019-06-28 14:08:41,357 Running command: ['/usr/bin/koji', 'tag-build', 'f30-coreos-signing-pending', 'kernel-5.1.11-300.fc30']
2019-06-28 14:08:43,671 [ERROR] koji: ActionNotAllowed: policy violation (tag)

We need this to continue to work until we have the coreos-koji-tagger in prod.

actually looks like this is only an issue for tagging the kernel.. is that expected? Can we get it fixed?

related: https://pagure.io/releng/issue/8390 - but that was for untagging the kernel and not for tagging.

Yeah, so this is a secure boot perms issue.

It's denying you tagging/untagging secure-boot channel packages that you didn't build:

# CoreOS coreos-pool and coreos-release tags, https://pagure.io/releng/issue/8294
operation tag && tag coreos-pool coreos-release && has_perm coreos-continuous :: allow
operation untag && fromtag coreos-pool coreos-release && has_perm coreos-continuous :: allow
# deny tagging secureboot packages that are not related to coreos-continuous
package kernel shim grub2 fedora-release fedora-repos pesign :: deny

We cannot remove that rule, as it's the thing that protects provenpackagers from tagging in secure boot packages they built.

Perhaps we can do something like "operation tag && has_perm coreos-continious && package kernel shim ... :: allow
before the deny rule? but that basically means all those people in coreos-continous are basically just in secure-boot too.

Or we could say if you are trying to tag one of those, ask @bgilbert or other secureboot people to tag for you?

@mizdebsk any ideas?

could we write a rule that says

operation tag && has_perm coreos-continious && package kernel shim... && wasbuiltbysomeonewithsecureboot :: allow

The wasbuiltbysomeonewithsecureboot is the tricky part. i.e. we need this tool (coreos-koji-tagger) to be able to tag kernels into coreos-pool. Most of the time those kernels are actually just the normal kernel that one of the kernel team built and is already in fedora repos.

Until we sort this out, can I tag some things for you to unblock you for today?

Until we sort this out, can I tag some things for you to unblock you for today?

Thanks for the offer. We're good for today, no tagging needed.

@mizdebsk could we get you to see if you could work some magic and make up a policy rule that would work? For reference, see: https://pagure.io/fedora-infrastructure/issue/7821#comment-580062

@kevin @mizdebsk - This is now becoming a blocker for us I think. We need to be able to add those special secureboot packages to a tag and also then tag/untag new builds into those tags.

@kevin Not that relevant for solution, but: note, that policy is not doing what are you expecting. Lines with coreos will return as 'allow' and line with packages (deny) will be never evaluated.

You've to place it before coreos if it should block them from tagging kernel.

thanks to @tkopecek I now believe that this isn't actually a policy issue but rather an issue with our keytab not being associated with the coreos-continuous ruleset. My user (@dustymabe) can perform these actions but the keytab within our prod openshift instance does not have those permissions.

Can we please get those permissions added?

proof:

[dustymabe@hattop ~]$ 
[dustymabe@hattop ~]$ koji list-permissions --user coreos-koji-tagger/coreos-koji-tagger.fedoraproject.org@FEDORAPROJECT.ORG

Where my user has these permissions:

[dustymabe@hattop ~]$ koji list-permissions --user dustymabe
image
atomic
coreos-continuous

and in stage we have these permissions:

[dustymabe@hattop ~]$ stg-koji list-permissions --user coreos-koji-tagger/coreos-koji-tagger.stg.fedoraproject.org@STG.FEDORAPROJECT.ORG 
coreos-continuous

ok I think we should be able to fix this if someone can run:

koji grant-permission coreos-continuous coreos-koji-tagger/coreos-koji-tagger.fedoraproject.org@FEDORAPROJECT.ORG

Good detective work tracking that down.

Done.

thanks @kevin.. now we're on to the next issue :)

2019-08-20 15:06:46,795 Adding packages to the coreos-pool tag: {'fedora-repos'}
2019-08-20 15:06:46,961 Package adding done
2019-08-20 15:06:46,961 Tagging the following (tag, nvr):
        ('f30-coreos-signing-pending', 'fedora-repos-30-1')
2019-08-20 15:06:47,006 Caught Exception!
2019-08-20 15:06:47,006 ###################################
Traceback (most recent call last):
  File "./coreos_koji_tagger.py", line 248, in __call__
    self.process(message)
  File "./coreos_koji_tagger.py", line 354, in process
    for (tag, nvr) in tuples]
  File "/opt/koji/koji/__init__.py", line 3016, in __exit__
    self.call_all()
  File "/opt/koji/koji/__init__.py", line 2998, in call_all
    raise err
koji.ActionNotAllowed: policy violation (tag)
2019-08-20 15:06:47,008 ###################################
2019-08-20 15:06:47,008          continuing...

@tkopecek - are we sure we don't need any updates to the rules to allow secureboot packages?

You've permission only for those two tags: coreos-pool and coreos-release. If you need additional (f30-coreos-signing-pending), you need additional rules.

for some reason I thought those tags inherited (including permissions) from coreos-pool I guess that is not accurate ?

No, in policy are tags defined by globs, so something like f??-coreos-* could work (if it makes sense).

thanks @tkopecek. Here is my proposed patch to the infra repo:

From 5828997e5ef577a5fc18b83bfddcb3da46dcb060 Mon Sep 17 00:00:00 2001
From: Dusty Mabe <dusty@dustymabe.com>
Date: Tue, 20 Aug 2019 11:19:31 -0400
Subject: [PATCH] koji_hub: add policy for coreos signing pending tags

We tag into the signing-pending tags so that the builds
can get signed before being moved into the coreos-pool tag.
Allow for tagging into these signing-pending tags.
---
 roles/koji_hub/templates/hub.conf.j2 | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/roles/koji_hub/templates/hub.conf.j2 b/roles/koji_hub/templates/hub.conf.j2
index e9a3c3061..47c6a75f4 100644
--- a/roles/koji_hub/templates/hub.conf.j2
+++ b/roles/koji_hub/templates/hub.conf.j2
@@ -159,8 +159,11 @@ package_list =
     tag *infra* && has_perm infra && match action add unblock block :: allow
     # CoreOS continuous builds, https://pagure.io/releng/issue/8165
     tag f{{FedoraRawhideNumber}}-coreos-continuous f{{FedoraBranchedNumber}}-coreos-continuous f{{FedoraCycleNumber}}-coreos-continuous f{{FedoraPreviousCycleNumber}}-coreos-continuous && has_perm coreos-continuous && match action add unblock block :: allow
-    # CoreOS coreos-pool and coreos-release tags, https://pagure.io/releng/issue/8294
-    tag coreos-pool coreos-release && has_perm coreos-continuous && match action add unblock block :: allow
+    # CoreOS coreos-release tag https://pagure.io/releng/issue/8294
+    tag coreos-release && has_perm coreos-continuous && match action add unblock block :: allow
+    # CoreOS coreos-pool tag and intermediate signing tags that lead
+    # to coreos-pool https://pagure.io/releng/issue/8294
+    tag coreos-pool f{{FedoraRawhideNumber}}-coreos-signing-pending f{{FedoraBranchedNumber}}-coreos-signing-pending f{{FedoraCycleNumber}}-coreos-signing-pending f{{FedoraPreviousCycleNumber}}-coreos-signing-pending && has_perm coreos-continuous && match action add unblock block :: allow
     # Catch-all rule.
     all :: deny

-- 
2.20.1

If I can get a +1 I'll merge and then ask that person to run the playbook so we can apply the change.

Looks acceptable to me. +1 and I can run the playbook...

Looks acceptable to me. +1 and I can run the playbook...

Thanks. I pushed the commit so you can now run the playbook.

running.

All done, please test.

I believe all issues are resolved now. Thanks @tkopecek, @kevin and @mizdebsk