Package is called "SecretManager" but command is "user-secrets"?

[analogrelay]

It seems odd to me that installing SecretManager enables the user-secrets command. I think the command should be named a little differently. Also, user-secrets is exteremly generic... I'd prefer something like aspnet-secrets or dnx-secrets.

I really like aspnet-secrets as a prelude to possibly introducing a more generic aspnet command that behaves like git (where git foo is just rewritten as a call to git-foo). Then the command would (eventually) be something more like aspnet secrets set, etc.

[analogrelay]

And yes, I realize that the secrets aren't ASP.NET-specific, they are part of Config which is generic, but we're targetting ASP.NET scenarios with it right now, we can always "broaden" the name later.

[blowdart]

I dislike dnx-secrets and aspnet-secrets because they're not either of those things, they are user secrets which happen to be used by asp.net apps.

[victorhurdugaci]

1. dnx-vault?
2. secret-config ?

[blowdart]

No dnx- something please.

secret-vault is interesting though.

[analogrelay]

Fair points @blowdart. I still like aspnet- as the prefix (since the "secrets" aren't really a "DNX" concept)

Since this is basically external user-level configuration, how about aspnet-config or aspnet-vault?

[analogrelay]

Not putting a prefix on it concerns me. We're entering the global namespace of user commands then. Are we trying to create a general purpose application-secret management system? Not really... Should user-secrets really be a peer to dir/ls?

[blowdart]

Oh go on then, aspnet-vault (if only because I started playing Borderlands 2 last night, and vault wins by default)

[Praburaj]

Thanks @anurse for bringing this up.

@Eilon @davidfowl @DamianEdwards @blowdart @anurse @rustd can we come to a consensus on this work item?

1. Current proposal is to go with aspnet-vault. Though the tool and the configuration extensions can work on a console app as well.
2. Changing the package name to the same name as the command will be useful as users don't have to remember the package name is different from command name. How about AspNet-Vault for the package name?

[analogrelay]

For the record, I slightly prefer aspnet-config as this is a tool for managing configuration data for ASP.NET applications. Yes, it only manages user-level configuration (for now) and can manage more than just ASP.NET applications (DNX Console Apps), but I still think that name is clearer. The aspnet- prefix makes sense to me because it's easier to broaden it later than to try and scope it down again (and dnx-config sounds weird). I prefer the config suffix because this is designed to manage user-level development-time configuration, and is not encrypted, secured or protected in any way so using the term secrets is a bit iffy. vault is better but still implies some kind of secure storage to me. config implies, to me, that it's where I should go to manage configuration data, which is what we're trying to achieve here.

[analogrelay]

Also, if the Package ID is going to match the command name (which it should), we shouldn't arbitrarily mess with casing. I'd go with an all lower-case Package ID.

[blowdart]

I don't know if I like aspnet-config because it's not meant for general config is it? It's mean for sensitive, hidden, don't check into source control by accident type things.

[MisterJames]

I'm going to ask a really naive question here, but if you're not encrypting things, and there is no intent to check things in, then why not just create something that targets env vars (at a user level)?

It would seem to me that to create yet another place to manage project info seems superfluous, especially in a way that would differ from what's currently compatible with runtime environments (Azure, linux, WinServer, etc).

What am I missing?

[davidfowl]

The plan is to encrypt it. It also gives you a per app secret store for free instead of having to juggle env variables for different apps potentially on the same machine. That can get messy.

[MisterJames]

@davidfowl That sounds better...it's just that @anurse's comment above seemed to indicate that it wasn't going to be secure.

[MisterJames]

I actually just saw the link from the comment in #13 as well. Because it's just storing key/value pairs, I'm guessing locally it would work fine with the secrets API, but then you could set vars through the Azure portal/API and not have to worry about shipping those values around (or checking anything in, per above). 👍

[glen-84]

👎 For aspnet-*

I think the command is currently not pluralized (user-secret vs user-secrets) – I think it should be.

The current name seems okay to me: user (stored per user) and secrets (since it will be encrypted).

If "user-secrets" is too generic, then dnx-user-secrets could be used.

Question: Is this command only for development environments, or might it be used in cloud/hosting environments instead of environment variables?

[shanselman]

I like aspnet-vault or DotNet-vault IF it's encrypted. If it's not, it's just user-config.

[JRoppert]

Think about non-native english speakers and "KISS" (know what i mean, keep it simple). IMHO should not be a kinda "cool name" like somethink-vault or so. We're talking about the secrets of the user so I like user-secrets. Pretty straightforward.

[muratg]

@DamianEdwards This one needs a decision so assigning to you.

cc @glennc who cares about this too.

[analogrelay]

Nah, @glennc doesn't care. I heard him say "I love the current name and if we change it, I'm leaving"

[Eilon]

Closing this because we rename the package and command to dotnet-user-secrets.