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.