Existing credential secrets can't be found on MacOS after upgrading to 0.0.12+ #96

liamdawson · 2022-09-13T00:45:01Z

After upgrading to cf-vault 0.0.12+, I've been unable to run cf-vault exec using credentials saved to my keychain. To test the theory that this was connected to versions, I've run a suite of commands against versions 0.0.11, 0.0.12 and 0.0.13, all amd64 (my processor is arm64, but there's no amd64 build of 0.0.11 in the releases):

$ for bin in ./cf-vault-0.0.1*; do file "$bin"; "$bin" version; echo; codesign --verify "$bin"; echo; done
./cf-vault-0.0.11: Mach-O 64-bit executable x86_64
cf-vault 0.0.11+4c50b90 (go1.15.6,gc-amd64)
./cf-vault-0.0.11: code object is not signed at all
In architecture: x86_64

./cf-vault-0.0.12: Mach-O 64-bit executable x86_64
cf-vault 0.0.12 (go1.19,gc-amd64)
./cf-vault-0.0.12: code object is not signed at all
In architecture: x86_64

./cf-vault-0.0.13: Mach-O 64-bit executable x86_64
cf-vault 0.0.13 (go1.19,gc-amd64)
./cf-vault-0.0.13: code object is not signed at all
In architecture: x86_64

$ for bin in ./cf-vault-0.0.1*; do echo "$bin"; "$bin" list; "$bin" -v exec read-only -- printf "\nsuccess\n"; echo; done
./cf-vault-0.0.11
PROFILE NAME        	AUTHENTICATION TYPE	EMAIL
...
read-only           	api_token
DEBU[0000] using profile: read-only
DEBU[0000] found executable /usr/bin/printf
DEBU[0000] executing command: printf \nsuccess\n

success

./cf-vault-0.0.12
PROFILE NAME        	AUTHENTICATION TYPE	EMAIL
...
read-only           	api_token
DEBU[0000] using profile: read-only
FATA[0000] failed to get item from keyring: the specified item could not be found in the keyring

./cf-vault-0.0.13
PROFILE NAME        	AUTHENTICATION TYPE	EMAIL
global-api-key      	api_key            	liam.dawson@envato.com
read-only           	api_token
read-only-no-expiry 	api_token
read-write          	api_token
read-write-no-expiry	api_token
DEBU[0000] using profile: read-only
FATA[0000] failed to get item from keyring: the specified item could not be found in the keyring

Strangely enough, I can't reproduce this issue by building the latest commit (036eb96) locally:

$ go run . version
cf-vault 0.0.0-dev (go1.19.1,gc-arm64)

$ go run . exec read-only -- echo 'success'
success

OS: macOS 12.5.1
Arch: arm64

The text was updated successfully, but these errors were encountered:

liamdawson · 2022-09-13T00:50:19Z

Other observation: version 0.0.11 prompted me for keychain password, 0.0.12/0.0.13 did not prompt before failing. I also notice some slight differences in linked shared library references after 0.0.11 (notably, compatibility version 0.0.0):

$ for bin in ./cf-vault-0.0.1*; do otool -L "$bin"; echo; done
./cf-vault-0.0.11:
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1677.104.0)
	/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 59306.140.5)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)

./cf-vault-0.0.12:
	/usr/lib/libSystem.B.dylib (compatibility version 0.0.0, current version 0.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 0.0.0, current version 0.0.0)
	/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 0.0.0, current version 0.0.0)

./cf-vault-0.0.13:
	/usr/lib/libSystem.B.dylib (compatibility version 0.0.0, current version 0.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 0.0.0, current version 0.0.0)
	/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 0.0.0, current version 0.0.0)

Linked libraries for my locally built version (which would be arm64, though?)

$ go build .
$ otool -L cf-vault
cf-vault:
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1858.112.0)
	/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 60158.100.133)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)

jacobbednarz · 2022-09-13T01:40:09Z

thanks for raising this. the 0.0.11+ releases were triggered by GoReleaser (config: https://github.com/jacobbednarz/cf-vault/blob/master/.goreleaser.yml) instead of me building on a local machine with using script/build

the only obvious thing i can see is the GCFLAGS missing from GoReleaser - https://github.com/jacobbednarz/cf-vault/blob/master/script/build#L35. i'll drop those into the configs and see if it helps out here.

liamdawson · 2022-09-13T01:45:05Z

My other question is whether the keyring libraries handle linking properly if they're cross-compiled from Linux. Were you building the Darwin binaries on a Macos machine before? (GoReleaser would be building them on Ubuntu now?)

jacobbednarz · 2022-09-13T01:53:30Z

fwiw, this is working on amd64 mac on 0.0.13 for me.

$ otool -L ~/Downloads/cf-vault_0.0.13_darwin_amd64/cf-vault
/Users/jacob/Downloads/cf-vault_0.0.13_darwin_amd64/cf-vault:
        /usr/lib/libSystem.B.dylib (compatibility version 0.0.0, current version 0.0.0)
        /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 0.0.0, current version 0.0.0)
        /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 0.0.0, current version 0.0.0)

$ ~/Downloads/cf-vault_0.0.13_darwin_amd64/cf-vault list
PROFILE NAME    AUTHENTICATION TYPE     EMAIL
personal        api_key                 jacob.bednarz@gmail.com

$ ~/Downloads/cf-vault_0.0.13_darwin_amd64/cf-vault exec personal -- env | grep -i cloudflare
Enter passphrase to unlock /Users/jacob/.cf-vault/keys/: 
CLOUDFLARE_VAULT_SESSION=personal
CLOUDFLARE_EMAIL=jacob.bednarz@gmail.com
CLOUDFLARE_API_KEY=[redacted]

have i just botched the arm64 side of things? i will have to fire up some VMs to test the other platforms.

My other question is whether the keyring libraries handle linking properly if they're cross-compiled from Linux.

that is a good question! i don't know the answer unfortunately.

Were you building the Darwin binaries on a Macos machine before?

yep, a (local enough) amd64 machine with a bit more grunt than my daily driver.

GoReleaser would be building them on Ubuntu now?

correct - https://github.com/jacobbednarz/cf-vault/actions/runs/3034201381/jobs/4883046221#step:5:11

liamdawson · 2022-09-13T07:18:30Z

For reference, I get the same errors as noted previously if I use the arm64 builds as well. I might try to do some debugging later and snoop on the behaviour of my locally built (working) binary vs. the one in releases, which doesn't work for me.

liamdawson · 2022-09-14T03:34:38Z

I haven't found anything helpful while using XCode tooling to debug, but I confirmed I can replicate the issue by building locally using GoReleaser inside Docker:

$ docker run --rm -it -v "$(pwd):/src" golang:bullseye /bin/bash
golang$ wget https://github.com/goreleaser/goreleaser/releases/download/v1.11.2/goreleaser_1.11.2_arm64.deb && dpkg -i goreleaser_1.11.2_arm64.deb && cd /src && git checkout 0.0.13 && goreleaser build

# ...

  • starting build...
  • loading config file                              file=.goreleaser.yml
  • loading environment variables
  • getting and validating git state
    • building...                                    commit=4720e71456e9ba1a8ce7db813d87152f2713ede3 latest tag=0.0.13
  • parsing tag
  • setting defaults
  • checking distribution directory
  • loading go mod information
  • build prerequisites
  • writing effective config file
    • writing                                        config=dist/config.yaml
  • building binaries
    • building                                       binary=dist/cf-vault_freebsd_386/cf-vault
    • building                                       binary=dist/cf-vault_darwin_amd64_v1/cf-vault
    • building                                       binary=dist/cf-vault_freebsd_arm64/cf-vault
    • building                                       binary=dist/cf-vault_freebsd_amd64_v1/cf-vault
    • building                                       binary=dist/cf-vault_darwin_arm64/cf-vault
    • building                                       binary=dist/cf-vault_linux_amd64_v1/cf-vault
    • building                                       binary=dist/cf-vault_linux_arm64/cf-vault
    • building                                       binary=dist/cf-vault_linux_386/cf-vault
    • building                                       binary=dist/cf-vault_windows_amd64_v1/cf-vault.exe
    • building                                       binary=dist/cf-vault_windows_arm64/cf-vault.exe
    • building                                       binary=dist/cf-vault_windows_386/cf-vault.exe
    • took: 55s
  • storing release metadata
    • writing                                        file=dist/artifacts.json
    • writing                                        file=dist/metadata.json
  • build succeeded after 55s

Running that built binary outside of the Docker container results in the same issue again:

$ ./dist/cf-vault_darwin_arm64/cf-vault exec read-only -- true
FATA[0000] failed to get item from keyring: the specified item could not be found in the keyring

jacobbednarz · 2022-09-14T07:37:27Z

thanks. let me have a dig around the goreleaser issues and see if anyone else has come across this with ARM builds.

jacobbednarz · 2022-09-14T07:39:45Z

do the versions pre 0.0.11 work for you if you build with goreleaser? just to rule out #63 somehow not working on ARM too.

liamdawson · 2022-09-15T01:18:17Z

I can't build 0.0.11 (for Darwin) using GoReleaser:

$ goreleaser build
  • starting build...
  • loading config file                              file=.goreleaser.yml
  • loading environment variables
  • getting and validating git state
    • building...                                    commit=4c50b90adff17b23f03b27d7986f46dbd8f0023f latest tag=0.0.11
  • parsing tag
  • setting defaults
  • checking distribution directory
  • loading go mod information
  • build prerequisites
  • writing effective config file
    • writing                                        config=dist/config.yaml
  • building binaries
    • building                                       binary=dist/cf-vault_freebsd_386/cf-vault
    • building                                       binary=dist/cf-vault_darwin_amd64_v1/cf-vault
    • building                                       binary=dist/cf-vault_freebsd_arm64/cf-vault
    • building                                       binary=dist/cf-vault_darwin_arm64/cf-vault
    • building                                       binary=dist/cf-vault_freebsd_amd64_v1/cf-vault
    • building                                       binary=dist/cf-vault_linux_amd64_v1/cf-vault
    • building                                       binary=dist/cf-vault_linux_arm64/cf-vault
    • building                                       binary=dist/cf-vault_linux_386/cf-vault
    • building                                       binary=dist/cf-vault_windows_amd64_v1/cf-vault.exe
    • building                                       binary=dist/cf-vault_windows_arm64/cf-vault.exe
    • building                                       binary=dist/cf-vault_windows_386/cf-vault.exe
    • took: 45s
  ⨯ build failed after 44s                           error=failed to build for darwin_arm64: exit status 2: # golang.org/x/sys/unix
/go/pkg/mod/golang.org/x/sys@v0.0.0-20201119102817-f84b799fce68/unix/syscall_darwin.1_13.go:29:3: //go:linkname must refer to declared function or variable
/go/pkg/mod/golang.org/x/sys@v0.0.0-20201119102817-f84b799fce68/unix/zsyscall_darwin_arm64.1_13.go:27:3: //go:linkname must refer to declared function or variable
/go/pkg/mod/golang.org/x/sys@v0.0.0-20201119102817-f84b799fce68/unix/zsyscall_darwin_arm64.1_13.go:40:3: //go:linkname must refer to declared function or variable
/go/pkg/mod/golang.org/x/sys@v0.0.0-20201119102817-f84b799fce68/unix/zsyscall_darwin_arm64.go:28:3: //go:linkname must refer to declared function or variable
/go/pkg/mod/golang.org/x/sys@v0.0.0-20201119102817-f84b799fce68/unix/zsyscall_darwin_arm64.go:43:3: //go:linkname must refer to declared function or variable
/go/pkg/mod/golang.org/x/sys@v0.0.0-20201119102817-f84b799fce68/unix/zsyscall_darwin_arm64.go:59:3: //go:linkname must refer to declared function or variable
/go/pkg/mod/golang.org/x/sys@v0.0.0-20201119102817-f84b799fce68/unix/zsyscall_darwin_arm64.go:75:3: //go:linkname must refer to declared function or variable
/go/pkg/mod/golang.org/x/sys@v0.0.0-20201119102817-f84b799fce68/unix/zsyscall_darwin_arm64.go:90:3: //go:linkname must refer to declared function or variable
/go/pkg/mod/golang.org/x/sys@v0.0.0-20201119102817-f84b799fce68/unix/zsyscall_darwin_arm64.go:105:3: //go:linkname must refer to declared function or variable
/go/pkg/mod/golang.org/x/sys@v0.0.0-20201119102817-f84b799fce68/unix/zsyscall_darwin_arm64.go:121:3: //go:linkname must refer to declared function or variable
/go/pkg/mod/golang.org/x/sys@v0.0.0-20201119102817-f84b799fce68/unix/zsyscall_darwin_arm64.go:121:3: too many errors

jacobbednarz · 2022-09-15T01:25:57Z

hmm, probably just goreleaser issue then 😢

simpson-ross · 2022-10-03T02:02:19Z

Today I upgraded to cf-vault 0.0.13 (go1.19,gc-amd64), and am running into the same problem Liam raised, where existing tokens from 0.0.11 can no longer be found. list worked (listed out the expected profiles, presumably because that comes from the toml config), but exec failed with:

FATA[0000] failed to get item from keyring: the specified item could not be found in the keyring

I went through the setup process again and it's working fine, but with one difference -- where it was using the OSX keychain previously, now it's using JWTs in ~/.cf-vault/keys/. I'm not sure where specifically this comes from, whether it's a recent change in a dependency, or caused by the change to the builder/release mechanism, or something to do with #63, or what.

jacobbednarz · 2022-10-03T23:10:55Z

thanks, i don't think the release/build process would have updated the storage or prompt here however, #63 (or another dependency upgrade) may have.

if you revert #63 locally, do you still have the issue using older credentials?

simpsora · 2023-06-27T03:33:58Z

I did a little local dev on the codebase today, and found that it does seem to be related to the release/build process:

Previous working version (installed from Homebrew)
cf-vault 0.0.13 (go1.19,gc-amd64)
file-based key storage in ~/.cf-vault/keys/
local (built locally with go build)
cf-vault 0.0.0-dev (go1.20.5,gc-arm64)
OSX keychain in ~/Libarary/Keychains/cf-vault.keychain-db
Today's github release, ARM
cf-vault 0.0.14 (go1.20.5,gc-arm64)
file-based key storage in ~/.cf-vault/keys/
Today's github release, AMD
cf-vault 0.0.14 (go1.20.5,gc-amd64)
file-based key storage in ~/.cf-vault/keys/

So: it seems the issue maybe in how the keychain provider is being chosen, and that is somehow different between local builds and those built for release?

Both ways work for me, but it would be good to have it consistent so that folks could continue to use their existing keys when they upgrade.

simpsora · 2023-06-27T03:56:42Z

Looking historically:

0.0.13-arm64 and 0.0.13-amd64: file-based keychain
0.0.12-arm64 and 0.0.12-amd64: SIGSEGV on add
0.0.11-amd64: OSX keychain prompt
67d9132 (commit just before Fix password prompt file keyring issue #63 was merged): file-based keychain

At the moment though, even doing local dev right now I'm getting the file-based keychain, where earlier today I was getting the OSX keychain (I know this is accurate because that specific keychain has today's date on it, and I haven't otherwise touched it since this issue was opened).

Happy to help troubleshoot further, just need to figure out what's happening here.

jacobbednarz · 2023-06-27T04:43:24Z

At the moment though, even doing local dev right now I'm getting the file-based keychain, where earlier today I was getting the OSX keychain (I know this is accurate because that specific keychain has today's date on it, and I haven't otherwise touched it since this issue was opened).

i'm not getting the same behaviour here on mac 13.4.1 (22F82) amd64, when building locally.

(master) $ go run . add example
Email address: a@a.com
Authentication value (API key or API token): 
(*keyring.keychain)(0xc00023e030)({
 path: (string) (len=17) "cf-vault.keychain",
 service: (string) (len=8) "cf-vault",
 passwordFunc: (keyring.PromptFunc) <nil>,
 isSynchronizable: (bool) false,
 isAccessibleWhenUnlocked: (bool) false,
 isTrusted: (bool) true
})

((67d91321…)) $ go run . add example
Email address: a@a.com
Authentication value (API key or API token): 
(*keyring.keychain)(0xc00021a870)({
 path: (string) (len=17) "cf-vault.keychain",
 service: (string) (len=8) "cf-vault",
 passwordFunc: (keyring.PromptFunc) <nil>,
 isSynchronizable: (bool) false,
 isAccessibleWhenUnlocked: (bool) false,
 isTrusted: (bool) true
})

couple of potentially related issues upstream which suggest to me that i'll need to fiddle with the goreleaser cross compiling to get this to work properly.

jacobbednarz · 2023-06-27T05:50:32Z

cross compiling Go on GitHub Actions may be in the too hard basket for now.

@liamdawson @simpsora can you confirm that the assets from https://github.com/jacobbednarz/cf-vault/releases/tag/0.0.15-rc3 work for you? if so, i'll just have to go back to manually building and distributing this package.

simpson-ross · 2023-06-27T09:30:48Z

@jacobbednarz I can confirm the opposite -- that version (cf-vault 0.0.15-rc3+46191e7 (go1.20.1,gc-arm64)) works, but it's using the file-based keyring:

$ ./cf-vault -v exec admin-read-only
DEBU[0000] using profile: admin-read-only
Enter passphrase to unlock /<snip>/.cf-vault/keys/:

$ sw_vers
ProductName:		macOS
ProductVersion:		13.4.1
BuildVersion:		22F82

I'll experiment a bit more with the keychain and local dev tomorrow. Perhaps there's some other factor that's influencing the available keyring backends 🤔

jacobbednarz · 2023-06-27T10:01:18Z

hmm, that's interesting. those assets are using the same process I was using locally previously so there is something not quite right here.

the easy solution would be to use the file system across all but at this point, I can't say why that is the easy fix.

simpson-ross · 2023-06-30T02:04:56Z

There's more discussion on this topic in #147.

jacobbednarz · 2023-11-06T04:54:36Z

to address this, i'm going to stop building artifacts locally and instead lean on the formula via homebrew (instead of a cask) so that every version/update is built locally on the right arch. it's a bit more annoying but it will fix the cross arch issues we're seeing in the artifacts.

jacobbednarz closed this as completed Nov 6, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Existing credential secrets can't be found on MacOS after upgrading to 0.0.12+ #96

Existing credential secrets can't be found on MacOS after upgrading to 0.0.12+ #96

liamdawson commented Sep 13, 2022

liamdawson commented Sep 13, 2022 •

edited

jacobbednarz commented Sep 13, 2022

liamdawson commented Sep 13, 2022

jacobbednarz commented Sep 13, 2022

liamdawson commented Sep 13, 2022

liamdawson commented Sep 14, 2022 •

edited

jacobbednarz commented Sep 14, 2022

jacobbednarz commented Sep 14, 2022

liamdawson commented Sep 15, 2022

jacobbednarz commented Sep 15, 2022

simpson-ross commented Oct 3, 2022

jacobbednarz commented Oct 3, 2022

simpsora commented Jun 27, 2023

simpsora commented Jun 27, 2023

jacobbednarz commented Jun 27, 2023

jacobbednarz commented Jun 27, 2023

simpson-ross commented Jun 27, 2023

jacobbednarz commented Jun 27, 2023

simpson-ross commented Jun 30, 2023

jacobbednarz commented Nov 6, 2023

Existing credential secrets can't be found on MacOS after upgrading to 0.0.12+ #96

Existing credential secrets can't be found on MacOS after upgrading to 0.0.12+ #96

Comments

liamdawson commented Sep 13, 2022

liamdawson commented Sep 13, 2022 • edited

jacobbednarz commented Sep 13, 2022

liamdawson commented Sep 13, 2022

jacobbednarz commented Sep 13, 2022

liamdawson commented Sep 13, 2022

liamdawson commented Sep 14, 2022 • edited

jacobbednarz commented Sep 14, 2022

jacobbednarz commented Sep 14, 2022

liamdawson commented Sep 15, 2022

jacobbednarz commented Sep 15, 2022

simpson-ross commented Oct 3, 2022

jacobbednarz commented Oct 3, 2022

simpsora commented Jun 27, 2023

simpsora commented Jun 27, 2023

jacobbednarz commented Jun 27, 2023

jacobbednarz commented Jun 27, 2023

simpson-ross commented Jun 27, 2023

jacobbednarz commented Jun 27, 2023

simpson-ross commented Jun 30, 2023

jacobbednarz commented Nov 6, 2023

liamdawson commented Sep 13, 2022 •

edited

liamdawson commented Sep 14, 2022 •

edited