jku / repository-playground

Community artifact repository workflow experiments
Other
7 stars 4 forks source link

Bundle of fixes #99

Closed jku closed 1 year ago

jku commented 1 year ago

Three separate fixes I found while testing:

jku commented 1 year ago

these could probably all be tested... I wish creating tests like this would be easier

kommendorkapten commented 1 year ago

Hm, this PR seems a bit broken?

I had a root with one keyolder (me), then I ran playground-delegate add-1foo:

% playground-delegate add-1foo
Remote branch not found: branching off from main
Enter name of role to modify: root
Modifying delegation for root

Configuring role root
 1. Configure signers: [@kommendorkapten], requiring 1 signatures
 2. Configure expiry: Role expires in 365 days, re-signing starts 60 days before expiry
Please choose an option or press enter to continue: 1
Please enter list of root signers [@kommendorkapten]: @kommendorkapten,@1foo
Please enter root threshold [1]:
 1. Configure signers: [@kommendorkapten, @1foo], requiring 1 signatures
 2. Configure expiry: Role expires in 365 days, re-signing starts 60 days before expiry
Please choose an option or press enter to continue:

Configuring signing key
 1. Sigstore (OpenID Connect)
 2. Yubikey
Please choose the type of signing key you would like to use [1]: 2
Please insert your Yubikey and press enter:
Press enter to push changes to origin/add-1foo:
Enumerating objects: 9, done.
Counting objects: 100% (9/9), done.
Delta compression using up to 10 threads
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 597 bytes | 597.00 KiB/s, done.
Total 5 (delta 2), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
remote:
remote: Create a pull request for 'add-1foo' on GitHub by visiting:
remote:      https://github.com/kommendorkapten/tuf-repo-test-1/pull/new/add-1foo
remote:
To github.com:kommendorkapten/tuf-repo-test-1.git
 * [new branch]      HEAD -> add-1foo

After that I got a new metadata file for root, but no invite/state file. And the diff for root.json looks wrong:

diff --git a/metadata/root.json b/metadata/root.json
index 5b0e928..bada54d 100644
--- a/metadata/root.json
+++ b/metadata/root.json
@@ -2,13 +2,13 @@
  "signatures": [
   {
    "keyid": "d7d2d47a3f644fc3a685bac7b39c81ed9f9cee48ff861b44fbd86b91e34e7829",
-   "sig": "3046022100b658e5fdca5e755c1db4cee0a8bc87bcecc7e90f13ab912f3c03458ad7d3be9e022100c6e707723c4a289637f2c9aa8ab86bdd555d34b47e2c8a0582d1587c47ceefd4"
+   "sig": ""
   }
  ],
  "signed": {
   "_type": "root",
   "consistent_snapshot": true,
-  "expires": "2024-05-31T11:44:06Z",
+  "expires": "2024-06-07T12:36:12Z",
   "keys": {
    "8b4af6aec66518bc66718474aa15c8becd3286e8e2b958c497a60a828d591d04": {
     "keytype": "ecdsa",
@@ -24,7 +24,7 @@
      "public": "-----BEGIN PUBLIC KEY-----\nMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgA
E++Wv+DcLRk+mfkmlpCwl1GUi9EMh\npBUTz8K0fH7bE4mQuViGSyWA/eyMc0HvzZi6Xr0diHw0/lUPB
vok214YQw==\n-----END PUBLIC KEY-----\n"
     },
     "scheme": "ecdsa-sha2-nistp256",
-    "x-playground-keyowner": "@kommendorkapten"
+    "x-playground-keyowner": "@1foo"
    }
   },
   "roles": {
@@ -58,7 +58,7 @@
    }
   },
   "spec_version": "1.0.31",
-  "version": 1,
+  "version": 2,
   "x-playground-expiry-period": 365,
   "x-playground-signing-period": 60
  }

Instead my key was transferred to the new user (1foo).

kommendorkapten commented 1 year ago

Also the branch becomes a bit strange locally:

% git status
On branch add-1foo
Your branch and 'origin/add-1foo' have diverged,
and have 1 and 1 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)
kommendorkapten commented 1 year ago

It looks like the actual commit was the same locally and remote, but for some reason they end up having different commit SHA.

jku commented 1 year ago
-    "x-playground-keyowner": "@kommendorkapten"
+    "x-playground-keyowner": "@1foo"

are yous sure you weren't pretending to be 1foo in the config file?

jku commented 1 year ago

btw, please use user names that don't exist on GH for testing: it's easy to accidentally start sending notifications otherwise

kommendorkapten commented 1 year ago

btw, please use user names that don't exist on GH for testing: it's easy to accidentally start sending notifications otherwise

Yes, that was my idea, I was under the impression that starting with a digit is not allowed. Sorry for this.

kommendorkapten commented 1 year ago

are yous sure you weren't pretending to be 1foo in the config file?

Yes, that probably was the case 🤦 Re-ran invite and signing today and it all worked.