Year 2038 problem #609

New Issue

OVERLORD · 2025-10-09T16:41:17+03:00

OVERLORD commented

2025-10-09 16:41:17 +03:00

Originally created by @zacknewman on GitHub.

This is not a "vulnerability" due to the fact that the issue is 14 years away*; furthermore Vaultwarden may not even be a thing then. Anyway, I am not sure why 32-bit timestamps are used for the TOTP code considering most OSes running on 64-bit systems have been using 64-bit timestamps for a decade or more (even 32-bit Linux has support since 5.6), chrono uses i64s, and totp-lite uses u64s. The change to u64/i64s is easy in code—I've done so on my personal fork—and SQLite has no issues either since INTEGER is a flexible-width data type (up to 64 bits) and DATETIME has type affinity NUMERIC which will store values as INTEGER so long as they are valid 64-bit signed integers. I'm not sure what if anything would be needed to "fix" PostgreSQL and MariaDB/MySQL.

* Technically a contrived setup where servers and clients have their clocks in-sync but set to beyond 2038 are vulnerable.

Originally created by @zacknewman on GitHub. This is not a "vulnerability" due to the fact that the issue is 14 years away*; furthermore Vaultwarden may not even be a thing then. Anyway, I am not sure why [32-bit timestamps](https://github.com/dani-garcia/vaultwarden/blob/main/src/api/core/two_factor/authenticator.rs#L121) are used for the TOTP code considering most OSes running on 64-bit systems have been using 64-bit timestamps for a decade or more (even 32-bit Linux has support since 5.6), `chrono` uses `i64`s, and `totp-lite` uses `u64`s. The change to `u64`/`i64`s is easy in code—I've done so on my personal fork—and SQLite has no issues either since `INTEGER` is a flexible-width data type (up to 64 bits) and `DATETIME` has type affinity `NUMERIC` which will store values as `INTEGER` so long as they are valid 64-bit signed integers. I'm not sure what if anything would be needed to "fix" PostgreSQL and MariaDB/MySQL. \* _Technically a contrived setup where servers and clients have their clocks in-sync but set to beyond 2038 are vulnerable._

OVERLORD added the enhancement label 2025-10-09 16:41:17 +03:00

OVERLORD closed this issue

2025-10-09 16:41:19 +03:00

OVERLORD commented

2025-10-09 16:41:23 +03:00

@zacknewman commented on GitHub:

Why re-open it? The kid can fix it and create a PR ;)

The "kid" would use my fork which has it fixed, but they would use WebAuthn anyway so wouldn't matter.

I do believe that was a joke; but just in case it were not, let me state that my fork has diverged by 10s of thousands of lines if not over 100K. This means sending a git format-patch or PR would take time and not benefit me at all. I realize that's selfish, but I believe making an issue without a PR is better than not making an issue at all. I obviously benefited from the work of this project, so bug and security exploit reports are my contribution. Also note that I have offered PRs before privately and publicly that were rejected, so that also adds to the "waste of time" aspect.

@zacknewman commented on GitHub: > Why re-open it? The kid can fix it and create a PR ;) The "kid" would use my fork which has it fixed, but they would use WebAuthn anyway so wouldn't matter. I do believe that was a joke; but just in case it were not, let me state that my fork has diverged by 10s of thousands of lines if not over 100K. This means sending a `git format-patch` or PR would take time and not benefit me at all. I realize that's selfish, but I believe making an issue without a PR is better than not making an issue at all. I obviously benefited from the work of this project, so bug and security exploit reports are my contribution. Also note that I have offered PRs before privately and publicly that were rejected, so that also adds to the "waste of time" aspect.

OVERLORD commented

2025-10-09 16:41:23 +03:00

@BlackDex commented on GitHub:

Why re-open it? The kid can fix it and create a PR ;)

@BlackDex commented on GitHub: Why re-open it? The kid can fix it and create a PR ;)

OVERLORD commented

2025-10-09 16:41:24 +03:00

@BlackDex commented on GitHub:

If I'm correct, only the last used is stored in a i32, all other parts are 64 bit. Since 2038 is far away, i think we have time to fix this and convert this to 64bit.

Thanks for the report

@BlackDex commented on GitHub: If I'm correct, only the last used is stored in a `i32`, all other parts are 64 bit. Since 2038 is far away, i think we have time to fix this and convert this to 64bit. Thanks for the report

OVERLORD commented

2025-10-09 16:41:26 +03:00

@zacknewman commented on GitHub:

Yes, only the last used is stored/retrieved as an i32; however that is enough to invalidate the entire thing.

i think we have time to fix this and convert this to 64bit.

Lol, I agree that 14 years is enough time.

@zacknewman commented on GitHub: Yes, only the last used is stored/retrieved as an `i32`; however that is enough to invalidate the entire thing. > i think we have time to fix this and convert this to 64bit. Lol, I agree that 14 years is enough time.

OVERLORD commented

2025-10-09 16:41:27 +03:00

@LoiLock commented on GitHub:

You can have a kid in that time, only for your kid to then come back to this issue and reopen it again.

@LoiLock commented on GitHub: You can have a kid in that time, only for your kid to then come back to this issue and reopen it again.

OVERLORD commented

2025-10-09 16:41:29 +03:00

@BlackDex commented on GitHub:

Why re-open it? The kid can fix it and create a PR ;)

The "kid" would use my fork which has it fixed, but they would use WebAuthn anyway so wouldn't matter.

I do believe that was a joke; but just in case it were not, let me state that my fork has diverged by 10s of thousands of lines if not over 100K. This means sending a git format-patch or PR would take time and not benefit me at all. I realize that's selfish, but I believe making an issue without a PR is better than not making an issue at all. I obviously benefited from the work of this project, so bug and security exploit reports are my contribution. Also note that I have offered PRs before privately and publicly that were rejected, so that also adds to the "waste of time" aspect.

It does mean a bit more work for us, but indeed all the items you send we (I) will try to address. From my point of view I'm happy with them, any insight and approvements are welcome!

@BlackDex commented on GitHub: > > Why re-open it? The kid can fix it and create a PR ;) > > The "kid" would use my fork which has it fixed, but they would use WebAuthn anyway so wouldn't matter. > > I do believe that was a joke; but just in case it were not, let me state that my fork has diverged by 10s of thousands of lines if not over 100K. This means sending a `git format-patch` or PR would take time and not benefit me at all. I realize that's selfish, but I believe making an issue without a PR is better than not making an issue at all. I obviously benefited from the work of this project, so bug and security exploit reports are my contribution. Also note that I have offered PRs before privately and publicly that were rejected, so that also adds to the "waste of time" aspect. It does mean a bit more work for us, but indeed all the items you send we (I) will try to address. From my point of view I'm happy with them, any insight and approvements are welcome!

OVERLORD commented

2025-10-09 16:41:30 +03:00

@gzfrozen commented on GitHub:

Hi, I create PR to fix this. Please check:
https://github.com/dani-garcia/vaultwarden/pull/4355

@gzfrozen commented on GitHub: Hi, I create PR to fix this. Please check: https://github.com/dani-garcia/vaultwarden/pull/4355

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/vaultwarden#609