CredHub CLI "find -n ''" should find all credentials, not none

[danjahner]

From @Amit-PivotalLabs on December 8, 2016 3:12

./credhub find -n 'ab' only finds creds where "ab" is a substring of the cred name. So ./credhub find -n '' should find creds that have the empty string as a substring of the name, which should be every single string. Instead, this command returns nothing.

Assuming every credential has an alphabetical character in it, I can find all creds like this:

$ for x in {a..z}; do ./credhub find -n $x 2>/dev/null; done | grep 2016  | cut -f1 -d' ' | sort | uniq
DELETE_ME_AMIT
shell/pivotal/ssh_key

but that's not a desirable way to do it.

Additional info:

$ ./credhub --version
CLI Version: 0.3.0
CM Version: 0.3.0 build DEV

Copied from original issue: cloudfoundry/credhub#3

[danjahner]

Hey Amit -

Is there a use case you have in mind for listing every credential that exists in the system? My instinct is to not add this until there is a need and we feel that this is a good way to accomplish it.

My guess is that a user would be looking for something vaguely specific - a partial name, deployment name or path - not just listing all of the things that exist. I will certainly validate this as feedback rolls in.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/150199502

The labels on this github issue will be updated when the story is started.

[danjahner]

From @Amit-PivotalLabs on December 23, 2016 20:1

My use case was hygiene. I discovered that some random test credential had been left around during development/testing, and I wanted to make sure there weren't any other credentials lying around. I can imagine people may want to be able to audit what's living around in their CredHub for various reasons.

It's also just inconsistent behaviour. ./credhub find -n <X> should match all credentials containing the substring <X>. It's awkward UX that the empty string behaves differently, it was definitely surprising/unexpected behaviour. It's contrary to how grep and other CLI tools people are familiar with work.

[danjahner]

At some point, we changed this behaviour and it now works as you expect in this issue.