Introducing protobuf file for the new /uuid endpoint

[cshari-zededa]

• Once attestation feature is enabled in Controller, the /config endpoint
  will fail incoming requests without an integrity token associated with the
  request. As a result, the initial getUuid() method in zedclient will fail,
  since it starts early before attestation, and at that point system will not
  have any integrity token available.

• Since zedclient uses /config primarily for getting UUID of the device and other
  fields such as Manufacturer, Model etc, having a separate endpoint for that
  makes sense, and this PR adds protobuf fields for the same.

Signed-off-by: Hariharasubramanian C S cshari@zededa.com

[eriknordmark]

Should we also remove the ConfigRequest using a URL without the UUID? That is in the APIv4.md file

[eriknordmark]

@kalyan-nidumolu are these protobuf errors you expect to see?
uuid/uuid.proto:8:1:Expected "uuidpb" for option "go_package" but was "github.com/lf-edge/eve/api/go/uuid".
uuid/uuid.proto:9:1:Expected "com.org.lfedge.eve.uuid" for option "java_package" but was "org.lfedge.eve.uuid".
uuid/uuid.proto:11:1:Expected "UuidProto" for option "java_outer_classname" but was "EveUuid".

I don't know if prototool would have the same complaints on our existing proto files in which case we can ignore them.

[cshari-zededa]

@kalyan-nidumolu are these protobuf errors you expect to see?
uuid/uuid.proto:8:1:Expected "uuidpb" for option "go_package" but was "github.com/lf-edge/eve/api/go/uuid".
uuid/uuid.proto:9:1:Expected "com.org.lfedge.eve.uuid" for option "java_package" but was "org.lfedge.eve.uuid".
uuid/uuid.proto:11:1:Expected "UuidProto" for option "java_outer_classname" but was "EveUuid".

I don't know if prototool would have the same complaints on our existing proto files in which case we can ignore them.

@eriknordmark
When I ran "make yetus" on my local branch, I am getting the same lint errors for the existing files as well. e.g. for attest:

Hariharasubramanians-MacBook-Pro:eve cshari$ cat /private/tmp/yetus-out/diff-patch-prototool.txt | grep attest
attest/attest.proto:10:1:Expected "attestpb" for option "go_package" but was "github.com/lf-edge/eve/api/go/attest".
attest/attest.proto:11:1:Expected "com.org.lfedge.eve.attest" for option "java_package" but was "org.lfedge.eve.attest".
attest/attest.proto:13:1:Expected "AttestProto" for option "java_outer_classname" but was "EveAttest".

Now, either I can fix the lint errors or we can ignore the yetus errors (to keep the naming conventions consistent with existing files), please let me know what you prefer.

[eriknordmark]

LGTM

Let's ignore the yetus/prototool complaints

[rvs]

Hey @cshari-zededa @nordmark @deitch -- one sentence here caught my eye "Once attestation feature is enabled in Controller, the /config endpoint will fail incoming requests without an integrity token associated with the request" -- that's fine from the controller's standpoint (IOW controller forcing this behavior) but I wanted to make sure that we don't accidentally break V1 API compatibility with this change.

We rely heavily on V1 API in Adam still (V2 work is getting delayed there) and making sure it keeps working is a pretty high priority. Please confirm.

On a related note @cshari-zededa those few paragraphs from the description of this PR is what I was suggesting you add to your integrity token PR as part of updating docs/SECURITY.md

[cshari-zededa]

Hey @cshari-zededa @nordmark @deitch -- one sentence here caught my eye "Once attestation feature is enabled in Controller, the /config endpoint will fail incoming requests without an integrity token associated with the request" -- that's fine from the controller's standpoint (IOW controller forcing this behavior) but I wanted to make sure that we don't accidentally break V1 API compatibility with this change.

Yes @rvs, V1 compatibility is not disturbed. In fact, we have not started enforcing integrity-token yet in any of the Controller, including ZedControl. These PRs are just setting it up from EVE side. But even when we enforce integrity-token check, we will do it only for V2 /config endpoint.

But this also means that we should add /uuid support in Adam, before we can start replacing /config with /uuid in zedclient.

[rvs]

Got it! Filed lf-edge/adam#38 @giggsoff @deitch -- can you guys please take a look ASAP?