providers: implement SOPS provider

[euphemism]

Hey all,

This implements a SOPS-backed provider, supporting the full range of SOPS capabilities (I think [I am unable to realistically test this]).

This is some LLM output that I am in the process of cleaning up, but I wanted to get the draft in front of you for some initial feedback. Instead of using a re-implementation of SOPS à la rops, this uses Rust's FFI support to interop with the Go library through a C FFI. I feel more comfortable with this from a security perspective, and it allows for utilizing the full feature set/API surface of SOPS.

Closes #5

[domenkozar]

Could we for starters use sops cli?

[euphemism]

@domenkozar to clarify: Are you saying as part of an MVP to utilize the SOPS CLI and later explore this direct integration with the SOPS code, or are you saying this is a direction you don't want to go down at all? Using the CLI means requiring having that separately installed, but I suppose that's the standard approach for the integrations supported by secretspec.

[domenkozar]

I'd also be fine using sops-ffi if it was an externally maintained crate

[euphemism]

I'd also be fine using sops-ffi if it was an externally maintained crate

Ah, but I don't want to maintain it either 😅. When I get around to it I'll refactor this to assume the sops CLI is available in the environment.

[euphemism]

@domenkozar Just listened to the Devenv 2.0 Full Time Nix episode and heard you mentioning the FFI-based approach for the SOPS integration 😅.

[domenkozar]

@domenkozar Just listened to the Devenv 2.0 Full Time Nix episode and heard you mentioning the FFI-based approach for the SOPS integration 😅.

I think it's the right way long term, but I really want to maintain it separately. Maybe we create a repo on cachix and then transfer it over?

[euphemism]

@domenkozar Just listened to the Devenv 2.0 Full Time Nix episode and heard you mentioning the FFI-based approach for the SOPS integration 😅.

I think it's the right way long term, but I really want to maintain it separately. Maybe we create a repo on cachix and then transfer it over?

Okay, I've parked the current implementation at https://github.com/euphemism/secretspec/tree/sops-integration-via-ffi. I will rework this MVP to call out to the SOPS CLI.

[euphemism]

Okay, back to square one (ish). Invokes the SOPS CLI. Still need to do a heavy review and refactor pass on all of this generated code, and flesh out the test cases.

[euphemism]

Initial review and refactor done. Getting closer, not quite yet ready to transition out of draft. Some further refactoring and tests writing remains.

[euphemism]

[euphemism]

This did not appear to be a thing?

[euphemism]

@domenkozar This is generally ready for review.

[euphemism]

I added an entry to the table here, but apart from the table this page seems vestigial? It is duplication of content available on the individual providers' pages.

[euphemism]

Relatedly, should the icons be inverted i.e. No gets a green check and Yes gets a red cross?

[euphemism]

The testing workflows are failing for a few reasons. The non-Windows ones are failing here:

• Running tests
Process exited (Failure), restarting
Restarted (attempt 1)
sh: line 1: astro: command not found

> docs@0.0.1 dev
> astro dev

Implying Node modules are not being installed, so in attempt to address this I set languages.javascript.directory = "./docs" in devenv.nix. since languages.javascript.npm.install is set to true.

The Windows run fails with:

Provider operation failed: The 'sops' CLI is not installed.
Install it from https://github.com/getsops/sops or via your package manager.

This makes sense, devenv provides sops to the environment, but devenv is not used for the Windows tests. I added a step to download the latest SOPS binary into the workspace.

[domenkozar]

uri() leaks credentials into the audit log (secretspec/src/provider/sops/mod.rs)

uri() re-emits every set field into the query string, including secrets like age_key, aws_secret_access_key, hc_vault_token, and google_oauth_access_token. The Provider::uri() contract requires it to be credential free since it goes to the audit log and fallback warnings. Every other provider already does this (onepassword drops the token and emits only account@vault, etc.).

Please emit only the file location plus non-secret attribution and drop the credential params. The values still reach sops via apply_env, so behavior is unchanged. Suggest adding a secret: bool to FieldSpec so uri() can skip secret fields and new fields must declare themselves.

(Not caught today because uri_never_echoes_a_userinfo_password only tests the URL password position, which SOPS never reads.)

[euphemism]

uri() leaks credentials into the audit log (secretspec/src/provider/sops/mod.rs)

uri() re-emits every set field into the query string, including secrets like age_key, aws_secret_access_key, hc_vault_token, and google_oauth_access_token. The Provider::uri() contract requires it to be credential free since it goes to the audit log and fallback warnings. Every other provider already does this (onepassword drops the token and emits only account@vault, etc.).

Please emit only the file location plus non-secret attribution and drop the credential params. The values still reach sops via apply_env, so behavior is unchanged. Suggest adding a secret: bool to FieldSpec so uri() can skip secret fields and new fields must declare themselves.

(Not caught today because uri_never_echoes_a_userinfo_password only tests the URL password position, which SOPS never reads.)

Oops. Added a sensitive field to FieldSpec, and I have added two tests to address this:

• test_sops_provider_sensitive_fields_correctly_marked
• test_sops_provider_uri_drops_sensitive_fields

test_sops_provider_sensitive_fields_correctly_marked validates that these fields are marked as sensitive:

• age_key
• aws_secret_access_key
• azure_client_secret
• hc_vault_token
• huawei_sdk_ak
• huawei_sdk_sk
• google_oauth_access_token

I believe this is the sum total of sensitive fields, but you should probably double check this.