RUSTSEC-2020-0159

[dandavison]

IIUC, projects using syntect are currently affected by RUSTSEC-2020-0159. This is because syntect depends on the plist crate, and plist depends on chrono, and chrono contains the security problem. There is an unreleased fix for this in plist: ebarnard/rust-plist#72 so IIUC if that were released, and syntect were to update to it, then that would fix the issue. There is also current discussion in the chrono repo about fixing the situation there: chronotope/chrono#499. cc @sharkdp

(Or is there a feature-based workaround for now?)

[Enselic]

It would be great if someone could come up with a way to reproduce this with syntect.

[extrawurst]

I think its not only relevant if there is a reproducible way to trigger the actual bug using syntect.
Most corporate policy prevents keeping RUSTSECs around.
In case of syntect its an easy fix once plist releases a version including the fix

[Enselic]

Well, if there is no way to trigger the bug with syntect, there is no point to keep this issue open in syntect.

And if there is a way to trigger it, it is very useful to use that to confirm that the issue is gone once we bump plist.

[michaelblyons]

Looks like PList released a fix two days ago...?

[Enselic]

The thing is, syntect does not specify a version of plist. Only a minimal version. It is then up to clients of syntect to pick an actual version of plist. So I'm not sure what syntect should do here. Bump minimum version of plist to 1.3.0? Then I think someone needs to show that syntect is actually affected by this bug.

Related: #397

[Enselic]

Since we are about to do a major bump I think we can increase the minimum plist version without any concerns. I'll take care of that when I get time.

[Enselic]

As far as I can tell, #414 removes the indirect chrono dependency from syntect, which should be enough to fix this issue.

Any help with double-checking that would be appreciated. Otherwise we'll just have to assume the above PR solves this RUSTSEC issue for syntect.