Add show/hide toggle for secret variables

[sanbhattdeep]

When we are creating collection/environment variables that contain secrets , there should be a toggle to show/hide the values
Bruno version:- v0.10.2

[helloanoop]

@sanbhattdeep Yes, this is on the roadmap.

I imagine an eye icon next to the delete button to toggle the visibility of the value.
When hidden, the value will be masked.

@ajaishankar Need your feedback on the DSL implications of above feature.
Currently, we save envs like below.

vars {
   host: https://api.github.com
   ~token: secret
}

The ~ means the var is disabled. But now, we also need to store if a var is actually hidden in the UI.

I am thinking to add a new tag called as vars:hidden

vars: hidden {
  token: secret
}

[inneon]

I had also commented in #122 that maybe a different way to store secret values would be to put them into a separate env file. For example you might have a test environment with the following 2 file:

test.bru

vars {
   host: https://api.github.com
}

test.secret.bru

vars {
  token: secret
}

The advantage would be that you can add .secret.bru to .gitignore and the secrets will not be stored in source control.

[ajaishankar]

@helloanoop sorry for the late reply...

Questions:

1. What is the purpose of a secret variable
   • Is it just to be masked in the UI?
   • Or is it to make sure it is not stored plaintext in source control
2. When a user adds a secret variable do we expect it to be available to other users
3. If the main goal is not to store secret variables in plaintext in source control, would it make sense to encrypt it?

In the DSL, we could store secret vars as follows.

vars {
   token: $secret$<encrypted value>
}

The above scheme would allow a team to just share a key with members instead of a .git ignored secret file.

[helloanoop]

@ajaishankar we want to mask it in the UI. We also don't want to check-in plain text secrets

So we have two options

1. Store the secret using a strong symmetric encryption (AES256), that can only be decoded after the users enters the right key. This key can be shared across users

2. The .env-name.secret.bru pattern where the secrets will not be checked in.

We could also do the best of the both worlds where secrets get stored in .secret.bru file

And a meta tag inside that optionally specify the encryption and the encryption algo. Ex:
environments/staging.secret.bru

meta {
   encrypted: true,
   algo: aes256
}

vars {
   token: 2yidjdhye735e6hshsg
}

I do like us to be as less opinionated as possible and give a wide variety options for people on how they want to manage the secrets.

@ajaishankar @inneon thoughts?

[ajaishankar]

IMO the secret.bru might be unnecessary for vars... If we really want users to control the algorithm, similar to bcrypt hash we can simply store a secret var as

vars {
   token: $alg$<encrypted-value>
}

Not sure how vars specified (only) in a secret .git ignored file would work when another dev pulls the collection from git.

[helloanoop]

Not sure how vars specified (only) in a secret .git ignored file would work when another dev pulls the collection from git.

Let's say that a company has a strict policy of not checking in secrets in git. (even encrypted). The company might be using a centralised secret management to share passwords.

In that case, the .secret.bru file can be added in .gitignore so that devs dont accidentally don't checkin secret variables. The UI will automatically save any secret vars (based on a toggle icon in the UI) in the .secret file.

This was @inneon point in #122

token: $alg$encrypted-value

Nice, I like this simpler approach of specifying algo.

[ajaishankar]

Understood the concept.

My only point was

1. I add a secret variable
2. Bruno stores it locally in .secret.bru which is git ignored
3. Another dev clones the collection
4. Bruno is not able to list the secret variable in the UI since it's in a git ignored file

if we have to get this to work then Bruno would have to save a secret variable as this.

staging.bru

vars {
  token: $secret$
}

staging.secret.bru

vars {
   token: actual-value
}

Exactly what yourself and @inneon suggested. Took me a while to understand 😄

There is no need for encryption in this approach. Let's avoid it...

[ajaishankar]

To answer the DSL question, imo the following reads nice... There is this variable token whose value is a secret

vars {
  token: $secret$
}

[sanjai0py]

Closing this!

The PR adding this feature has been merged and released in v1.12.3