Well, for all intents and purposes, it is over for the security issue that is disclosed. Even if people continue investigating further potential issues and rolling back potentially innocuous changes out of an abundance of caution, there's genuinely nothing else for consumers of liblzma5 or xz to do directly, unless they want to participate in that investigation.
But, for users of xz, like package managers, I think the right thing to do is sandbox all of the compression (and other data handling routines) using OS-level sandboxing technology like seccomp and pledge if they don't already. It's already a common strategy for handling potentially unsafe data, and while packages are typically signed and could potentially compromise the system anyway if not trustworthy, it's still worth it because a compromise via RCE in the LZ algorithm could possibly be VASTLY more difficult to detect than the package itself being malicious, in the same way that compromising SSH via a library it doesn't even nominally depend on is. (e.g. a package could potentially detect if it is being unpacked manually or via a package manager to try to hide that it is malicious!)
But, for users of xz, like package managers, I think the right thing to do is sandbox all of the compression (and other data handling routines) using OS-level sandboxing technology like seccomp and pledge if they don't already. It's already a common strategy for handling potentially unsafe data, and while packages are typically signed and could potentially compromise the system anyway if not trustworthy, it's still worth it because a compromise via RCE in the LZ algorithm could possibly be VASTLY more difficult to detect than the package itself being malicious, in the same way that compromising SSH via a library it doesn't even nominally depend on is. (e.g. a package could potentially detect if it is being unpacked manually or via a package manager to try to hide that it is malicious!)