nats auth - incompatibilities with nsc created operators/accounts

[roeschter]

Observed behavior

We see nil pointer check failures in a few places involving key management. Specifically scoped signing keys.
I would seem nats auth cannot handle that the list of scoped signing keys is empty (if the account was created by nsc).

Tested on local compile of main branch

Case 1) (reproducible)
Create an operator with

1. nsc add operator --name TEST --sys
2. Run nats auth accounts keys ls (selecting the SYS account)

`panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x68 pc=0x7ff6d8f6f634]

goroutine 1 [running]:
github.com/nats-io/natscli/cli.(*authAccountCommand).skListAction(0xc000515980?, 0x7ff6d85b77df?)
D:/private/nats.io_synadia/natscli/cli/auth_account_command.go:685 +0x254
github.com/choria-io/fisk.(*actionMixin).applyActions(...)
C:/Users/micha/go/pkg/mod/github.com/choria-io/fisk@v0.9.1-0.20260703081120-1be688c199d2/actions.go:28
github.com/choria-io/fisk.(*Application).applyActions(0xc0006cc000?, 0xc0004442d0)
C:/Users/micha/go/pkg/mod/github.com/choria-io/fisk@v0.9.1-0.20260703081120-1be688c199d2/app.go:842 +0xd0
github.com/choria-io/fisk.(*Application).execute(0xc0006cc000, 0xc0004442d0, {0xc0002700c0, 0x4, 0x4})
C:/Users/micha/go/pkg/mod/github.com/choria-io/fisk@v0.9.1-0.20260703081120-1be688c199d2/app.go:643 +0x65
github.com/choria-io/fisk.(*Application).Parse(0xc0006cc000, {0xc00004a090?, 0x38?, 0x7ff6d85bb9f3?})
C:/Users/micha/go/pkg/mod/github.com/choria-io/fisk@v0.9.1-0.20260703081120-1be688c199d2/app.go:300 +0x17f
github.com/choria-io/fisk.(*Application).MustParseWithUsage(0xc0006cc000, {0xc00004a090, 0x4, 0x7})
C:/Users/micha/go/pkg/mod/github.com/choria-io/fisk@v0.9.1-0.20260703081120-1be688c199d2/app.go:908 +0x45
main.main()
D:/private/nats.io_synadia/natscli/nats/main.go:105 +0x3cde `

Case 2) (cannot reproduce from scratch, likely same or similar issue)

When running user create with a signing key passed in
nats auth user add <name> <account> --operator <op> --key <accountSigningKey>

panic: runtime error: invalid memory address or nil pointer dereference
github.com/nats-io/natscli/internal/auth.SelectSigningKey(...)  internal/auth/auth.go:281
github.com/nats-io/natscli/cli.(*authUserCommand).addAction(...) cli/auth_user_command.go:36

Expected behavior

nats auth should work (create users) and certainly not crash when using an nsc created store/key setup.

Server and client version

nats CLI from main branch (July 14th 2026)
0.4.0 has a bug that was fixed two weeks ago, which casue panic even earlier when using an nsc created operator

Host environment

No response

Steps to reproduce

No response

[roeschter]

The problem is that nats auth assumes that ALL signing keys are in the scoped signing key format. At least having a role defined. This is distinctly NOT the case traditionally with nsc generated signing keys. Also not the case with SCP generated ones. So nats auth would fail when importing "old" style account.

I do not know what the intention here is. Possibly adding a "fake" scope and role in
jwt_auth_builder/account.go.ScopedSigningKeys()

Otherwise the whole logic in all places using ScopedSigningKeys() needs to revisited.

[ripienaar]

He great if you could share the nsc commands that I can use to reproduce it

[roeschter]

One reproducer is trivial as shown above. Repeating for clarity:

1. nsc add operator --name TEST --sys
2. (Pointing to the same store and keys) - nats auth account keys ls SYS --> nil pointer deref (its looking for a scope)

Trying the second case (user creation)

[ripienaar]

Thanks @roeschter missed it there, appreciate it!

[roeschter]

And here is the second case - diffrent code location
nats auth user add ADMIN2 SYS --defaults --key <any valid or invalid key>

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x40 pc=0x7ff6384d326f]

goroutine 1 [running]:
github.com/nats-io/natscli/internal/auth.SelectSigningKey({0x7ff638d58420, 0xc0003eef00}, {0xc000032900, 0x38})
        D:/private/nats.io_synadia/natscli/internal/auth/auth.go:281 +0x20f
github.com/nats-io/natscli/cli.(*authUserCommand).addAction(0xc0003a2a00, 0x7ff637c877df?)
        D:/private/nats.io_synadia/natscli/cli/auth_user_command.go:363 +0x7b
github.com/choria-io/fisk.(*actionMixin).applyActions(...)
        C:/Users/micha/go/pkg/mod/github.com/choria-io/fisk@v0.9.1-0.20260703081120-1be688c199d2/actions.go:28
github.com/choria-io/fisk.(*Application).applyActions(0xc0001902c0?, 0xc0003862d0)
        C:/Users/micha/go/pkg/mod/github.com/choria-io/fisk@v0.9.1-0.20260703081120-1be688c199d2/app.go:842 +0xd0
github.com/choria-io/fisk.(*Application).execute(0xc0001902c0, 0xc0003862d0, {0xc0001f6d00, 0x3, 0x4})
        C:/Users/micha/go/pkg/mod/github.com/choria-io/fisk@v0.9.1-0.20260703081120-1be688c199d2/app.go:643 +0x65
github.com/choria-io/fisk.(*Application).Parse(0xc0001902c0, {0xc0000c0010?, 0x38?, 0x7ff637c8b9f3?})
        C:/Users/micha/go/pkg/mod/github.com/choria-io/fisk@v0.9.1-0.20260703081120-1be688c199d2/app.go:300 +0x17f
github.com/choria-io/fisk.(*Application).MustParseWithUsage(0xc0001902c0, {0xc0000c0010, 0x8, 0xf})
        C:/Users/micha/go/pkg/mod/github.com/choria-io/fisk@v0.9.1-0.20260703081120-1be688c199d2/app.go:908 +0x45
main.main()
        D:/private/nats.io_synadia/natscli/nats/main.go:105 +0x3cde

[ripienaar]

Yeah I think the inherent problem here is jwt-auth-builder.go doesn't handle the difference well - give me unscoped keys as scoped keys - and in fact in general jwt auth builder doesn't support just signing keys well I think only scoped ones.

Or something like that, I need to chat with @aricart

For now #1700 fixes the panic (first one) but its not the right fix since I think there's a more fundamental issue here

Will get back to you

[ripienaar]

I reworked #1700 to handle scoped and unstopped keys transparently in the existing keys commands so it should just work, will merge after review and do a release soon