Requesting certificates for plain file user keys no longer works

[notCalle]

When requesting a certificate for a plain file key, fingerprint parsing got broken by 7952e33e16f996ec923296518b218f4513c6ab3d.

2019/02/01 10:03:41 Server running version 1.7.0-0-g7952e33
2019/02/01 10:03:41 Using SSH agent at /tmp/ssh-NB2G9PMmzz5F/agent.1
2019/02/01 10:03:41 Added private key for env test: ad:0a:8a:8b:be:a0:ec:be:dd:ba:b5:a2:f4:a1:7f:1d
2019/02/01 10:03:41 Server started with config map[string]ssh_ca_util.SignerdConfig{"test":ssh_ca_util.SignerdConfig{SigningKeyFingerprint:"ad:0a:8a:8b:be:a0:ec:be:dd:ba:b5:a2:f4:a1:7f:1d", AuthorizedSigners:map[string]string(nil), AuthorizedUsers:map[string]string{"01:f5:24:35:51:52:13:b9:8e:a9:3b:0f:00:20:fa:10":"calle@test"}, NumberSignersRequired:-1, SlackUrl:"", SlackChannel:"", MaxCertLifetime:600, PrivateKeyFile:"/etc/ssh/ca/test_ca_ed25519", KmsRegion:"", CriticalOptions:map[string]string(nil)}}

$ ssh-cert-authority --version
ssh-cert-authority version 1.7.0-0-g7952e33
$ ssh-cert-authority request --environment test --reason test
Ignoring invalid private key url: '01:f5:24:35:51:52:13:b9:8e:a9:3b:0f:00:20:fa:10'. Error parsing: parse 01:f5:24:35:51:52:13:b9:8e:a9:3b:0f:00:20:fa:10: first path segment in URL cannot contain colon

It seems that the breakage is in the client side of things, because when I request a certificate from an up-to-date server, using an older client build it still works.

[bobveznat]

That's embarrassing. My test suite has only been using paths to private keys for a while now and I'll need to stop doing that.

The temporary work around of course is to keep using the old version on the client side. 1.7 wouldn't have introduced anything useful on the client so there's no real downside to doing that.

I'll try to get this patched up this weekend. Thanks for reporting the issue.

[bobveznat]

This should be fixed in 1.7.1. Thanks for the report and sorry for the inconvenience.