Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Could not determine the UTC offset on this system #51

Closed
stevemk14ebr opened this issue Jan 19, 2022 · 5 comments
Closed

Could not determine the UTC offset on this system #51

stevemk14ebr opened this issue Jan 19, 2022 · 5 comments
Labels
CVE-2020-26235 Unsound behaviour with local timezone access

Comments

@stevemk14ebr
Copy link

stevemk14ebr commented Jan 19, 2022

thread 'main' panicked at 'Could not determine the UTC offset on this system. Possible causes are that the time crate does not implement "local_offset_at" on your system, or that you are running in a multi-threaded environment and the time crate is returning "None" from "local_offset_at" to avoid unsafe behaviour. See the time crate's documentation for more information. (https://time-rs.github.io/internal-api/time/index.html#feature-flags): IndeterminateOffset', /home/steve/.cargo/registry/src/github.com-1ecc6299db9ec823/simple_logger-1.16.0/src/lib.rs:409:85
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Using initialization code:

 simple_logger::SimpleLogger::new()
    .with_level(LevelFilter::Warn)
    .with_module_level("filter", verbosity)
    .init().unwrap();

This occurs on a WSL2 console running debian. This is a really standard environment, perhaps the default could be to not try to localize the time instead, or fallback to another mode more gracefully.

I should also note this panic is 'new' after upgrading the library. The default mode now causes systems that previous ran to panic.

@borntyping borntyping added the CVE-2020-26235 Unsound behaviour with local timezone access label Jan 19, 2022
@borntyping
Copy link
Owner

See #48, #47, #44, #43, #35.

I recommend using with_utc_timestamps():

 simple_logger::SimpleLogger::new()
    .with_level(LevelFilter::Warn)
    .with_module_level("filter", verbosity)
    .with_utc_timestamps()
    .init().unwrap();

I'm currently working out if I can replace the current init() methods with new ones to change the defaults - I'm unwilling to change the default from local time to UTC time in any way that might result in user's log formats silently changing from one timezone to another with no way to tell the difference.

@borntyping
Copy link
Owner

Are you running a program that uses multiple threads, or is this happening in a single threaded application?

@stevemk14ebr
Copy link
Author

stevemk14ebr commented Jan 19, 2022

this is in a multi-threaded actix (tokio) application. My main looks like this:

#[actix_rt::main]
async fn main() {
     simple_logger::SimpleLogger::new()
        .with_level(LevelFilter::Warn)
        .with_module_level("filter", verbosity)
        .init().unwrap();
    ... stuff ...
}

@borntyping
Copy link
Owner

This is unfortunately expected then. I'm working out what I can do to change the defaults in #52, as this is caused by a dependency.

There's a list of workarounds for simple_logger, depending on how you'd prefer to deal with the issue.

  1. Use UTC time: SimpleLogger::new().with_utc_timestamps().init().unwrap();
  2. Disable timestamps: SimpleLogger::new().without_timestamps().init().unwrap();
  3. Use the time crate's unsafe features: RUSTFLAGS="--cfg unsound_local_offset" (docs)

@borntyping
Copy link
Owner

UTC timestamps are now the default in simple_logger 2.0.0.

dimtion added a commit to dimtion/copiepate that referenced this issue Mar 30, 2022
Fix a bug where simple_logger would not start due to time crate not
providing a local timestamp. simple_logger 2.x.x now displays by default
the timestamp in UTC which does not have this issue.

Since we are not displaying timestamp in logs, this bump is harmless.

Issue: borntyping/rust-simple_logger#51
Fix & recomendation: borntyping/rust-simple_logger#52
dimtion added a commit to dimtion/copiepate that referenced this issue Mar 30, 2022
Fix a bug where simple_logger would not start due to time crate not
providing a local timestamp. simple_logger 2.x.x now displays by default
the timestamp in UTC which does not have this issue.

Since we are not displaying timestamp in logs, this bump is harmless.

Issue: borntyping/rust-simple_logger#51
Fix & recomendation: borntyping/rust-simple_logger#52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CVE-2020-26235 Unsound behaviour with local timezone access
Projects
None yet
Development

No branches or pull requests

2 participants