Use time in stead of chrono in hello world example#136
Use time in stead of chrono in hello world example#136Swaagie wants to merge 4 commits intoproxy-wasm:masterfrom
Conversation
4abfb1c to
91e4dd6
Compare
Signed-off-by: Martijn Swaagman <martijn@swaagman.online>
Signed-off-by: Martijn Swaagman <martijn@swaagman.online>
Signed-off-by: Martijn Swaagman <martijn@swaagman.online>
91e4dd6 to
67b85d0
Compare
Signed-off-by: Martijn Swaagman <martijn@swaagman.online>
|
Is this good to merge? |
jcrugzz
left a comment
There was a problem hiding this comment.
Would be cool to get this merged just to clear up the red X on CI. LGTM
PiotrSikora
left a comment
There was a problem hiding this comment.
IMHO, this change is wrong. The 2 CVEs affecting chrono are:
-
RUSTSEC-2020-0071 - which can be easily fixed by removing
oldtimefeature fromchronodependency. -
RUSTSEC-2020-0159 - which doesn't have a clear fix, but it also doesn't affect this project. The CVE is about the unsafe use of
localtime_rsyscall, which isn't exposed inwasm32-*targets, nor used withDateTime<Utc>. Futhermore, thetimecrate didn't solve the underlying issue, but they've hidden calls tolocaltime_rbehind a feature flag, so I don't think it's much better, security-wise. Lastly, I believe thatchronois (or was?) more popular in the Rust ecosystem, so I'd prefer to leave it as a more representative example. I agree that we should fix thecargo-auditwarning, but that's going to be cleaned up with #140... in the meantime, we can excludeRUSTSEC-2020-0159using--ignoreflag.
|
Closing in favor of #144 |
Rust/audit ✅ by sidestepping reported security vulnerability for which there is no clear resolution.
Regenerated lockfiles
Extracted from: #129