starred/vaultwarden

Fork 0

mirror of https://github.com/dani-garcia/vaultwarden.git synced 2026-04-26 09:46:00 +03:00

[GH-ISSUE #4177] Year 2038 problem #1807

New issue

Closed

opened 2026-03-03 02:12:22 +03:00 by kerem · 7 comments

kerem commented

2026-03-03 02:12:22 +03:00

Owner

Originally created by @zacknewman on GitHub (Dec 17, 2023).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/4177

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 (Dec 17, 2023). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/4177 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._

kerem

2026-03-03 02:12:22 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-03-03 02:12:23 +03:00

Author

Owner

@BlackDex commented on GitHub (Dec 17, 2023):

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 (Dec 17, 2023): 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

kerem commented

2026-03-03 02:12:23 +03:00

Author

Owner

@zacknewman commented on GitHub (Dec 17, 2023):

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 (Dec 17, 2023): 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.

kerem commented

2026-03-03 02:12:23 +03:00

Author

Owner

@LoiLock commented on GitHub (Jan 12, 2024):

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 (Jan 12, 2024): You can have a kid in that time, only for your kid to then come back to this issue and reopen it again.

kerem commented

2026-03-03 02:12:23 +03:00

Author

Owner

@BlackDex commented on GitHub (Jan 12, 2024):

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

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

kerem commented

2026-03-03 02:12:23 +03:00

Author

Owner

@zacknewman commented on GitHub (Jan 12, 2024):

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 (Jan 12, 2024): > 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.

kerem commented

2026-03-03 02:12:23 +03:00

Author

Owner

@BlackDex commented on GitHub (Jan 12, 2024):

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 (Jan 12, 2024): > > 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!

kerem commented

2026-03-03 02:12:24 +03:00

Author

Owner

@gzfrozen commented on GitHub (Feb 15, 2024):

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

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

kerem referenced this issue

2026-03-03 09:09:21 +03:00

[PR #1809] [MERGED] Fix armv7 alpine build. #3010