Initial commit

[alicefr]

Create first version of the pin.
The test.sh script tries to encrypt and unlock a device and can be used for some manual testing.
In order to perform the encryption, you need to have trustee running and set its url in the data.json. Additionally, you also need to upload the secret, and you can use the test-secret-trustee as example.
I have uploaded the secret using the kbs-client from trustee:

$ target/debug/kbs-client --url http://localhost:8080  config --auth-private-key kbs/config/private.key  set-resource --path conf-cluster/root/machine --resource-file test-secret-trustee

Clevis expect to have the encrypt and decrypt scripts, so I have created those scripts in my local enviroment:

cat /usr/local/sbin/clevis-encrypt-trustee
#!/bin/bash

/home/afrosi/src/clevis-pin-trustee/target/debug/clevis-pin-trustee encrypt "$@"

and

cat /usr/local/sbin/clevis-decrypt-trustee
#!/bin/bash

/home/afrosi/src/clevis-pin-trustee/target/debug/clevis-pin-trustee decrypt "$@"

Clevis looks for the scripts automatically based on the name of the pin

[alicefr]

need to fix this

[travier]

Not tested but looking good. Comments can be addressed as a follow up PR as well. Let's not forget to add a LICENSE to this repo immediately as well.

[travier]

We can probably have only one "path" variable here and have the logic of figuring out what is in there be in another tool.

[alicefr]

I split it because of the tag/id, this needs to be part of the path as well, so would you prefer to have a partial path here?

[travier]

You can use the derive pattern with structures to make this easier to read. See https://github.com/confidential-clusters/compute-pcrs/blob/main/cli/src/main.rs#L10 for an example.

[sarroutbi]

In general, changes LGTM. The only comment is that the logic for fetching the key, decoding it, and creating a Jwk is nearly identical in both the encrypt and decrypt functions.

You might create a helper function to handle this logic

[alicefr]

@travier @uril as far as I understand we need to pass to the trustee-agent the certificate for the trustee sever, am I right? If so, don't we need here an array of certificates like for the urls? If so, then I would merge the urls together with the certificate for the pin configuration. Like:

{
  "servers": [
      {
         "url": "http://trustee1:8080",
          "cert": "",
      },
      {
         "url": "http://trustee2:8080",
          "cert": "",
      },   
  ],
  "resource_path": "conf-cluster/<id>/root",
}

[alicefr]

The pin configuration depends on the discussion in coreos/ignition#2099

[uril]

@alicefr Yes, we do want a list of (KBSURL, https-certificate).

[uril]

Nice ! I added some minor comments.

[travier]

Looking good. Some nits but we can also fix them later

[travier]

Let's use a Fedora image here to do the build. We can do what we did in compure-pcrs.

[travier]

Hum, why do we need that? Let's place the binaries in the right place directly?

[travier]

This is fine for now but we'll need to make this either bigger or configurable.

[travier]

We can import CI from https://github.com/confidential-clusters/compute-pcrs/blob/main/.github/workflows/rust.yml and https://github.com/confidential-clusters/compute-pcrs/blob/main/.github/workflows/buildroot.yml

[travier]

Let's start with that and we'll iterate