fix: explicitly disallow negative timestamps in libzauth tokens

[comawill]

timestamp in Token is a signed integer, but is required to be an unsigned integer for Duration.

Since is_expired will always only be used on tokens with non negative values, we can safely reject all attempts to verify a token with negative timestamp values.

Checklist

• [x] Add a new entry in an appropriate subdirectory of changelog.d
• [x] Read and follow the PR guidelines

[comawill]

@OtaK I might ask stupid questions, but I have problems following your arguments for this specific case:

 fn is_expired(&self) -> bool {
        // negative timestamps are always considered as expired
        if self.timestamp < 0 {
            return false;
        }
        let expiration = UNIX_EPOCH + Duration::from_secs(self.timestamp as u64);
        expiration < SystemTime::now()
    }

My braindump:

• self.timestamp is a i64 (signed 64 bit integer)
• we make sure that self.timestamp > 0 -> MSB is 0 -> only 63 bit representation
• we cast self.timestamp to u64 (unsigned 64 bit integer)
• a cast of a unsigned 63bit integer into a unsigned 64bit integer is safe
• Duration::from_secs expects a u64
• rustlang's SystemTime is intended to be Y2038 safe even on 32bit systems (e.g. https://doc.rust-lang.org/src/std/sys/unix/time.rs.html#329)

OT:

• timestamps can be negative to represent times before epoch 0, but don't make sense to represent dates in the future

Therefore PR intends to make it 100% sure, that is_expired never accepts negative timestamp values (even though they should never appear in the first place).

All changes don't break current compatibility.

[CLAassistant]

All committers have signed the CLA.