[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #17639 [Core Tor/Tor]: provide an option to display the expiry date of a given ed25519 signing key
#17639: provide an option to display the expiry date of a given ed25519 signing key
------------------------------------------------+--------------------------
Reporter: cypherpunks | Owner: isis
Type: enhancement | Status:
| needs_review
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:
| SponsorM-can
------------------------------------------------+--------------------------
Changes (by isis):
* status: needs_revision => needs_review
* sponsor: => SponsorM-can
Comment:
Replying to [comment:24 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?)
The above two are done in
[https://gitweb.torproject.org/user/isis/tor.git/commit/?h=bug17639&id=6ba245f916e21ef3104d377cf3292f36e97c5e48
commit] `6ba245f916e`.
> > - 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.
This is done in
[https://gitweb.torproject.org/user/isis/tor.git/commit/?h=bug17639&id=7c2329c3eb22249cb68676b07bf2912c1ce58ff7
commit] `7c2329c3eb`, or the suboptions parsing is, at least. I didn't add
parsers for auth keys or onion service keys yet, because I don't really
understand which key is the auth key ("dir-identity-key"?) and the
following questions about OS keys:
> 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?
For this, I kept the command line flag as "--key-expiration" but all the
function/object names and documentation in the code uses "key certificate"
or just "certificate" everywhere.
([https://gitweb.torproject.org/user/isis/tor.git/commit/?h=bug17639&id=d01793e2ee6c5212d9f4add22087a081893645ba
Commit] `d01793e2ee`.)
> > - 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.
Done in
[https://gitweb.torproject.org/user/isis/tor.git/commit/?h=bug17639&id=9e6aee990504a57bc92fd11e9c0fd1fe05db2401
commit] `9e6aee99`.
> > Please fix whatever from above you agree with. :)
I also added tests and fixed some problems the tests caught in
[https://gitweb.torproject.org/user/isis/tor.git/commit/?h=bug17639&id=9b82470a27aceb7a279fd910eed878180d43956e
commit] `9b82470a27`.
I made oniongit PR for review, if we want that!
https://oniongit.eu/network/tor/merge_requests/3
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17639#comment:28>
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