Page MenuHomePhabricator

Make the Conduit auth error for an unrecognized public key a little more useful
ClosedPublic

Authored by epriestley on Jul 17 2018, 11:06 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Apr 25, 1:37 AM
Unknown Object (File)
Tue, Apr 23, 9:57 PM
Unknown Object (File)
Fri, Apr 19, 7:49 PM
Unknown Object (File)
Thu, Apr 11, 9:21 AM
Unknown Object (File)
Fri, Apr 5, 6:23 AM
Unknown Object (File)
Sat, Mar 30, 6:28 AM
Unknown Object (File)
Fri, Mar 29, 11:51 AM
Unknown Object (File)
Thu, Mar 28, 7:04 PM
Subscribers

Details

Summary

Ref T13168. This is just a small quality-of-life fix: we can disclose which public key we're talking about because public keys are public.

Test Plan
  • Hit public key error (through my own bumbling / not reading or following instructions). Specifically, I haven't associated the key with a device in Almanac.
  • Before: vague error.
  • After: more specific error with enough key material that I could grep for it.

Diff Detail

Repository
rP Phabricator
Branch
key1
Lint
Lint Passed
Unit
Tests Passed
Build Status
Buildable 20472
Build 27807: Run Core Tests
Build 27806: arc lint + arc unit

Event Timeline

Isn't the end of the public key way more useful for human readability in general? Most of my keys generated via ssh-keygen (which I assume is the practically universal method?) end in an identifier that I can plausibly use to identify the key, like this one:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDzzrWAoWk0QFKtGz3860178qb5ue1cMSqrwYnBOJah7SXEUfwCOjXtvfvE3hyShS3SBdhm6qJZfSMngq7jO84Je1T7HU9FFjLg9HUPsfXaPtsojg4HhhN2n1dm+SysdmXScqIDb0g5/JWHenHTRh146t7ptP6+JzSHQGCWBzXsgXFCdlRrcrM+cUIGz9A0AIr9rZBgcwRtp8qK+TG9geA+Vcxf2Lw2T/GUS4nAeuT8KslAY6oC7ge2zT33VUhkvHyWV4iNlTdDHFneMvtdyXiCFa0oZwaQ7PDNw6Hrde7TDOkTi9Pppxawi8UYotsL7CzkeNIRWDNGXGTLyVsxHYBX mriley@mriley-C02TW3N0HTDD

(C02TW3N0HTDD is the very useful totally human interpretable name of my laptop)

Isn't the end of the public key way more useful for human readability in general?

I was going to say the same thing:

~ $ grep -r AAAAB3NzaC1 .ssh/ | wc -l
      18

64 leading characters is definitely unique enough though. Accepting as-is, but I agree with @yelirekim that the last 64 chars would be more useful.

This revision is now accepted and ready to land.Jul 19 2018, 3:58 AM

I think structuring it as The public key ending in "...<xyz>". is at least a little weird, and potentially confusing even if it's technically better in most cases.

The comment may also be arbitrarily long and non-unique. (When we generate keys, I think we currently just use the comment "Generated", which in a German localization would of course be "Gensherkeymatthaffenuntermazerhosenauomattermachinen", making the last 64 characters nonunique and nonidentifying.)

Perhaps best would be "aaa ... bbb" but we don't have a convenient UTF8-aware truncation process for that today.

(Practically, we don't have a "...xxx" truncator either, and we can't just strrev() the input and output because we don't have a UTF8-aware string reverser.)

I suppose reversing phutil_utf8v_combined() is a reasonably good approximation of a UTF8 reverser. It's probably not perfect (e.g., RTL marks should be inverted, I guess?) but if we were to implement phutil_utf8_strrev(), reversing phutil_utf8v_combined() would probably be a reasonable v0.

This revision was automatically updated to reflect the committed changes.