Odd to me that the focus seems to be on the inactivity of Google's package when https://github.com/gofrs/uuid not only conforms to the newer standard but is actively maintained.

▲

0x696C6961 4 hours ago | parent | next [-]

I get a kick out of publishing libs with no external deps. Regardless of reasoning, this change makes that easier.

	▲	ycombinatrix 3 hours ago \| parent [-]
		especially when they don't depend on libc.

▲

da_chicken 4 hours ago | parent | prev | next [-]

While the uuid package is actively maintained, it hasn't had a release since 2024. Indeed, there's an open issue from June 2025 asking about it: https://github.com/google/uuid/issues/194

▲

rafram 4 hours ago | parent [-]

The RFC isn’t changing, is it?

▲

JimDabell 3 hours ago | parent | next [-]

I’m not sure of the state of that particular library, but yes, the RFC has changed significantly. For instance, the UUIDv7 format changed from the earlier draft RFC resulting in incompatibilities.

This is an example of an unmaintained UUID library in a similar situation that is currently causing incompatibilities because they implemented the draft spec. and didn’t update when the RFC changed:

https://github.com/stevesimmons/uuid7/issues/1

Any Python developer using the uuid7 library is getting something that is incompatible with the UUIDv7 specification and other UUIDv7 implementations as a result. Developers who use the stdlib uuid package in Python 3.14+ and uuid7 as a fallback in older versions are getting different, incompatible behaviour depending upon which version of Python they are running.

This can manifest itself as a developer using UUIDv7 for its time-ordered property, deploying with Python <=3.13, upgrading to Python 3.14+ and discovering that all their data created with Python 3.13 sorts incorrectly when mixed with data created with Python 3.14+.

A UUID library that is not receiving updates is quite possibly badly broken and definitely warrants suspicion and closer inspection.

▲

0x696C6961 3 hours ago | parent [-]

Alternative take: don't put draft RFCs into prod

▲

JimDabell 3 hours ago | parent [-]

It hasn’t been a draft RFC for a couple of years:

https://datatracker.ietf.org/doc/rfc9562/

The problem is not that it is a draft RFC, the problem is that the library is unmaintained with an unresponsive developer who is squatting the uuid7 package name. It’s the top hit for Python developers who want to use UUIDv7 for Python 3.13 and below.

	▲	0x696C6961 2 hours ago \| parent [-]
		The problem here is a lack of namespaces. A problem the cargo bozos decided to duplicate

▲

8organicbits 3 hours ago | parent | prev [-]

RFC changes aside, the go community has been bit by unmaintained UUID libraries with security issues. Consider https://github.com/satori/go.uuid/issues/123 as a popular example.

The open issue in Google's repo about the package being malicious is not a good look. The community concluded it's a false positive. If the repo was maintained they'd confirm this and close the issue.

Maintaince is much more than RFC compliance, although the project hasn't met that bar either.

▲

PunchyHamster 14 minutes ago | parent | prev [-]

The proposal is 3 years old