@Standing-Man I looked at skipping the login view in case credentials already exist in the config file. In the PR I started working on the login view is skipped in case credentials are present.

I think the number of times a user might invoke login after creating a config file is limited. However, the additional login view might be annoying this is true.

Concerning storing the password in the config file, do you think obfuscation to base64 would be enough or would be plans for storing an encrypted pwd more suitable?

Hi @qcserestipy, Thank you very much for your contributions. Since we are considering encrypting the password in plaintext and then decrypting it during login, we have made a trade-off between security and convenience. Additionally, it would be great if you could add some examples of how to use the config flag in the README. At the same time, this is just a suggestion with some gaps on my part. If you have a better implementation in mind, feel free to bring your ideas to life!

Hi @Standing-Man, I added some info to the readme and also to the docs, feel free to have a look at it. Converning the encryption I totally agree with you. Does it make sense to discuss for a while what mechanism would be desirable? I think there are different solutions with different level of complexity and finding out which is good and which might be overkill is maybe good. Shall we start such kind of a discussion somewhere?

The command documentation in the "doc" folder could potentially be automatically generated using Dagger.

maybe there are some option to use TPM?

• https://github.com/facebookincubator/sks
• https://github.com/google/go-tpm
• https://github.com/google/go-tpm-tools
• https://github.com/FiloSottile/age, is great but only in combination with TPM or such. otherwise, it is not a great UX and encourages the user to skip handling the keys.
• https://github.com/remko/age-plugin-se
  -https://github.com/Foxboron/age-plugin-tpm
• https://github.com/FiloSottile/awesome-age -> giving the various options of age, if hey can be used in the SDK, this could be an easy and standerdized way to store the secrets securly across linux, mac, windows.

Last but not least, just using kyrings might be, exactly. what we need.

• https://github.com/99designs/keyring
• https://github.com/zalando/go-keyring

@Vad1mo Thank you for your comments on that! I was playing around with the zalando/go-keyring plugin and it seems quite easy to use. In the latest commit to the PR i added an encryption.go that uses this library. In the login password are encrypted and stored in the file, whereas on client creation the password is decrypted for the harbor api client. The config file then looks similar to this:

I am on a darwin arm64 mac, in case people use another os, please feel free to test this code.

@Vad1mo, @Standing-Man I removed the WIP tag from the PR and would be happy about any of your feedback.
I added a mockKeyRing provider, an interface for the zalando keyring, a test for the encryption functionality and adapted the present tests to work with the mockKeyRing in the dagger container.