FAQ
TLDR...
1. Conversion from uint64 to int64 to time.Time and then back had issues
with negative times (before unix epoch) which are not allowed in certs.
2. Helps with parse/marshal when trying to work around issue 1.


The field encoding is defined as a uint64, not an int64 like is becoming
typical for representing time with 64bit values. It was done this way
in the spec to avoid introducing a new wire encoding format for ssh
(this was djm's reasoning when I asked). Also, valid times for
certificates must start at unix epoch. So, a value of 0 is supposed to
correspond to unix epoch.

The problem this solves...

In openssh, if a time frame/window is not specified for a certificate
during creation, the default behavior is to set ValidAfter to all 0's
and ValidBefore to all 1's (in binary form). This is known as the
"forever" setting. Previously, the code was doing a direct conversion
from uint64 to int64. Any value above 1<<63-1 (max for an int64) gets
treated as a negative value. So, what should be considered a positive
value (really far into the future) suddenly becomes the past (before
unix epoch). Specifically, 0xFFFFFFFFFFFFFFFF in a uint64 is really far
into the future, but that same value in an int64 is -1 or unix epoch - 1
second. In the current form, when doing time validation on a cert, this
will flip flop the window so that the certificate expires before it ever
becomes valid.

Introducing CertTime will clamp the time range to start at unix epoch
and go to the max value for int64, but never before unix epoch. So, the
time window is always positive.

The other issue this solves is encoding. In trying to find a good way
around this issue with just a time.Time value, everything I did would
screw up the parse/marshal value comparison. If you want a test for
this, we already have one. The example key that jpsugar provided has
validafter at 0 and validbefore at all 0xFF bytes because he never set a
time window. So, the cert is intended to always be good. With the
current code, the certificate would have been expired one second before
it became valid.

Does that make sense?


https://codereview.appspot.com/15520047/diff/40002/ssh/certs.go
File ssh/certs.go (right):

https://codereview.appspot.com/15520047/diff/40002/ssh/certs.go#newcode55
ssh/certs.go:55: // handle time values above what a time.Time can
represent and prevent values
I wrote two comments. One for the reader of the code and one for
package documentation. I was hoping the first one explained the
reasoning for the CL.

https://codereview.appspot.com/15520047/

--

---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 5 of 11 | next ›
Discussion Overview
groupgolang-dev @
categoriesgo
postedOct 22, '13 at 9:36p
activeOct 23, '13 at 4:44p
posts11
users4
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase