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

Add semgrep rule for .elapsed() #4369

Merged
merged 2 commits into from
Feb 23, 2024
Merged

Conversation

bradleystachurski
Copy link
Member

@bradleystachurski bradleystachurski commented Feb 20, 2024

Followup to prevent further bugs similar to #4356

This rule catches usages of method calls to .elapsed(). I did an audit of all public functions for std::time::SystemTime and this is the only one that calls std::time::SystemTime::now.

Semgrep supports typed metavariables (docs), which would be much better than catching any usage of .elapsed(), however after testing locally it doesn't catch the usage in the associated PR. Rust support is beta and I believe it's limited in its ability to parse types from struct fields. We're currently using semgrep v1.37.0, so I installed the latest version and that doesn't work either.

Semgrep PR introducing typed metavariables for rust: semgrep/semgrep#8201

@bradleystachurski bradleystachurski requested a review from a team as a code owner February 20, 2024 15:01
languages:
- rust
message: Use fedimint_core::time::now and std::time::duration_since to compare an elapsed time for better wasm compatibility.
pattern: $SYSTEM_TIME.elapsed()
Copy link
Contributor

@dpc dpc Feb 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was hoping:

- id: ban-system-time-elapsed
  languages:
    - rust
  message: TBD
  pattern-either:
    - pattern: std::time::SystemTime::elapsed
    - pattern: std::time::Instant::elapsed

  severity: WARNING

would work, but it seems it doesn't. I guess method calls need to be done via $foo.bar?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I was hoping the same and came to the same conclusion for method calls via $foo.bar.

It's also worth noting a footgun:

pattern: '($SYSTEM_TIME: std::time::SystemTime).elapsed()'

This is valid syntax for typed metavariables and implies it will only match method calls to SystemTime.elapsed(), however semgrep is unable to parse the type from struct fields so we could accidentally sneak in additional calls to .elapsed().

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I guess semgrep would have to do a perfect type resolution and inference like rustc to be able to know types of method receivers, which seems prohibitively complex and slow for basically a linter.

dpc
dpc previously approved these changes Feb 20, 2024
@@ -909,7 +909,7 @@ impl LightningClientModule {
.get_value(&MetaOverridesKey {})
.await
{
let elapsed = now().duration_since(cache.fetched_at).unwrap();
let elapsed = now().duration_since(cache.fetched_at)?;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we make this an unwrap_or_default to stay in sync with 0.2.3? See #4370

@justinmoon
Copy link
Contributor

What about just banning use of std::time in all our client module crates? Anything time-related that you want to use needs to come from fedimint-core which should always have WASM-compatible implementations?

@elsirion
Copy link
Contributor

What about just banning use of std::time in all our client module crates? Anything time-related that you want to use needs to come from fedimint-core which should always have WASM-compatible implementations?

I think that's a great idea!

@bradleystachurski
Copy link
Member Author

What about just banning use of std::time in all our client module crates?

Shoot, I like the idea but semgrep doesn't catch the import. This is a draft PR with a global ban of std::time but semgrep passes. Looks like there are known limitations for use declarations (semgrep/semgrep#6593).

#4386

@dpc dpc added this pull request to the merge queue Feb 23, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to no response for status checks Feb 23, 2024
@dpc dpc added this pull request to the merge queue Feb 23, 2024
Merged via the queue into fedimint:master with commit 32e5994 Feb 23, 2024
20 checks passed
@bradleystachurski bradleystachurski deleted the elapsed-semgrep branch February 24, 2024 03:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants