Re: [tor-bugs] #17639 [Core Tor/Tor]: provide an option to display the expiry date of a given ed25519 signing key

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#17639: provide an option to display the expiry date of a given ed25519 signing key
------------------------------------------------+--------------------------
 Reporter:  cypherpunks                         |          Owner:  isis
     Type:  enhancement                         |         Status:
                                                |  needs_revision
 Priority:  High                                |      Milestone:  Tor:
                                                |  0.3.2.x-final
Component:  Core Tor/Tor                        |        Version:  Tor:
                                                |  0.2.7.2-alpha
 Severity:  Normal                              |     Resolution:
 Keywords:  tor-ed25519-proto, review-group-21  |  Actual Points:
Parent ID:                                      |         Points:  1
 Reviewer:  nickm                               |        Sponsor:
------------------------------------------------+--------------------------

Comment (by isis):

 Replying to [comment:23 nickm]:
 > This looks comparatively solid to me!  A few things to consider as
 possibilities, though maybe they're not needed:
 >
 >  - Maybe this should printf() something to stdout, instead of using the
 log facility, and run at --quiet by default?

 Yes, this makes sense. TBH, I didn't know if I was allowed/encouraged to
 do printf(), since it seems like there's a lot of ways "interfaces" over
 stdin/stdout can be bad/broken/wrong, particularly when they are relied
 upon by other scripts/programs (cf. gnupg). I think it does make sense
 though to work even with --quiet, and in this case the user is asking a
 question like "hey parse this thing and tell me what it says", not
 intending any operation or for the binary to run as a daemon or anything
 more complicated, so it makes sense here.

 >  - Maybe the output format should be machine-readable?

 Yeah! But what should this look like?

 Literally just spit out the expiry in ISO8601 format? (With or without the
 underscore in between the date and the time?) Or some more easily machine
 parseable (but less human readable) format, like seconds-since-epoch?

 Should it be in the local timezone, or in UTC? (Probably UTC, right? if we
 expect scripts to be able to process it?)

 >  - Maybe it should dump information about the installed authority auth
 key as well
 >  - I wonder what it should do about hidden service keys?

 Yes, I can add these. I thought about the first one before, but I didn't
 know how to make the interface, plus had worries about the patch being
 large/invasive. I think the "proper" way to do it would be to add a
 suboptions parser so that the user could be like "--key-expiration auth"
 or "--key-expiration sign"; this way, it would more easily extendable to
 further changes in supported cert types moving forward.

 I'm not sure what to do about onion service keys/certs at all. I imagine
 there are users with multiple hidden services. Frankly, I didn't even know
 OS keys/certs ''could'' expire. Is that just a v2 thing? Is there some
 canonical way to refer to an onion service such that I could provide some
 option like "--key-expiration specifier-for-my-onion-service"? Should I
 optionally take an onion service's address and learn the keys from the
 configured onion service directory?

 >  - Technically speaking, keys don't expire: certificates do. The user
 needs to replace both of them, not just one.

 Right. How should we communicate this to users? I'm not a UX person at
 all, but I can vaguely naïvely foresee confusion of like "but I was asking
 about my keys".  Should I change to the cmdline flag to --cert-expiration?

 >  - The buffer in log_ed_key_expiration() can probably just be stack-
 allocated.

 Yep, done in `cc2af48569`.

 >  - Documentation on the new option should go into the manpage

 Yeah… it would probably be the nice thing to do to tell operators how to
 use it. :) I will add this once we agree on what the commandline flags and
 output should be like.

 > Please fix whatever from above you agree with. :)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17639#comment:24>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs