alex-sherwin commented on a change in pull request #198:
URL: https://github.com/apache/mina-sshd/pull/198#discussion_r641662142
##########
File path:
sshd-common/src/main/java/org/apache/sshd/common/config/keys/OpenSshCertificate.java
##########
@@ -52,26 +57,34 @@
Collection<String> getPrincipals();
/**
- * Retrieves the time in number of seconds since the {@link
java.time.Instant#EPOCH} at which this certificate
- * becomes or became valid.
- *
- * @return the number of seconds since the Instant.EPOCH <em>as an
unsigned 64bit value</em>
- * @see {{@link #isValidNow(OpenSshCertificate)}
+ * When null, implies forever
*/
- long getValidAfter();
+ Instant getValidAfter();
+
+ default long getValidAfterEpochSeconds() {
+ if (getValidAfter() == null) {
+ return VALID_AFTER_FOREVER_EPOCH;
+ }
+ return getValidAfter().getEpochSecond();
Review comment:
I don't think it can be legally `0` and *not* mean "forever"
I just re-read the man page for `ssh-keygen`'s `validity_interval` and you
can use the magic values `always` for the `validAfter` and `forever` for
`validBefore`
But, when encoded, there is no special flag to indicate this, they are still
just epoch (seconds) uint64's, where `always` (`validAfter`) is encoded as `0`
and `forever` (`validBefore`) is uint64 max value
I manually verified this by generating certs and looking at the encoded
bytes, and you can also see it like this, where generating a certificate using
`-V 'always:20220101' versus `-V '19790101:20220101'` yield identical values.
If you inspect the cert using `ssh-keygen -L -f [file]` when using a cert
generated with `-V '19790101:20220101`, as you would now expect, it prints a
human-friendly output of what "always" would have shown. Be sure to set
`TZ=utc ssh-keygen ...` to avoid your local TZ offsets from being applied.
What's more, is if you move the date back before UTC 1970, ssh-keygen still
encodes it as `0` (which I guess they have to, since it's a uint64)
... so maybe when they defined the spec they assumed (probably rightly so)
that no one would be trying to enforce a `validAfter` time on a server that was
pretending to run pre 1970?
So, it seems to me, like they do treat `0` and max uint64 as a magic value.
However, it is also entirely possible this magic behavior is just for the
human-friendly output of the CLI tools...
I'm happy to change this to behave how you think it should, but I'm not
really sure what that should be
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
