Better secret management for tokens and ids

[Hypercookie]

The clockify-cli uses an underlying YAML file located at ~/.clockify-cli.yaml to manage settings. This file also includes the userid, workspaceid, and token in plain text, which may not be desirable for all users.

While it is possible to set the token (and other IDs) via the command line, this approach is also insecure as it exposes the sensitive data in the command history. To address this, there are two secure alternatives that could be implemented:

• Credential Process Support
  Similar to the AWS config file, a credential_process parameter could be introduced, allowing users to specify a command responsible for securely returning the credential. For example, a user could configure credential_process: pass show clockify, enabling the pass utility to handle security and encryption. This parameter would be optional in the YAML file and, if present, would take precedence over any token supplied manually. This approach is more flexible, secure, and versatile, but it might be more challenging to implement.

• YAML !include Support
  Allow the YAML syntax to support !include, enabling users to reference another YAML file containing sensitive data. This secondary YAML file could be stored in a more secure location, such as a removable device, providing better protection for sensitive information.

While the first option offers greater security and flexibility, it is more complex to implement. Nevertheless, either approach would significantly enhance security for users.

I love this project and use it all the time, so I’d be thrilled to see these features implemented. While I’m not experienced in Go programming, I’ll take a look at the code to see if I can contribute in some way.

[lucassabreu]

hi @Hypercookie , i think we might try to use the OS keyring to protect the token and ids, there is some go libs that might helps us in that.

[Hypercookie]

Sounds good to me.

I would still advocate for also using the first option. Using the OS keyring will prevent declarative configurations like NixOS from working (which is what I use and also the reason I opened this ticket).

Thanks you for taking time to answer :)

[zevisert]

@Hypercookie I'm also a NixOS user and my solution to this is just to wrap the clockify-cli to provide a config from a secrets provider, basically I have something like this in my overlays:

{
  lib,
  config,
  makeWrapper,
  buildGoModule,
  fetchFromGitHub,
}:
buildGoModule rec {
  pname = "clockify-cli";
  version = "0.54.2";

  src = fetchFromGitHub {
    owner = "lucassabreu";
    repo = "clockify-cli";
    rev = "v${version}";
    hash = "sha256-Ffez1oEJdLQMuUB6LsLrOtOd0HFIr3kHCC6GOioeM8o=";
  };

  vendorHash = "sha256-L8jT328TEGbpVq5OwuQrSQdCU24Sb/dwvaty86l8n9Q=";

  buildInputs = [makeWrapper];

  postBuild = ''
    wrapProgram $out/bin/clockify-cli \
      --append-flags "--config ${config.age.secrets.clockify-cli-config.path}"
  '';

  meta = with lib; {
    description = "A simple cli to manage your time entries on Clockify from terminal";
    homepage = "https://github.com/lucassabreu/clockify-cli";
    license = licenses.asl20;
    maintainers = with maintainers; [zevisert];
  };
}

The important part is basically just that you can use wrapProgram from lib.makeWrapper to set a --config flag by default to always use the given config file containing a token. You could also use --set CLOCKIFY_TOKEN "${config.some-secret}" to just set the token, but there's drawbacks with that in that the token becomes world-readable in your /nix/store, and you might also need to set things like the workspace ID, but you could use --append-flags "--user-id ${...}" --append-flags "--workspace ${...}" --append-flags "--token ${...}", but those too would become readable within the /nix/store.

That's all to say, being able to configure where these options are read from a bit more would still be helpful