tvc: init CLI #74

emostov · 2026-01-18T00:03:23Z

Introduce TVC CLI with login, app, and deployment commands

Supersedes

socket-security · 2026-01-18T00:03:40Z

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	assert_cmd@2.1.1
	toml@0.8.22
	predicates@3.1.3
	x509-cert@0.2.5
	clap@4.5.54

View full report

r-n-o

I haven't looked at the details of each command, just browsed through top-to-bottom to get a lay of the land. First impression: looks great! 👏

r-n-o · 2026-01-20T15:55:30Z

codegen/src/main.rs

+            let is_internal = http_opts
+                .contains("option (google.api.method_visibility).restriction = \"INTERNAL\"");
+            let is_tvc = fn_name.contains("tvc");
+            if is_internal && !is_tvc {
+                // Skip internal-only endpoints (except TVC endpoints)
                continue;


I could make these endpoint non-internal, they're feature-flagged already. So there's no real "danger". I'm just a bit cautious because of the other SDKs (JS, Golang, etc...users might get confused if they see "TVC" activities. With the right docstring though ("BETA"), maybe not.

I'm in favor of keeping them internal and having some extra complexity here. I don't want them leaking into API spec docs and then confusing people

r-n-o · 2026-01-20T15:58:29Z

tvc/README.md

@@ -0,0 +1,41 @@
+# Experimental CLI for Turnkey Verifiable Cloud
+
+## Usage


Something I'm wondering: possible to have e2e tests for tvc CLI? We can start small, but I think having a harness will pay off

I see them! They're here, but at the very end of the diff (tvc/tests)

🐐

They are pretty simple for now and don't fully test functionality with the API - but they should at least check basics like the expected arguments

r-n-o · 2026-01-20T16:02:25Z

tvc/src/commands/deploy/status.rs

+/// Run the deploy status command.
+pub async fn run(args: Args) -> anyhow::Result<()> {
+    println!("Getting status for deploy: {}", args.deploy_id);
+    todo!("deploy status not yet implemented")
+}


I think this should be possible with the latest protos? There's a GetDeployment endpoint you can leverage. Or maybe you mean kubernetes level status?

That's a good point. I was originally thinking this would be for k8s type status. We implicitly call GetDeployment in in deploy approve

Maybe what I can do is fill this current stub with GetDeployment, and then we can add another API call and combine the info

r-n-o · 2026-01-20T16:06:39Z

tvc/src/config/turnkey.rs

+/// API key stored in api_key.json
+#[derive(Debug, Clone, Serialize, Deserialize)]
+pub struct ApiKey {
+    /// Hex-encoded compressed public key
+    pub public_key: String,
+    /// Hex-encoded private key
+    pub private_key: String,
+}


Might be worth reusing the ApiKey struct from here?

rust-sdk/api_key_stamper/src/lib.rs

Lines 56 to 60 in 06a000d

/// Represents a Turnkey API key using the P-256 curve.

#[derive(Debug, PartialEq)]

pub struct TurnkeyP256ApiKey {

signing_key: P256SigningKey,

}

One thing you're missing if you want this to be generic is the curve / scheme

I will add curve so we are more generic

The idea with this struct is that is represents how its stored on disk. While the TurnkeyP256ApiKey is the abstraction for actually using/generating the p256 key. I'll rename it to StoredApiKey

r-n-o · 2026-01-20T16:07:47Z

tvc/src/config/turnkey.rs

+/// Operator key stored in operator.json
+#[derive(Debug, Clone, Serialize, Deserialize)]
+pub struct OperatorKey {
+    /// Hex-encoded compressed public key
+    pub public_key: String,
+    /// Hex-encoded private key
+    pub private_key: String,
+}


Same here I think a scheme could be beneficial. Although...if you make the struct "QOSOperatorKey" it's clear enough that it'll be whatever QOS expects, which is a seed + 2 derived keys

r-n-o · 2026-01-20T16:08:46Z

tvc/src/config/turnkey.rs

+    }
+}
+
+impl ApiKey {


These impl should probably move to their own module so we can test them in isolation

r-n-o · 2026-01-20T16:10:39Z

tvc/src/pair.rs

+/// Something that can do key pair operations with the QOS p256 scheme.
+pub trait Pair: Send + Sync {


Why a trait as opposed to implementing on QOSOperatorKey? Do you envision a lot of "something"s? :D

EDIT: oh, I see the vision. Of course: remote operator keys (vs local ones)

Disregard my comment

Yubikey, TKMS, Password encrypted file etc

emostov added 3 commits January 17, 2026 18:59

Introduce TVC CLI with login, app, and deployment commands

e949bea

Update protos and codegen for TVC support

cdb95d4

Add known quorum key and share set support for TVC

fa4f6d2

emostov force-pushed the zeke/tvc-cli branch from d20547b to a3e79b9 Compare January 20, 2026 06:01

Use get deployment to fetch manifest

7b6cb01

emostov force-pushed the zeke/tvc-cli branch from a3e79b9 to 7b6cb01 Compare January 20, 2026 15:35

r-n-o reviewed Jan 20, 2026

View reviewed changes

emostov added 2 commits January 20, 2026 13:57

Rename stored api key and operator key

a67549c

impl tvc deploy status

eb57deb

		@@ -0,0 +1,41 @@
		# Experimental CLI for Turnkey Verifiable Cloud

		## Usage

	/// Represents a Turnkey API key using the P-256 curve.
	#[derive(Debug, PartialEq)]
	pub struct TurnkeyP256ApiKey {
	signing_key: P256SigningKey,
	}

		/// Something that can do key pair operations with the QOS p256 scheme.
		pub trait Pair: Send + Sync {

tvc: init CLI #74

Are you sure you want to change the base?

tvc: init CLI #74

Uh oh!

Conversation

emostov commented Jan 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

socket-security bot commented Jan 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

r-n-o left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

emostov commented Jan 18, 2026 •

edited

Loading

socket-security bot commented Jan 18, 2026 •

edited

Loading