> the only way for keyston to do this would be to wait for the user to auth and as a sideffect of thatt caluate a newer hash after they verify the users credentials

And that would be really a great way to do it from my prespective. Though, it would require at this point to:
- re-implement sha512-crypt algorithm natively without passlib
- backport to 2025.1
- maintain it for couple of cycles to allow users to naturally login and update the hash

> the SELECT query shows one less entry

I realized there is an issue in this SQL query actually - I have not figured out the correct one so far though. And the issue is, that not all "non-expired" passwords are actually relevant ones for the user, so there has to be another JOIN. As current query may include also historical passwords for the user.

> Is this approach reasonable to just switch the hashing algorithm and nothing else by simply setting the existing password again

Sure, if you know the password - setting the same password again for the user will work indeed.

вт, 26 авг. 2025 г. в 09:02, Tobias Urdin - Binero <tobias.urdin@binero.com>:
Thanks for the heads-up! :)

/Tobias

On 25 Aug 2025, at 18:12, Dmitriy Rabotyagov <noonedeadpunk@gmail.com> wrote:

Hey folks,

I wanted to raise awareness of operators regarding Keystone upgrade to Epoxy (2025.1), as found that existing release notes are slightly more vague about corner case definition.

During analysis, it appeared that a lot of users (and under "a lot" I mean 4 figures number) in my really old deployments (which were deployed during Newton), still in use passwords hashed with sha512_crypt which has been dropped in 2025.1 [1]. As this was referenced as a "corner case" in upgrade docs, it may not bring enough attention to this matter reading notes, while sha512_crypt removal is mentioned in "Other" section which I personally missed when analyzing upgrade requirements.

So I would highly recommend to ensure that all your users are using supported hashing algorithms before the upgrade to Epoxy, and inform them to reset their passwords if they don't.

You can list users who are using unsupported hashing algorithm using following MySQL query:
SELECT distinct l_u.user_id FROM keystone.local_user AS l_u JOIN keystone.password AS hash ON l_u.id = hash.local_user_id WHERE (hash.password_hash LIKE '$6$%' OR hash.password_hash LIKE '$5$%') AND hash.expires_at i
s null;

Hope this helps somebody to save some time in the future.