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

Lock regex crate at min 1.5.5 for CVE-2022-24713 #2145

Merged
merged 1 commit into from
Apr 2, 2022

Conversation

Enselic
Copy link
Collaborator

@Enselic Enselic commented Apr 2, 2022

Cargo.lock already specifies 1.5.5, but we should also do it in Cargo.toml.

I forgot that in #2139.

For #2125

Cargo.lock already specifies 1.5.5, but we should also do it in
Cargo.toml.
@sharkdp
Copy link
Owner

sharkdp commented Apr 2, 2022

I don't know if bat is really "vulnerable" to this CVE, but anyway: to resolve that completely, would we also have to make sure that we do not transitively depend on that older regex version?

It looks good

▶ cargo tree | rg regex
│   ├── regex v1.5.5
│   │   └── regex-syntax v0.6.25
│   │   └── regex-automata v0.1.10
│   └── regex v1.5.5 (*)
│   ├── regex v1.5.5 (*)
├── regex v1.5.5 (*)
│   ├── regex-syntax v0.6.25
│   │   └── regex v1.5.5 (*)

but I wonder if that is guaranteed by having 1.5.5 specified in the lock file?

@Enselic
Copy link
Collaborator Author

Enselic commented Apr 2, 2022

After skimming through https://doc.rust-lang.org/cargo/reference/resolver.html it seems as if different versions of the same crate is only allowed if the versions are within different semver domains. So if some dependency would have depended on say 1.3.0 then the resolver will still make sure that at least 1.5.5 is used for both, since they are in the same semver compatibility domain.

But if some crate transitively depended on 0.2.0 of regex, then we would build against both 0.2.0 and 1.5.5.

Anyway, thanks for checking with cargo tree, it seems like we are good to go.

I'm not sure either if we are vulnerable, but it seems easier to me to just do the bump than to dig deeper :)

@Enselic Enselic merged commit 47e0dc2 into sharkdp:master Apr 2, 2022
@Enselic Enselic deleted the lock-regex-at-1.5.5 branch April 2, 2022 19:46
@sharkdp
Copy link
Owner

sharkdp commented Apr 2, 2022

I'm not sure either if we are vulnerable, but it seems easier to me to just do the bump than to dig deeper :)

Agreed

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.

2 participants