What version of the credhub server you are using?
Doesn't matter

What version of the credhub cli you are using?
2.0.0

If you were attempting to accomplish a task, what was it you were attempting to do?
Doing anything with cli.

What did you expect to happen?
I expected it to work.

What was the actual behavior?

$ docker run -it --rm bash bash
bash-4.4# apk add -u wget
bash-4.4# wget https://github.com/cloudfoundry-incubator/credhub-cli/releases/download/2.0.0/credhub-linux-2.0.0.tgz
bash-4.4# tar xvf credhub-linux-2.0.0.tgz
./
./credhub
bash-4.4# ./credhub
bash: ./credhub: No such file or directory
bash-4.4# ldd ./credhub
    /lib64/ld-linux-x86-64.so.2 (0x7ff878a46000)
    libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7ff878a46000)
    libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7ff878a46000)

This forces me to use heavier images or somehow install glibc on alpine. It would be nice to not depend on glibc.

• I have included a log output
• My log includes an error message
• I have included steps for reproduction

What version of the credhub server you are using?

Server Version: 2.3.0

What version of the credhub cli you are using?

CLI Version: 2.4.0

If you were attempting to accomplish a task, what was it you were attempting to do?
export our creds to a secure backup using credhub export

What did you expect to happen?
To see a json formatted dump of the data (so that I can use jq to test the backup)

What was the actual behavior?
I got YAML... I'm fine with yaml, but in automated systems such as this, jq is an easier thing to depend upon than one of two flavors of yq

Please confirm where necessary:

• I have included a log output
• My log includes an error message
• I have included steps for reproduction

Hi,
I am trying to implement the workflow described in this doc in service broker side. And I found this repo as an sample secure service broker. But it is outdated e.g. the method addPermissions is no longer existed in the CLI.

I feel hard to figure out how to integrate the service broker with credhub -- there are too many credhub concepts to understand for a service broker author, I think. Do you have any quick-start guidance for service broker authors? That would be helpful.

Sometimes it is necessary to determine the local CLI version before connecting to the server.
Feature proposal: credhub --version currently waits for the backend connection before reporting the CLI version. It would be better if the local version would be displayed instantly regardless of the ability to connect to the API backend.

CLi version: v1.5.1

I ran brew upgrade credhub-cli, then credhub --version to check that it installed correctly,

and got:

$ credhub --version
CLI Version: 1.5.1
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x1297fc6]

goroutine 1 [running]:
github.com/cloudfoundry-incubator/credhub-cli/credhub.(*CredHub).Request(0x0, 0x13a4125, 0x3, 0x13a680e, 0xc, 0xc4201107e0, 0x0, 0x0, 0x10, 0x1353a20, ...)
	/tmp/build/8dc578f1/go/src/github.com/cloudfoundry-incubator/credhub-cli/credhub/request.go:20 +0x26
github.com/cloudfoundry-incubator/credhub-cli/credhub.(*CredHub).find(0x0, 0x13a483d, 0x5, 0x13a454b, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0)
	/tmp/build/8dc578f1/go/src/github.com/cloudfoundry-incubator/credhub-cli/credhub/find.go:54 +0x1a4
github.com/cloudfoundry-incubator/credhub-cli/credhub.(*CredHub).FindAllPaths(0x0, 0x13b5c26, 0x3f, 0x0, 0x0, 0x0)
	/tmp/build/8dc578f1/go/src/github.com/cloudfoundry-incubator/credhub-cli/credhub/find.go:26 +0x8a
github.com/cloudfoundry-incubator/credhub-cli/commands.PrintVersion(0x1065acd, 0x132a800)
	/tmp/build/8dc578f1/go/src/github.com/cloudfoundry-incubator/credhub-cli/commands/version.go:22 +0x17f
github.com/cloudfoundry-incubator/credhub-cli/commands.init.2.func1()
	/tmp/build/8dc578f1/go/src/github.com/cloudfoundry-incubator/credhub-cli/commands/version.go:39 +0x22
reflect.Value.call(0x1326140, 0x15508d8, 0x193, 0x13a434b, 0x4, 0x0, 0x0, 0x0, 0x1095eb1, 0x154f8c0, ...)
	/usr/local/go/src/reflect/value.go:434 +0x91f
reflect.Value.Call(0x1326140, 0x15508d8, 0x193, 0x0, 0x0, 0x0, 0xc420071788, 0xc4200efae0, 0x109e5c4)
	/usr/local/go/src/reflect/value.go:302 +0xa4
github.com/cloudfoundry-incubator/credhub-cli/vendor/github.com/jessevdk/go-flags.(*Option).call(0xc420114d00, 0x0, 0x193, 0x15288c0)
	/tmp/build/8dc578f1/go/src/github.com/cloudfoundry-incubator/credhub-cli/vendor/github.com/jessevdk/go-flags/option.go:384 +0x3ff
github.com/cloudfoundry-incubator/credhub-cli/vendor/github.com/jessevdk/go-flags.(*Option).set(0xc420114d00, 0x0, 0x12da719, 0x1345b20)
	/tmp/build/8dc578f1/go/src/github.com/cloudfoundry-incubator/credhub-cli/vendor/github.com/jessevdk/go-flags/option.go:224 +0x27e
github.com/cloudfoundry-incubator/credhub-cli/vendor/github.com/jessevdk/go-flags.(*Parser).parseOption(0xc42001a3c0, 0xc4200e5170, 0x7ffeefbff8ca, 0x7, 0xc420114d00, 0x12ea301, 0x0, 0x7, 0x13a3f23)
	/tmp/build/8dc578f1/go/src/github.com/cloudfoundry-incubator/credhub-cli/vendor/github.com/jessevdk/go-flags/parser.go:509 +0x866
github.com/cloudfoundry-incubator/credhub-cli/vendor/github.com/jessevdk/go-flags.(*Parser).parseLong(0xc42001a3c0, 0xc4200e5170, 0x7ffeefbff8ca, 0x7, 0x0, 0x7ffeefbff8ca, 0x7)
	/tmp/build/8dc578f1/go/src/github.com/cloudfoundry-incubator/credhub-cli/vendor/github.com/jessevdk/go-flags/parser.go:564 +0xbb
github.com/cloudfoundry-incubator/credhub-cli/vendor/github.com/jessevdk/go-flags.(*Parser).ParseArgs(0xc42001a3c0, 0xc42000a350, 0x1, 0x1, 0x100f148, 0x10, 0x1357920, 0x1, 0xc420106f30)
	/tmp/build/8dc578f1/go/src/github.com/cloudfoundry-incubator/credhub-cli/vendor/github.com/jessevdk/go-flags/parser.go:265 +0x366
github.com/cloudfoundry-incubator/credhub-cli/vendor/github.com/jessevdk/go-flags.(*Parser).Parse(0xc42001a3c0, 0xc420106f30, 0x2, 0xc42001a3c0, 0x0, 0xc420013b90)
	/tmp/build/8dc578f1/go/src/github.com/cloudfoundry-incubator/credhub-cli/vendor/github.com/jessevdk/go-flags/parser.go:186 +0x73
main.main()
	/tmp/build/8dc578f1/go/src/github.com/cloudfoundry-incubator/credhub-cli/main.go:25 +0xd0

What version of the credhub server you are using?

2.0.1+

What version of the credhub cli you are using?

2.0.1+ Go client library

If you were attempting to accomplish a task, what was it you were attempting to do?

Concourse allows users to store their credentials at either the pipeline or team level. It first looks for it at /.../team/pipeline/foo, if it is unable to find it it will then look at /.../team/foo.

If a get credential fails we would like to be able to figure out if it's due to credhub not being able to find the credential (which is acceptable) or something else (which should throw error)

What did you expect to happen?

Being able to tell the difference between generic (e.g. network unavailable) and credhub (e.g. credential does not exist) errors

What was the actual behavior?

Both are returned as a errors.New(...)

Are you interested in fixing this yourself?

yep

When providing a password for the password or user types via stdin, it seems like the password should be hidden the way that it is for other password prompts.

Problem

The credhub CLI includes a great way to explore the entire tree of creds via the command line.

Its difficulty comes when trying to get/set multiple fields. The import command was enabled to help alleviate this.

When it comes to exploring the data, export helped immensely. Being able to see all the values are transverse the tree is very useful.

With any of these mechanisms, it can be repetitive to lookup fields, remember all the options to set, etc. Editing large YAML files can be difficult as it is YAML and remembering what’s on line 10 is hard when on line 1001.

Proposal

The data for credhub is structured by types (ie password, username, etc) it fits well into the shape of a form. An HTML form would be useful to edit/add/delete values from credhub.

I’d like to propose credhub-cli web or maybe credhub-cli explorer.

When enabled from the local command line, it would start a local server, that only the current user can use (via the targeting creds on the machine), to explore their remote credhub.

Something similar to vault ui.

Features

• Tree explorer, which just allows you to expand/fold creds through the path of all the keys.
• Add, edit, or remove a specific key.

I’m happy to help work on this. I’d like to start a discussion to see if this a viable feature.

Firstly, thanks for adding SOCKS5 proxy support recently.

I need to set $HTTPS_PROXY for many Golang CLIs that cleverly use it to route traffic thru a SOCKS5 proxy. Can credhub move to use HTTPS_PROXY features from Golang 1.9/1.10? Or if we must keep CREDHUB_PROXY, can the CLI internally ignore HTTPS_PROXY if its set, please?

Currently, if both are set:

$ credhub find
Get https://10.10.1.4:8844/api/v1/data?path=: proxyconnect tcp: proxy: failed to read connect reply from SOCKS5 proxy at localhost:9999: EOF

$ unset HTTPS_PROXY
$ credhub find
credentials:
- name: /bucc/useast2-prod-vault/root_token
...

Noticed this story in flight: https://www.pivotaltracker.com/story/show/135819653

Seems like the command always expects a path to a cert file, while our team's workflow both locally and in CI is based around environment variables, e.g. $CREDHUB_CA_CERT. Could this flag be made to accept either a filepath or the contents of the file? I know Terraform uses a similar approach for many of its certs: https://github.com/hashicorp/terraform/blob/master/helper/pathorcontents/read.go.

Taking it a step further, additionally having the CLI recognize an environment variable directly, similar to $CREDHUB_CLIENT, would be even better.

What version of the credhub server you are using?

2.0.2 and 1.4.1

What version of the credhub cli you are using?

We tested on the newest and oldest patch releases from 2.0 down to 0.6.

If you were attempting to accomplish a task, what was it you were attempting to do?

Summary

We were attempting to use Credhub CLI 2.0 with Credhub Server 2.0.2 from a container in a Linux-hosted Concourse 3.14.1 server.

The same combination of CLI and Server versions works without issue natively on Mac, as well as in a Linux Docker image run on that Mac. The Docker image is the same as the one used in the job on the Concourse server.

Details

The Credhub CLI appears to have a mysterious failure when run in a Linux Docker image run by a Linux-hosted Concourse 3.14.1 server.

Specifically, credhub login succeeds, but the CLI refuses to try to talk with the Credhub server. This means that credhub --version hangs for many seconds before printing the line Server Version: Not Found. Have you targeted and authenticated against a CredHub server?, and operations like credhub find report You are not currently authenticated. Please log in to continue. very quickly.

These operations succeed without issue when run using the same Docker image on a Mac workstation, or running natively on a Mac.

tcpdump indicates that when the credhub --version operation fails, there is no traffic between the machine running the CLI and the Credhub Server. In contrast, when the operation is successful there is traffic.

When running against a 2.0.2 server, the versions up to 1.5.0 succeed. 1.5.3 and later fail.

When running against a 1.4.1 server, the versions up to 1.7.0 succeed. 1.7.7 and later fail.

We don't know where in the 1.5.x and 1.7.x families the issue crept in, as we tested the newest and oldest release in each family.

Testing Methodology

We wrote a script that effectively did the following in the Concourse job:

• Download, unpack, and make executable the Linux pre-built Credhub-CLI for the version being tested
• Run credhub login to log into the target Credhub server.
• Run credhub --version to attempt to read the version info from the Credhub server.

Success was having something other than Not Found. Have you targeted and authenticated against a CredHub server? printed for the Server Version.

What did you expect to happen?

Use normal credhub functionality with credhub-cli 2.0.0 and credhub server 2.0.2.

What was the actual behavior?

Repeated assertions that we had not authenticated.

Please confirm where necessary:

• I have included a log output
• My log includes an error message
• I have included steps for reproduction

If you are a PCF customer with an Operation Manager (PCF Ops Manager) please direct your questions to support (https://support.pivotal.io/)

To make the CLI more usable in automated scripts, a flag that pulls out just the value of a credential would be super helpful. A current workaround would be setting --output-json and using jq, but a simple flag feels nicer.

For example:

Plain get:

$ credhub get --name /vbox/cf/uaa_scim_users_admin_password
type: password
name: /vbox/cf/uaa_scim_users_admin_password
value: MY_PASSWORD
updated: 2017-05-10T21:25:53Z

With flag:

$ credhub get --name /vbox/cf/uaa_scim_users_admin_password --value
MY_PASSWORD

If this seems reasonable but y'all don't have time, I'd be willing to throw a PR your way.

I have been thinking about the need for this for a while, but without SOCKS5 proxy support bbl and credhub would never be on the same machine, so it was sort of useless to provide CREDHUB_SERVER and CREDHUB_CA_CERT inside of bbl print-env

But, now that it seems socks5 proxying is feasible, then it also makes sense that BBL could print all information needed to target credhub so that users aren't actually aware of what their credhub password is. I realize this may have been an intentional choice (everything else is ENV var settable) but interested in revisiting it.

I don't have any opinion on the name of the env vars, but if you let me know what you plan to use I could integrate them immediately into bbl for future support.

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

When I run this command
credhub login -u test -p '' -s https://10.2.1.252:8844
I got request to enter password

It should be treated as a case when I send the wrong password.

What version of the credhub server you are using?
unknown. Using credhub from concourse 5.1

What version of the credhub cli you are using?
2.4.0

If you were attempting to accomplish a task, what was it you were attempting to do?
We were attempting to interpolate an empty file, but got an error. When running another test with invalid yaml in that file, we did not get an error.

What did you expect to happen?
I expected a consistent experience for credhub interpolate when using an empty file or invalid file

What was the actual behavior?
One returned an error, the other did not

Please confirm where necessary:

• I have included a log output
• My log includes an error message
• I have included steps for reproduction

if you had an empty file, credhub interpolate fails. However, if you gave that same file minimal yaml (---) with nothing else in it, it would pass. If you also give it a file with - or invalid: as the only file contents, this also does not return an error.

→ credhub interpolate --file minimal-yaml.yml
null

→ echo $?
0

→ credhub interpolate --file invalid-yaml.yml
null

→ echo $?
0

→ credhub interpolate --file empty-yaml.yml
Error: empty-yaml.yml was an empty file

→ echo $?
1

What version of the credhub server you are using?
2.0.2

What version of the credhub cli you are using?
2.0.1
2.1.0

If you were attempting to accomplish a task, what was it you were attempting to do?
Save a value
credhub s -n /foo -t value -v bar

What did you expect to happen?
Save the value

What was the actual behavior?
CLI 2.0.1 and 2.1.0 send invalid parameter "mode". CLI 2.0.0 writes successfully.

[DEBUG] PUT /api/v1/data HTTP/1.1
Host: 10.0.0.6:8844
User-Agent: Go-http-client/1.1
Content-Length: 63
Content-Type: application/json
Accept-Encoding: gzip

{"mode":"overwrite","name":"/foo","type":"value","value":"bar"}
[DEBUG] HTTP/1.1 422
Transfer-Encoding: chunked
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Content-Type: application/json;charset=UTF-8
Date: Wed, 14 Nov 2018 19:06:00 GMT
Expires: 0
Pragma: no-cache
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block

81
{"error":"The request includes an unrecognized parameter 'mode'. Please update or remove this parameter and retry your request."}
0

What version of the credhub server you are using?
What version of the credhub cli you are using?

credhub --version
CLI Version: 1.7.7
Server Version: 0.0.0

If you were attempting to accomplish a task, what was it you were attempting to do?

I am trying to bulk import credentials using the import command. E.g. credhub import -f notification-creds.yml

My notification-creds.yml file looks something like this

---
credentials:
- name: /bosh-oms/notifications/domain
  type: domain
  value: my.domain.com
- name: /bosh-oms/notifications/encryption_key
  type: string
  value: moons_of_endor

What did you expect to happen?

I expected a non-zero exit code when credential import is unsuccessful.

What was the actual behavior?

I see output telling me it was unsuccessful

Credential '/bosh-oms/notifications/domain' at index 0 could not be set: The request does not include a valid type. Valid values include 'value', 'json', 'password', 'user', 'certificate', 'ssh' and 'rsa'.
Credential '/bosh-oms/notifications/encryption_key' at index 1 could not be set: The request does not include a valid type. Valid values include 'value', 'json', 'password', 'user', 'certificate', 'ssh' and 'rsa'.

but I can echo $? to see the exit code was 0. This makes it difficult for my concourse pipeline to fail at the appropriate time.

What version of the credhub cli you are using?
1.7.7

If you were attempting to accomplish a task, what was it you were attempting to do?
credhub login (eventually) but encountering cert issues which has not happened to us before on this env.

What did you expect to happen?

$ credhub --version
CLI Version: 1.7.7

What was the actual behavior?

$ credhub --version
CLI Version: 1.7.7
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x12f6d19]

goroutine 1 [running]:
code.cloudfoundry.org/credhub-cli/credhub.(*CredHub).Request(0x0, 0x1425be2, 0x3, 0x1427c96, 0xc, 0xc42033eab0, 0x0, 0x0, 0x1, 0x4002011b488, ...)
    /tmp/build/8dc578f1/go/src/code.cloudfoundry.org/credhub-cli/credhub/request.go:20 +0x29
code.cloudfoundry.org/credhub-cli/credhub.(*CredHub).find(0x0, 0x14261f6, 0x5, 0x1425f80, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0)
    /tmp/build/8dc578f1/go/src/code.cloudfoundry.org/credhub-cli/credhub/find.go:54 +0x197
code.cloudfoundry.org/credhub-cli/credhub.(*CredHub).FindAllPaths(0x0, 0x1438a48, 0x3f, 0x0, 0x0, 0x0)
    /tmp/build/8dc578f1/go/src/code.cloudfoundry.org/credhub-cli/credhub/find.go:26 +0x73
code.cloudfoundry.org/credhub-cli/commands.PrintVersion(0x106b91b, 0x1396c00)
    /tmp/build/8dc578f1/go/src/code.cloudfoundry.org/credhub-cli/commands/version.go:23 +0x23c
code.cloudfoundry.org/credhub-cli/commands.init.1.func1()
    /tmp/build/8dc578f1/go/src/code.cloudfoundry.org/credhub-cli/commands/version.go:41 +0x22
reflect.Value.call(0x1391c40, 0x1649860, 0x193, 0x1425dd8, 0x4, 0x0, 0x0, 0x0, 0x1391c40, 0x2e680, ...)
    /usr/local/go/src/reflect/value.go:434 +0x905
reflect.Value.Call(0x1391c40, 0x1649860, 0x193, 0x0, 0x0, 0x0, 0xc40002e680, 0x1384040, 0x1649860)
    /usr/local/go/src/reflect/value.go:302 +0xa4
code.cloudfoundry.org/credhub-cli/vendor/github.com/jessevdk/go-flags.(*Option).call(0xc420155040, 0x0, 0x193, 0x1610a60)
    /tmp/build/8dc578f1/go/src/code.cloudfoundry.org/credhub-cli/vendor/github.com/jessevdk/go-flags/option.go:384 +0x3e5
code.cloudfoundry.org/credhub-cli/vendor/github.com/jessevdk/go-flags.(*Option).set(0xc420155040, 0x0, 0x13b4ca0, 0xc420146f30)
    /tmp/build/8dc578f1/go/src/code.cloudfoundry.org/credhub-cli/vendor/github.com/jessevdk/go-flags/option.go:224 +0x2ba
code.cloudfoundry.org/credhub-cli/vendor/github.com/jessevdk/go-flags.(*Parser).parseOption(0xc4200682a0, 0xc4201230e0, 0x7ffeefbfd94a, 0x7, 0xc420155040, 0x134bf01, 0x0, 0x7, 0x14259e3)
    /tmp/build/8dc578f1/go/src/code.cloudfoundry.org/credhub-cli/vendor/github.com/jessevdk/go-flags/parser.go:509 +0x81e
code.cloudfoundry.org/credhub-cli/vendor/github.com/jessevdk/go-flags.(*Parser).parseLong(0xc4200682a0, 0xc4201230e0, 0x7ffeefbfd94a, 0x7, 0x0, 0x7ffeefbfd94a, 0x7)
    /tmp/build/8dc578f1/go/src/code.cloudfoundry.org/credhub-cli/vendor/github.com/jessevdk/go-flags/parser.go:564 +0xbb
code.cloudfoundry.org/credhub-cli/vendor/github.com/jessevdk/go-flags.(*Parser).ParseArgs(0xc4200682a0, 0xc42000a090, 0x1, 0x1, 0x10109e8, 0x10, 0x13cba40, 0xc42011bf01, 0xc4201502a0)
    /tmp/build/8dc578f1/go/src/code.cloudfoundry.org/credhub-cli/vendor/github.com/jessevdk/go-flags/parser.go:265 +0x33b
code.cloudfoundry.org/credhub-cli/vendor/github.com/jessevdk/go-flags.(*Parser).Parse(0xc4200682a0, 0xc4201502a0, 0x2, 0xc4200682a0, 0x1004354, 0xc42001c0b8)
    /tmp/build/8dc578f1/go/src/code.cloudfoundry.org/credhub-cli/vendor/github.com/jessevdk/go-flags/parser.go:186 +0x71
main.main()
    /tmp/build/8dc578f1/go/src/code.cloudfoundry.org/credhub-cli/main.go:70 +0xc0

Feature Request

Problem

We access the same credhub with multiple users through the credhub cli. But i don't want everyone to see all the variables in the credhub. E.g. we have credentials only relevant for specific Concourse Pipelines, credentials needed by an Administrator for our bosh deployment or simple credentials that help apps to access their dashboard.

As we are redeploying our bosh from time to time to include new features, it is important to us that the different people can access their passwords without conducting a system administrator.
But on the other hand we don't want to expose all credentials to everyone.

Solution

credhub cli could support different user groups. Each group gets e.g. access to a certain set of credentials that match a prefix. For our Concourse users this prefix would be /concourse.

With the different user groups i could create user accounts with only the access permissions i am comfortable to give.

best

It would be nice to have the CREDHUB_DEBUG env more discoverable to credhub cli users, likely in the credhub --help output.

https://github.com/cloudfoundry-incubator/credhub-cli/blob/814bc1b711fe03888f7fc36cb2a9684e2d498bd3/credhub/request.go#L55-L63

What version of the credhub cli you are using?

CLI Version: 2.0.1

If you were attempting to accomplish a task, what was it you were attempting to do?

• display credhub REST api traces
• searched for related support through ./credhub help

What did you expect to happen?

help output to document CREDHUB_DEBUG variable support, (similarly to CF cli output)

$ credhub --help

[...]
Available commands:
[...]
ENVIRONMENT VARIABLES:
   CREDHUB_DEBUG=true                     Print API request diagnostics to stdout

What was the actual behavior?

help does not document CREDHUB_DEBUG variable support:

$ credhub --help

[...]
Available commands:
[...]

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

I have no way of discovering credentials saved under the root path /. For example if I create an entry with no slashes in its name, I have to remember the name to get it back, since find -a and find -p / don't show them. Or I think someone else on my team mucked around with my CredHub and I want to see if they left anything around, and it's hard to figure out.

In general, it appears that find shows "directories", not credentials, contrary to what a lot of the help text for the find command says. Also, it refers to "directories" as "paths", which is confusing -- "paths" should refer to "directories" or entries. In general I'd expect to be able to navigate the CredHub KV store similar to how I'd navigate a file system with the find utility, with recursive listing, options for showing only directories or only "end-values", limiting the depth to show, etc.

Additional information:

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

Copied from original issue: cloudfoundry/credhub#2

Feature Request

Problem

We deployed credhub using a certificate that is not signed by a TA. Every time we want to login, we need to do credhub login -u admin -p password --skip-tls-validation.
Since we got the cert we would rather than like to do so credhub login -u admin -p password --ca-cert=some-cert --insecure

If we try to authenticate against credhub cli with out cert (not TA signed), we receive the message "...your cert is not signed by a TA..."

Solution

Add --insecure flag to credhub login to allow authentication through not TA signed certs.

What version of the credhub server you are using?

CLI only issue

What version of the credhub cli you are using?

1.7.5

If you were attempting to accomplish a task, what was it you were attempting to do?

Import a YAML file with block-indentation indicators, e.g.

credentials:
- name: /concourse/pivotal_cloud_foundry/deploy-harbor/server_certificate
  type: certificate
  value:
    certificate: |6
          -----BEGIN CERTIFICATE-----
          MIIGGTCCBQGgAwIBAgISA0p5evMPElOBFaUPSJtg1B7hMA0GCSqGSIb3DQEBCwUA
          MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
          ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xODA5MjEyMDEwNDFaFw0x
          ODEyMjAyMDEwNDFaMCIxIDAeBgNVBAMTF3JlZ2lzdHJ5LnBjZi5jcmRhbnQubmV0
          MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAov8eaICIUNfk/Fqc1pfh
          wTdshILqGxBciHcPeeeGoBI4GtB3fLD+0jrrtTMe4jroBzlEc7oPg1Xvq/V1m3En
          HDxUkF88lj4iV7Sy0VSz1AYDl/fdrW6iIbtWjVqiBetICOo5PA8pm94y1UCPeL3T
          N2vwm9L/RVn6LPSV+AUAVAw2uzzXiT6wi/D4W58h9SysKH60uyLvw7lqyfLfgJzi
          rhmjkA8T/nubm87jaf27Cx5BpG2+OwMUHFZh7QX07xSAkk5g8RlZ1DiOjB9DA4dU
          oGeHqENvfQWsH3FnTNHpzlJ5kpTKLt6R5RuaxhG6THkD2rPMPu6Osgiico4mbVz6
          vwIDAQABo4IDHzCCAxswDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUF
          BwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBRoWQK17/n0Zj1I
          9Ey+egNEBW/1ozAfBgNVHSMEGDAWgBSoSmpjBH3duubRObemRWXv86jsoTBvBggr
          BgEFBQcBAQRjMGEwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwLmludC14My5sZXRz
          ZW5jcnlwdC5vcmcwLwYIKwYBBQUHMAKGI2h0dHA6Ly9jZXJ0LmludC14My5sZXRz
          ZW5jcnlwdC5vcmcvMCIGA1UdEQQbMBmCF3JlZ2lzdHJ5LnBjZi5jcmRhbnQubmV0
          MIH+BgNVHSAEgfYwgfMwCAYGZ4EMAQIBMIHmBgsrBgEEAYLfEwEBATCB1jAmBggr
          BgEFBQcCARYaaHR0cDovL2Nwcy5sZXRzZW5jcnlwdC5vcmcwgasGCCsGAQUFBwIC
          MIGeDIGbVGhpcyBDZXJ0aWZpY2F0ZSBtYXkgb25seSBiZSByZWxpZWQgdXBvbiBi
          eSBSZWx5aW5nIFBhcnRpZXMgYW5kIG9ubHkgaW4gYWNjb3JkYW5jZSB3aXRoIHRo
          ZSBDZXJ0aWZpY2F0ZSBQb2xpY3kgZm91bmQgYXQgaHR0cHM6Ly9sZXRzZW5jcnlw
          dC5vcmcvcmVwb3NpdG9yeS8wggEEBgorBgEEAdZ5AgQCBIH1BIHyAPAAdQBvU3as
          MfAxGdiZAKRRFf93FRwR2QLBACkGjbIImjfZEwAAAWX9+G2gAAAEAwBGMEQCICZY
          fJBtkd/9bYP3jTf7NeWY1Jwhi0UPPZMXQHLEMBtPAiBrsDkwwC70NBC4qoyG9bXO
          Utm+CfjNeRaxn7rP2/jawgB3AKRQEmkFWhVUXmIRqze8ED9irlV2pF5LFxRFPhsi
          EGolAAABZf34bVgAAAQDAEgwRgIhAIfY6IHHGKjr0Amc5DU2HPGd4OjMrDypSUGN
          35oL9FU3AiEA8sL4PYhtcdqkRRg4KlPCtIpAXOx2dQXS54TQo085cJwwDQYJKoZI
          hvcNAQELBQADggEBAAKI+OvFYFCW+Yjwi/9CtRSaqhp4S5U+Gv67zk02oueuY4k0
          VVoZGXudaWhba2UaSN6CkAPXSeSjlH/1Oi+5h8rKD5Mys44l9YrF9o/7IiqzHrZr
          9Nheu76O4Ma7AsFEVNg+h6QfNV57fCTEKEP62PzcYs9hV94sFW8dSi9acS4IpIBS
          2/Hq/ssjuCnZo4RrgslY9bhknwWLwI5FBcnwM7OPm5mmwZv5LyVgVJfz+6HqpgXk
          5XB7AobyXUrAS3HKXx7vPl2ARRabotDBxwyM6vELtHolZsSFObANun9a1WJEl0Og
          OWuJbVVRWTfhySd1nlxcb+3EpfifczZXAmW9a7w=
          -----END CERTIFICATE-----

What did you expect to happen?

The YAML file to be imported.

What was the actual behavior?

The referenced file does not contain valid yaml structure. Please update and retry your request.

Please confirm where necessary:

• I have included a log output
• My log includes an error message
• [ X] I have included steps for reproduction

If you are a PCF customer with an Operation Manager (PCF Ops Manager) please direct your questions to support (https://support.pivotal.io/)

What version of the credhub cli you are using?

1.7.7 CLI

If you were attempting to accomplish a task, what was it you were attempting to do?

I would like to read specific values from a requested credential using the --key option.

I can get a credential:

> credhub get -n /bosh-oms/cf/cf_admin_password
id: 41bff4f1-332f-498c-827d-735b51cdabff
name: /bosh-oms/cf/cf_admin_password
type: password
value: credentialvalue
version_created_at: "2018-08-09T17:47:37Z"

I would like to limit the output to just the value credentialvalue.

Based on the help from credhub get -h, I think I should be able to run with the -k option to Return only the specified field of the requested credential.

credhub get -n /bosh-oms/cf/cf_admin_password -k value
credhub get -n /bosh-oms/cf/cf_admin_password --key=value

What did you expect to happen?

I expect to see the value credential value credentialvalue and nothing else.

What was the actual behavior?

The CLI exits with no output at all.
The exit code was 0.

Currently these commands output YAML by default. However, conceivably, this CLI was meant to be used by humans who aren't usually interested in version_created_at or the database ID. They mainly want to know the value of their password or the name of their password, not the metadata associated with it.

Currently the find command returns this YAML:

jumpbox/0:~$ ./credhub find -p /bosh-ci-evanfarrar/concourse
credentials:
- name: /bosh-ci-evanfarrar/concourse/atc
  version_created_at: 2017-11-09T21:11:09Z
- name: /bosh-ci-evanfarrar/concourse/atc_ca
  version_created_at: 2017-11-09T18:48:03Z
- name: /bosh-ci-evanfarrar/concourse/database_password
  version_created_at: 2017-11-09T18:48:02Z
- name: /bosh-ci-evanfarrar/concourse/database_username
  version_created_at: 2017-11-09T18:48:02Z
- name: /bosh-ci-evanfarrar/concourse/database_name
  version_created_at: 2017-11-09T18:48:02Z
- name: /bosh-ci-evanfarrar/concourse/basic_auth_password
  version_created_at: 2017-11-09T18:48:02Z
- name: /bosh-ci-evanfarrar/concourse/basic_auth_username
  version_created_at: 2017-11-09T18:48:02Z

And the get command returns this YAML:

jumpbox/0:~$ ./credhub get --name `./credhub find -n "basic_auth_username" | grep -e"- name" | cut -d':' -f2`
id: e6f1d764-37a1-4261-86fd-64fb4ce6e02d
name: /bosh-ci-evanfarrar/concourse/basic_auth_username
type: password
value: APASSWORD
version_created_at: 2017-11-09T18:48:02Z

I propose that we make the output human-readable and human-relevant by default, but provide the YAML format as an option. It is arguably a smaller burden for a computer to remember and type an extra flag than it is for a human to do so.

new proposed find output:

jumpbox/0:~$ ./credhub find -p /bosh-ci-evanfarrar/concourse
/bosh-ci-evanfarrar/concourse/atc
/bosh-ci-evanfarrar/concourse/atc_ca
/bosh-ci-evanfarrar/concourse/database_password
/bosh-ci-evanfarrar/concourse/database_username
/bosh-ci-evanfarrar/concourse/database_name
/bosh-ci-evanfarrar/concourse/basic_auth_password
/bosh-ci-evanfarrar/concourse/basic_auth_username

new proposed get output:

jumpbox/0:~$ ./credhub get --name `./credhub find -n "basic_auth_username"`
APASSWORD

A possible migration path:

• 1.X: introduce --human to output just the value or just the keys delimited by newlines, introduce --yaml flag which does nothing as it is already the default.
• 2.X: --human now does nothing but print a deprecation warning, as it is the default. --yaml does what the default used to do.
• 3.x: remove --human

Related: this is an alternative suggestion for #3

What version of the credhub server you are using?
1.3.4

What version of the credhub cli you are using?
1.5.0

If you were attempting to accomplish a task, what was it you were attempting to do?
Regenerate a statically set credential

What did you expect to happen?
Expected to receive an error with the command returning non-zero exit code.

What was the actual behavior?
Command printed blank line and returned with exit code 0.

With CredHub server v1.3.4, calling the regenerate API on a statically set credential returns this error:
The user could not be regenerated because the value was statically set. Only generated users may be regenerated.

Using the credhub regenerate command from CredHub CLI v1.5.0 on the same credential returns no error. Executing credhub find on the credential afterward shows that the credential has not been updated.

Steps to reproduce:

$ date
Fri Feb 23 13:12:45 EST 2018
$ credhub regenerate -n "/p-bosh/cf-aa8ac10268039ab9c5f7/autoscale-db-credentials"

$ echo $?
0
$ credhub find -n "/p-bosh/cf-aa8ac10268039ab9c5f7/autoscale-db-credentials"
credentials:
- name: /p-bosh/cf-aa8ac10268039ab9c5f7/autoscale-db-credentials
  version_created_at: 2018-01-07T23:41:38Z

Please confirm where necessary:

• I have included a log output
• My log includes an error message
• I have included steps for reproduction

If you are a PCF customer with an Operation Manager (PCF Ops Manager) please direct your questions to support (https://support.pivotal.io/)

What version of the credhub server you are using?
The server version is showing as 0.0.0 in the CLI
but the actual version when I do a bosh deployment with BBL is 1.9.3

What version of the credhub cli you are using?
CLI Version: 2.0.0

If you were attempting to accomplish a task, what was it you were attempting to do?
I was trying to add in a multiline value to a key. The credhub get doesn't seem to display the output correctly.

credhub set -n /concourse/main/gcp_service_account_text -t value --value $(cat gcp_key.txt)

The file gcp_key.txt is formatted something like this:

{
 id:...
 private_key: ....
}

If I now try

credhub get -n /concourse/main/gcp_service_account_text

I get:

name: /concourse/main/gcp_service_account_text
type: value
value: '{'
version_created_at: "2018-08-10T22:10:14Z"

What did you expect to happen?
It should display the value properly. Otherwise users may think it is incorrect.
e.g.

name: /concourse/main/gcp_service_account_text
type: value
value: '{
 id:...
 private_key: ....
}'
version_created_at: "2018-08-10T22:10:14Z"

What was the actual behavior?

name: /concourse/main/gcp_service_account_text
type: value
value: '{'
version_created_at: "2018-08-10T22:10:14Z"

Please confirm where necessary:

• I have included a log output
• My log includes an error message
• [ X] I have included steps for reproduction

What version of the credhub server you are using?
1.6.5

What version of the credhub cli you are using?
1.6.0

If you were attempting to accomplish a task, what was it you were attempting to do?

I'm hoping that when I switch my credhub environment variables from one credhub server to another server my credhub config will be configured without having to run credhub api.

Steps to reproduce:

$ export CREDHUB_CLIENT=...
$ export CREDHUB_SECRET=...
$ export CREDHUB_SERVER=server1
$ export CREDHUB_CA_CERT=cert1
$ credhub get -n /some/ref
> id: 1b34c341... (success)
...
$ export CREDHUB_CLIENT=...
$ export CREDHUB_SECRET=...
$ export CREDHUB_SERVER=server2
$ export CREDHUB_CA_CERT=cert2
credhub get -n /some/ref
> Post https://server1:8443/oauth/token: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

Potentially useful line number?:
https://github.com/cloudfoundry-incubator/credhub-cli/blob/be697aff6ba98c2f37dad63887ba1349dbd0d40c/commands/helpers.go#L57

Please confirm where necessary:

• I have included a log output
• My log includes an error message
• I have included steps for reproduction

It looks like CLI version 1.5.1 should support socks5 proxying, but I'm having issues. It appears to be treating socks5 as a hostname, not a scheme:

curl -sS -L -o credhub.tar.gz https://github.com/cloudfoundry-incubator/credhub-cli/releases/download/1.5.1/credhub-linux-1.5.1.tgz
tar xfz credhub.tar.gz 
chmod +x credhub

https_proxy=socks5://127.0.0.1:55000 ./credhub api --server https://192.168.200.20
Error connecting to the targeted API: "Get https://192.168.200.20/info: proxyconnect tcp: dial tcp: lookup socks5 on 10.94.224.10:53: no such host". Please validate your target and retry your request.

I"m also getting a SEGV when doing credhub --version:

CLI Version: 1.5.1
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x68f0c6]

goroutine 1 [running]:
github.com/cloudfoundry-incubator/credhub-cli/credhub.(*CredHub).Request(0x0, 0x79954e, 0x3, 0x79bc5c, 0xc, 0xc42010e900, 0x0, 0x0, 0x10, 0x74ac00, ...)
	/tmp/build/8dc578f1/go/src/github.com/cloudfoundry-incubator/credhub-cli/credhub/request.go:20 +0x26
<snip>

Thanks!

What version of the credhub server you are using?

it is reporting 0.0.0 from the CLI

What version of the credhub cli you are using?

2.1.0

If you were attempting to accomplish a task, what was it you were attempting to do?

Creating a concourse task that sets the CREDHUB-* environment variables to allow people to run credhub interpolate. We've specified them under params in out tasks, as empty/null values, which allows pipelines to override them.

What did you expect to happen?

CREDHUB_CA_CERT would be ignored if it was an empty string.

What was the actual behavior?

$ export CREDHUB_SERVER="https://example.com" CREDHUB_SECRET="secret" CREDHUB_CLIENT="concourse" CREDHUB_CA_CERT=""
$ credhub interpolate --prefix /pipeline/vsphere --file 'files/*.yml'
provided ca certs are invalid

Please confirm where necessary:

• I have included a log output
• My log includes an error message
• I have included steps for reproduction

What version of the credhub server you are using?

Don't know; I assume the error message is coming from the CLI; if it's from the server, I need to explore this more deeply.

What version of the credhub cli you are using?

1.6.0

If you were attempting to accomplish a task, what was it you were attempting to do?

./credhub generate   --name=$PREFIX_PROD/rabbitmq-odb-ch-prod   --type=password   --username=$USER   --no-overwrite

What did you expect to happen?

I expected to get an error similar to request includes an unrecognized parameter 'username'

What was the actual behavior?

The request includes an unrecognized parameter 'value'

Please confirm where necessary:

• I have included a log output
• My log includes an error message
• I have included steps for reproduction

If you are a PCF customer with an Operation Manager (PCF Ops Manager) please direct your questions to support (https://support.pivotal.io/)

When I try the credhub cli, it's failing with below message.
How can I debug this issue?
[ubuntu@ip-10-100-3-191 TEST bosh-test]$ credhub api --server=https://10.100.0.6:8443 --skip-tls-validation
invalid character '<' looking for beginning of value

As a platform operator, I would like to context switch between multiple credhub environments.

I often find myself needing to switch between credhub servers. Instead of having to log in and out of them, I would like a mechanism similar to how the bosh-cli has bosh -e <env> to allow switching between environments. Or how Concourse's fly cli has different targets to choose from

e.g.,

credhub -t ci get -n /concourse/blah/...
credhub -t sandbox-bosh-oss get -n /blah/.../
credhub -t dev-opsman get -n /blah/.../

Thanks for your time and consideration

What version of the credhub server you are using?

BOSH release 1.9.1

What version of the credhub cli you are using?

1.7.5

If you were attempting to accomplish a task, what was it you were attempting to do?

We're trying to login to Credhub on the CLI with our username and password.

What did you expect to happen?

We expected to be able to login successfully.

What was the actual behavior?

$ credhub login
username: credhub-cli
password: ********************
The provided credentials are incorrect. Please validate your input and retry your request.

Despite this, the exact same credentials allow us to login to https://<concourse-web-node-IP>:8443/login

Here's the relevant chunk of the properties for the UAA job in our Concourse BOSH manifest:

        scim:
          users:
          - name: admin
            password: ((uaa-users-admin))
            groups:
            - scim.write
            - scim.read
            - bosh.admin
            - credhub.read
            - credhub.write
          - name: credhub-cli
            password: ((credhub_cli_password))
            groups:
            - credhub.read
            - credhub.write
        clients:
          credhub_cli:
            override: true
            authorized-grant-types: password,refresh_token,client_credentials
            scope: credhub.read,credhub.write
            authorities: uaa.resource,credhub.read,credhub.write
            access-token-validity: 30
            refresh-token-validity: 3600
            secret: ((credhub_cli_password))
          atc_to_credhub:
            override: true
            authorized-grant-types: client_credentials
            scope: ""
            authorities: credhub.read,credhub.write
            access-token-validity: 3600
            secret: ((uaa_clients_atc_to_credhub))

Please confirm where necessary:

• [ X ] I have included a log output
• [ X ] My log includes an error message
• [ X ] I have included steps for reproduction

Thanks!

What version of the credhub server you are using?

Server Version: 1.7.2

What version of the credhub cli you are using?

CLI Version: 1.7.0    

If you were attempting to accomplish a task, what was it you were attempting to do?

Use the find subcommand with an extra argument:

credhub find /some/key

Notice I did not provide a -n flag.

What did you expect to happen?

Return an error

What was the actual behavior?

It ignored the extra argument and returned everything.

Please confirm where necessary:

• I have included a log output
• My log includes an error message
• I have included steps for reproduction

If you are a PCF customer with an Operation Manager (PCF Ops Manager) please direct your questions to support (https://support.pivotal.io/)

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

Add .cf-extensions file to your repo so that it shows correctly in the CF-Extensions hub and catalog.

{
  "lead_company": "ADD LEAD COMPANY HERE",
  "contact_email": "[email protected]",
  "description": "ADD DESCRIPTION HERE",
  "tracker_url": "https://www.pivotaltracker.com",
  "proposal_url": "https://docs.google.com/document/d/1cpyBmds7WYNLKO1qkjhCdS8bNSJjWH5MqTE-h1UCQkQ/edit?usp=sharing",
  "proposed_date": "2017-08-29 10:31:53.049383201 -0700 PDT"
}

or

lead_company: ADD LEAD COMPANY HERE
contact_email: [email protected]
description: ADD DESCRIPTION HERE
tracker_url: https://www.pivotaltracker.com
proposal_url: https://docs.google.com/document/d/1cpyBmds7WYNLKO1qkjhCdS8bNSJjWH5MqTE-h1UCQkQ/edit?usp=sharing
proposed_date: 2017-08-29 10:31:53.049383201 -0700 PDT

This is a JSON or YAML formatted file. The default values in the file are for you to get started. You should edit to match your project's data.

For example, the field tracker_url should contain your project's tracker URL, and so on.

FINAL NOTES

You may also add two more optional fields: logo_url and icon_url pointing to images for your logo and icon respectively.

For best results your images should be in JPG or PNG file formats and their sizes around 200x300 pixels for logo and 32x32 pixels for icon.

Given that most installation instructions/manifests/tools for deployment BOSH with credhub will not allow access from the internet to the credhub API, it would be helpful to allow for a proxy to be supplied to credhub-cli. This is the default, so it seems odd if all users have to solve this connection problem in their own way.

The BOSH CLI accepts $BOSH_ALL_PROXY to support this. I suggest we take a different tack with credhub, an experience which we also would like to to PR into BOSH if they will allow it. We would make all commands respect the host, key, and ssh username and start a SOCKS5 proxy as a goroutine before any connections to the credhub API occur. The experience could be:

export CREDHUB_GW_HOST=`bbl jumpbox-address`
export CREDHUB_GW_PRIVATE_KEY=`bbl ssh-key`
export CREDHUB_GW_USER=jumpbox

credhub api 10.0.0.6:8844
credhub login -u admin -p `bbl credhub-password`

My team has already created the SOCKS5 proxy management code in Go twice (in bosh-deployment-resource and in BBL), we would be happy to PR this in to credhub-cli if you would accept it.

Description

credhub --version panics for me on on Ubuntu LTS 16.04.

Installation steps

wget https://github.com/cloudfoundry-incubator/credhub-cli/releases/download/1.5.2/credhub-linux-1.5.2.tgz
tar xfv credhub-linux-1.5.2.tgz
sudo mv credhub /usr/local/bin/credhub
sudo chmod +x  /usr/local/bin/credhub

Linux Kernel Version

$ uname -r
4.4.0-101-generic

Ubuntu Version info

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.3 LTS
Release:        16.04
Codename:       xenial

Error

$ credhub --version
CLI Version: 1.5.2
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x691d26]

goroutine 1 [running]:
github.com/cloudfoundry-incubator/credhub-cli/credhub.(*CredHub).Request(0x0, 0x7a0024, 0x3, 0x7a1fd4, 0xc, 0xc4201264b0, 0x0, 0x0, 0x40000000000, 0xc4200f14c0, ...)
        /tmp/build/8dc578f1/go/src/github.com/cloudfoundry-incubator/credhub-cli/credhub/request.go:20 +0x26
github.com/cloudfoundry-incubator/credhub-cli/credhub.(*CredHub).find(0x0, 0x7a05e1, 0x5, 0x7a037e, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0)
        /tmp/build/8dc578f1/go/src/github.com/cloudfoundry-incubator/credhub-cli/credhub/find.go:54 +0x187
github.com/cloudfoundry-incubator/credhub-cli/credhub.(*CredHub).FindAllPaths(0x0, 0x7b1144, 0x3f, 0x0, 0x0, 0x0)
        /tmp/build/8dc578f1/go/src/github.com/cloudfoundry-incubator/credhub-cli/credhub/find.go:26 +0x73
github.com/cloudfoundry-incubator/credhub-cli/commands.PrintVersion(0x46e65b, 0x725560)
        /tmp/build/8dc578f1/go/src/github.com/cloudfoundry-incubator/credhub-cli/commands/version.go:22 +0x144
github.com/cloudfoundry-incubator/credhub-cli/commands.init.1.func1()
        /tmp/build/8dc578f1/go/src/github.com/cloudfoundry-incubator/credhub-cli/commands/version.go:39 +0x22
reflect.Value.call(0x720c20, 0x980238, 0x193, 0x7a0206, 0x4, 0x0, 0x0, 0x0, 0x720c20, 0x26de0, ...)
        /usr/local/go/src/reflect/value.go:434 +0x905
reflect.Value.Call(0x720c20, 0x980238, 0x193, 0x0, 0x0, 0x0, 0xc400026de0, 0x712de0, 0x980238)
        /usr/local/go/src/reflect/value.go:302 +0xa4
github.com/cloudfoundry-incubator/credhub-cli/vendor/github.com/jessevdk/go-flags.(*Option).call(0xc4201236c0, 0x0, 0x193, 0x94f980)
        /tmp/build/8dc578f1/go/src/github.com/cloudfoundry-incubator/credhub-cli/vendor/github.com/jessevdk/go-flags/option.go:384 +0x3e5
github.com/cloudfoundry-incubator/credhub-cli/vendor/github.com/jessevdk/go-flags.(*Option).set(0xc4201236c0, 0x0, 0x7408c0, 0xc420126360)
        /tmp/build/8dc578f1/go/src/github.com/cloudfoundry-incubator/credhub-cli/vendor/github.com/jessevdk/go-flags/option.go:224 +0x2ba
github.com/cloudfoundry-incubator/credhub-cli/vendor/github.com/jessevdk/go-flags.(*Parser).parseOption(0xc4200522a0, 0xc4200fad80, 0x7ffd9b550931, 0x7, 0xc4201236c0, 0x6e2301, 0x0, 0x7, 0x79fe43)
        /tmp/build/8dc578f1/go/src/github.com/cloudfoundry-incubator/credhub-cli/vendor/github.com/jessevdk/go-flags/parser.go:509 +0x81e
github.com/cloudfoundry-incubator/credhub-cli/vendor/github.com/jessevdk/go-flags.(*Parser).parseLong(0xc4200522a0, 0xc4200fad80, 0x7ffd9b550931, 0x7, 0x0, 0x7ffd9b550931, 0x7)
        /tmp/build/8dc578f1/go/src/github.com/cloudfoundry-incubator/credhub-cli/vendor/github.com/jessevdk/go-flags/parser.go:564 +0xbb
github.com/cloudfoundry-incubator/credhub-cli/vendor/github.com/jessevdk/go-flags.(*Parser).ParseArgs(0xc4200522a0, 0xc42000c070, 0x1, 0x1, 0x4123b8, 0x10, 0x752c00, 0xc4200f1f01, 0xc42003dde0)
        /tmp/build/8dc578f1/go/src/github.com/cloudfoundry-incubator/credhub-cli/vendor/github.com/jessevdk/go-flags/parser.go:265 +0x33b
github.com/cloudfoundry-incubator/credhub-cli/vendor/github.com/jessevdk/go-flags.(*Parser).Parse(0xc4200522a0, 0xc42003dde0, 0x2, 0xc4200522a0, 0x405ea4, 0xc42005c058)
        /tmp/build/8dc578f1/go/src/github.com/cloudfoundry-incubator/credhub-cli/vendor/github.com/jessevdk/go-flags/parser.go:186 +0x71
main.main()
        /tmp/build/8dc578f1/go/src/github.com/cloudfoundry-incubator/credhub-cli/main.go:25 +0xc0

What version of the credhub server you are using?
Server Version: 2.0.2

What version of the credhub cli you are using?
CLI Version: 2.2.0

If you were attempting to accomplish a task, what was it you were attempting to do?
Attempting to change the transitional flag from one version of a certificate to another.

What did you expect to happen?
The transitional flag to switch from the new certificate version to the older one AND for the cli to return a message along the lines of "Success!".

What was the actual behavior?
The transitional flag DID switch from the new to the old certificate, BUT the credhub-cli only displayed an error message.

└─▪  credhub curl -d '{"version": "1024f501-f39a-43fb-8499-6ac9d704cb2b"}' -p /api/v1/certificates/d9a544ea-f1b3-49e3-8312-0872c2e277f6/update_transitional_version -X PUT
json: cannot unmarshal array into Go value of type map[string]interface {}

Because everything was successful server side, I'm assuming this is a client side only error in parsing the response. When I had the -i flag I can see that the response is HTTP 200.

└─▪ credhub curl -d '{"version": "1024f501-f39a-43fb-8499-6ac9d704cb2b"}' -p /api/v1/certificates/d9a544ea-f1b3-49e3-8312-0872c2e277f6/update_transitional_version -X PUT -i
HTTP/1.1 200
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Content-Type: application/json;charset=UTF-8
Date: Tue, 08 Jan 2019 21:31:47 GMT
Expires: 0
Pragma: no-cache
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block

json: cannot unmarshal array into Go value of type map[string]interface {}

To reproduce follow this document: https://github.com/pivotal-cf/credhub-release/blob/master/docs/ca-rotation.md
and instead of using curl use the credhub-cli for each command. You should get the error in the second step of step 2.

Please confirm where necessary:

• I have included steps for reproduction
• My log includes an error message
• I have included a log output

What version of the credhub server you are using?
1.7

What version of the credhub cli you are using?
2.0.0

If you were attempting to accomplish a task, what was it you were attempting to do?
credhub set

What did you expect to happen?
value saved

What was the actual behavior?
credhub cli said it saved my value but it did not.

# credhub set -n /concourse/gcpops_dev/testone -t value -v "test value 3"
id: 3a433603-b55a-42ad-840b-4b5e915e4bd0
name: /concourse/gcpops_dev/testone
type: value
value: <redacted>
version_created_at: "2018-08-08T21:12:58Z" 

Looks successful ^^ but it was not.

# credhub get -n /concourse/gcpops_dev/testone
id: 3a433603-b55a-42ad-840b-4b5e915e4bd0
name: /concourse/gcpops_dev/testone
type: value
value: testone 1
version_created_at: "2018-08-08T21:12:58Z" 

At the very least.. the credhub set should fail.

Bonus if the cli detects incompatible client/server combination, or just be backwards compatible.

Please confirm where necessary:

• I have included a log output
• My log includes an error message
• [* ] I have included steps for reproduction

If you are a PCF customer with an Operation Manager (PCF Ops Manager) please direct your questions to support (https://support.pivotal.io/)

• What version of the credhub server you are using?
  2.0.2

• What version of the credhub cli you are using?
  2.0.0

• If you were attempting to accomplish a task, what was it you were attempting to do?
  Log in interactivley to credhub.

$ credhub login 
username: credhub-admin
password: ********************

• What did you expect to happen?

$ credhub login 
username: credhub-admin
password: ********************
Login Successful

• What was the actual behavior?

$ credhub login 
username: credhub-admin
password: ********************
UAA error: unauthorized Bad credentials

• Do you have a workaround ?
  Yes, pass the credentials in as flags.

$ credhub login --client-name=credhub-admin --client-secret=****************
Login Successful

• Do you have any notes you want to add ?
  I think was able to track this down to two places ( 1 2 ) in the codebase but I am not fluent enough in go to work this out.

Please confirm where necessary:

• I have included a log output
• My log includes an error message
• I have included steps for reproduction

getting the version with credhub --version to get the current credhub cli version is slow.
because it wants to connect to credhub first.

What version of the credhub server you are using?
2.1.0

What version of the credhub cli you are using?
2.2.0

If you were attempting to accomplish a task, what was it you were attempting to do?
use the interpolate feature

What did you expect to happen?
it show me any missing key for the whole yml

What was the actual behavior?
It stops at the first key not found

Please confirm where necessary:

• I have included a log output
• My log includes an error message
• I have included steps for reproduction

The interpolate feature is rough to use when you are modifying pipelines for concourse integration. According to the current lookup rules it will look at /concourse/TEAM_NAME/PIPELINE_NAME/foo_param and then /concourse/TEAM_NAME/foo_param to find your variable. Fair enough, that lets you have a clean yml with ((foo_param) as a variable format.

My team is utilizing this to be able to use common variables that the TEAM_NAME can share. However this seems in contrast with the current design of credhub interpolate. While you can tell credhub to add a prefix there is only an option for one, so you have choose between a prefix up to the PIPELINE_NAME or a prefix up to and including PIPELINE_NAME

Either way it will give you error that it can't find one variable set or another depending on your choice of prefix. This wouldn't be so bad if it would give output based on the whole file however that does not seem to be the case; it stops at the first error. Interestingly, in my case, the first two variables defined in my yml are one from each of those sets so I can't go further.

Options:

1. I can interpolate fine if I edit my yml to be ((PIPELINE_NAME/foo_param) for variables specific to the pipeline and then prefix credhub interpolate with /concourse/TEAM_NAME but concourse doesn't like that, it won't find the variables starting with PIPELINE_NAME
2. Put all of my variables in PIPELINE_NAME scope. This lets me do ((foo_param) for everything and also interpolate. But that means I have to duplicate and maintain a heck of a lot of variables.
3. Edit yml to have all variables use the FQN so both concourse and credhub interpolate are happy. So you would have ((/concourse/TEAM_NAME/PIPELINE_NAME/foo_param)) and ((/concourse/TEAM_NAME/bar_param)) everywhere. This looks ugly/sloppy, but that aside our group is using TEAM_NAME to segregate values between environments. so foo_param needs to be different between different TEAM_NAMEs. I don't think there is a way to make TEAM_NAME dynamic (like fetch a credhub variable for it) so we don't want to hardcode it into the pipeline that needs to be used in different environments.

Request:

So that being said, can we get multiple prefixes? Or can interpolate do a whole pass and output all not found keys instead of stopping at the first one? At least then I could spam the various prefixes and check the results. This might be problematic for larger files, though.

I know there was a lot of concourse stuff in here when this is credhub-cli. But you folks control direction on both. I am a little new to these tools so perhaps there is something I can't think of. But really it would be great to have better harmony between credhub interpolate and concourse lookup rules

Thanks.

-Red

What version of the credhub server you are using?
1.6.5

What version of the credhub cli you are using?
master branch

If you were attempting to accomplish a task, what was it you were attempting to do?
attempting to rotate the password that is imported to the credhub

What did you expect to happen?
expect to be able to rotate imported generated password

What was the actual behavior?
The password could not be regenerated because the value was statically set. Only generated passwords may be regenerated.

Process executed:

$ credhub generate -n testing -t password
$ credhub regenerate -n testing
$ credhub export > temp.yml
$ credhub delete  -n testing # simulating the behavior to migrate to another empty credhub instance
$ credhub import -f temp.yml
$ credhub regenerate -n testing 
The password could not be regenerated because the value was statically set. Only generated passwords may be regenerated.

Notes:
The same procees repeated with -t cert, we can regenerate successfully. At least this is an inconsistant experience

Proposed exported format if behavior for password regeneration stays the same:

credentials:
- name: /testing
  type: password
  value: kL2tf0qh26R2jfH9X3hKHw48fUnwBA
  generated: true

Please confirm where necessary:

• I have included a log output
• My log includes an error message
• I have included steps for reproduction

If you are a PCF customer with an Operation Manager (PCF Ops Manager) please direct your questions to support (https://support.pivotal.io/)

Our CredHub has a certificate signed by a root CA. Targeting it fails with x509: certificate signed by unknown authority. I should not have to specify --ca-cert in this case, and don't really have a CA cert on hand since it's a root CA. (I could probably derive it or download it from the CA or something, but still.)

What version of the credhub server you are using?

λ credhub --version
CLI Version: 2.0.0
Server Version: 2.0.2

If you were attempting to accomplish a task, what was it you were attempting to do?

I was attempting to store a variable which determines how many instances of a BOSH deployment to deploy. With this credential storage:

λ credhub set -t value -n /bosh/rabbitmq/haproxy-instances -v 2

It should be storable as an int. When I deployed the BOSH release with ((haproxy-instances)) as the /instance_groups/name=haproxy/instances value, it failed because it's a string and not an integer.

What did you expect to happen?

The BOSH deployment to succeed because I passed a raw integer when creating the variable in credhub.

What was the actual behavior?

Task 28112

Task 28112 | 23:41:14 | Preparing deployment: Preparing deployment (00:00:01)
                     L Error: Property 'instances' value ("2") did not match the required type 'Integer'
Task 28112 | 23:41:15 | Error: Property 'instances' value ("2") did not match the required type 'Integer'

Task 28112 Started  Sun Nov 11 23:41:14 UTC 2018
Task 28112 Finished Sun Nov 11 23:41:15 UTC 2018
Task 28112 Duration 00:00:01
Task 28112 error

Updating deployment:
  Expected task '28112' to succeed but state is 'error'

Exit code 1

Please confirm where necessary:

• I have included a log output
• My log includes an error message
• I have included steps for reproduction

What version of the credhub server you are using?

N/A: This an issue only with the CLI.

What version of the credhub cli you are using?

v1.7.0

If you were attempting to accomplish a task, what was it you were attempting to do?

We were trying to verify that we can talk to credhub by running either of these commands:

credhub login

which returns:

Error connecting to the targeted API: "Get https://10.0.0.6:8844/info: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)". Please validate your target and retry your request.

OR

credhub find

which returns:

Post https://10.0.0.6:8443/oauth/token: x509: certificate signed by unknown authority

What did you expect to happen?

Because credhub was behind a firewall, I expected to see client timeout error when running credhub find instead of saying that the certificate is signed by unknown authority, which could be confusing.

What was the actual behavior?

Post https://10.0.0.6:8443/oauth/token: x509: certificate signed by unknown authority

Steps to reproduce

Disallow traffic to credhub. For example, on AWS, remove the security group rule that allows client to reach credhub server on port 8844.
Then run credhub find and credhub login and see that the error output is as described above.

Please confirm where necessary:

• I have included a log output
• My log includes an error message
• I have included steps for reproduction

What version of the credhub server you are using?

master

What version of the credhub cli you are using?

2.0.0

If you were attempting to accomplish a task, what was it you were attempting to do?

After a discussing with @athornton2012 and @TisVictress, we'd like to propose an additional format for credhub export.

The current export has a structure with made for easy importing into another Credhub.

We'd like to have a format that make it easier to consume the variables for YAML interpolation. This interpolation would not happen via a bosh director / concourse atc. This is for another CLI.

For example, the current output of a credhub export:

type: user
name: /example-user
value:
  username: FQnwWoxgSrDuqDLmeLpU
  password: 6mRPZB3bAfb8lRpacnXsHfDhlPqFcjH2h9YDvLpL
  password_hash: $6$h3b3JsG5$MnrPIrF6T3zAWk9uaun64vWY.vaBQ5nTRFZjjVqKuDWccxWXn8n6vstQykXEReamb4GYh2q1HC7vFy11wflXd0

The output format that we'd like to add, perhaps as credhub export --format simple.

example-user_username: FQnwWoxgSrDuqDLmeLpU
example-user_password: 6mRPZB3bAfb8lRpacnXsHfDhlPqFcjH2h9YDvLpL

NOTE: The pattern is useful because it prevents object collision when using YAML interpolation.

The above format allows YAML interpolation in a config file like:

some-config: value
username: ((/example-user_username))
password: ((/example-user_password))

We'd like to add this capability to credhub CLI because we don't want our CLI to have a direct dependency on a credhub server.

What did you expect to happen?

N/A

What was the actual behavior?

N/A