The 0.6.4 release bumped the MSRV to 1.88 by pinning time to 0.3.47 #40

New issue

Open

opened 2026-02-13 03:22:54 -08:00 by tillrohrmann · 2 comments

tillrohrmann commented

2026-02-13 03:22:54 -08:00

(Migrated from github.com)

The latest 0.6.4 release implicitly bumped the MSRV to 1.88 because it pinned the time dependency to 0.3.47. The change was introduced with github.com/acw/simple_asn1@b40a5dcd97. I am wondering whether this is strictly needed as our library is now failing to build with it's MSRV of 1.85. Alternatively, we could think about announcing the MSRV of this library. That way cargo can pick an older version of simple_asn1 that satisfies the MSRV requirements.

The latest 0.6.4 release implicitly bumped the MSRV to 1.88 because it pinned the time dependency to 0.3.47. The change was introduced with https://github.com/acw/simple_asn1/commit/b40a5dcd970c8b15d20998bde7bf8fcf2be8e502. I am wondering whether this is strictly needed as our library is now failing to build with it's MSRV of 1.85. Alternatively, we could think about announcing the MSRV of this library. That way cargo can pick an older version of simple_asn1 that satisfies the MSRV requirements.

acw commented

2026-02-23 20:12:40 -08:00

(Migrated from github.com)

Hey Til! Sorry about that. The update was due to a security advisory, and it doesn't look like there's a newer version to pin to. I think the best bet might be to have this library set its MSRV, then, unfortunately.

Hey Til! Sorry about that. The update was due to a [security advisory](https://rustsec.org/advisories/RUSTSEC-2026-0009.html), and it doesn't look like there's a newer version to pin to. I think the best bet might be to have this library set its MSRV, then, unfortunately.

arckoor commented

2026-04-11 08:22:49 -07:00

(Migrated from github.com)

I'm also encountering this issue. Judging from the advisory though, this is only relevant if you parse with the RFC 2822 format. I'm not intimately familiar with all the edge cases ASN.1 might have, but I at least failed to find any uses of time::format_description::well_known::Rfc2822 in the code, so I'm wondering if the bump was even necessary?

I'm also encountering this issue. Judging from the [advisory](https://github.com/advisories/GHSA-r6v5-fh4h-64xc) though, this is only relevant if you parse with the RFC 2822 format. I'm not intimately familiar with all the edge cases ASN.1 might have, but I at least failed to find any uses of `time::format_description::well_known::Rfc2822` in the code, so I'm wondering if the bump was even necessary?