fix(parsing): Handling wrong timestamps in dnstap-parser

[wooffie]

Summary

While parsing dnstap we can get panic while working with timestamps. Let's timestamp parse function returns Err for observe it. Maybe we should use more trivial construction and Err =)

Change Type

• Bug fix
• New feature
• Non-functional (chore, refactoring, docs)
• Performance

Is this a breaking change?

• Yes
• No

How did you test this PR?

Reproducer:

#[test]
    fn repro_crash() {
        let mut log_event = LogEvent::default();
        let raw_dnstap_data = "KAJyAHICUgByMDAwMDAwMDAwMDAwMUAwMDAwMDAwMDAwMDAwMDAwMGD/////////rjAwMDAwMDAwMDAAcgJyAHIA";
        let dnstap_data = BASE64_STANDARD
            .decode(raw_dnstap_data)
            .expect("Invalid base64 encoded data.");
        let _parse_result = DnstapParser::parse(
            &mut log_event,
            Bytes::from(dnstap_data),
            DnsParserOptions::default(),
        );
        println!("{:?}",_parse_result);
    }

Trace:

---- parser::tests::repro_crash stdout ----

thread 'parser::tests::repro_crash' panicked at lib/dnstap-parser/src/parser.rs:372:22:
attempt to multiply with overflow
stack backtrace:
   0: rust_begin_unwind
             at /rustc/4eb161250e340c8f48f66e2b929ef4a5bed7c181/library/std/src/panicking.rs:692:5
   1: core::panicking::panic_fmt
             at /rustc/4eb161250e340c8f48f66e2b929ef4a5bed7c181/library/core/src/panicking.rs:75:14
   2: core::panicking::panic_const::panic_const_mul_overflow
             at /rustc/4eb161250e340c8f48f66e2b929ef4a5bed7c181/library/core/src/panicking.rs:178:21
   3: dnstap_parser::parser::DnstapParser::parse_dnstap_message_time
             at ./src/parser.rs:372:22
   4: dnstap_parser::parser::DnstapParser::parse_dnstap_message
             at ./src/parser.rs:243:13
   5: dnstap_parser::parser::DnstapParser::parse
             at ./src/parser.rs:153:25
   6: dnstap_parser::parser::tests::repro_crash
             at ./src/parser.rs:1192:29
   7: dnstap_parser::parser::tests::repro_crash::{{closure}}
             at ./src/parser.rs:1186:21
   8: core::ops::function::FnOnce::call_once
             at /home/wooffie/.rustup/toolchains/1.85-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5
   9: core::ops::function::FnOnce::call_once
             at /rustc/4eb161250e340c8f48f66e2b929ef4a5bed7c181/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.


failures:
    parser::tests::repro_crash

Does this PR include user facing changes?

• Yes. Please add a changelog fragment based on our guidelines.
• No. A maintainer will apply the "no-changelog" label to this PR.

Notes

• Please read our Vector contributor resources.
• Do not hesitate to use @vectordotdev/vector to reach out to us regarding this PR.
• The CI checks run only after we manually approve them.
  • We recommend adding a pre-push hook, please see this template.
  • Alternatively, we recommend running the following locally before pushing to the remote branch:
    • cargo fmt --all
    • cargo clippy --workspace --all-targets -- -D warnings
    • cargo nextest run --workspace (alternatively, you can run cargo test --all)
    • ./scripts/check_changelog_fragments.sh
• After a review is requested, please avoid force pushes to help us review incrementally.
  • Feel free to push as many commits as you want. They will be squashed into one before merging.
  • For example, you can run git merge origin master and git push.
• If this PR introduces changes Vector dependencies (modifies Cargo.lock), please
  run cargo vdev build licenses to regenerate the license inventory and commit the changes (if any). More details here.

References

[pront]

Thanks @wooffie! Can you add a changelog and a test case?

[wooffie]

Hi, I found one more bug with casting to i64 from u64 and add one more check for it.