All comments have been addressed

The verity packages job failure kids
looks related to me.

@xabbuh Indeed, fixed. Thank you

What's the alternative? Isn't this PR making it easier to inadvertently put passwords in the session storage?

The alternative is to never store plain credentials in the user object especially if it's a doctrine entity but also any object that lives longer than the time required to deal with plain credentials e.g. using a DTO instead as suggested in deprec notices or just an extra form field in case of symfony/form, one that don't map to any property of the User object - that's whatmake:registration-form does for a while hence the 98% of user classes having this method empty.

I'm wondering if moving the methoderaseCredentials() from theUserInterface to it's ownEraseCredentialsInterface could be a better way to allow the removal of the emptyeraseCredentials() method from the User objects and also provide a smooth upgrade path for projects that still need the feature.

Combined with not deprecating theTokenInterface or a listener that checks for theEraseCredentialsInterface.

Based on my experience both as a Symfony core developer and a consultant, we don't need an equivalent given this is not needed for 90+% use case, a few sentences in the documentation are enough instead taking what we already have in term of educative content and docs into account. But maybe I'm wrong, if other core members and good part of Symfony developers think such alternative is needed in core, I will happily reconsider and smoothly turn this config option to false by default + extract this out of UserInterface.

To be clear. I'm fine with completely removing the erase credentials feature.

I just figured if others see a roadblock splitting the interface might be a way out to get ride of the emptyeraseCredentials() method from the User objects.

👍 I don't think we are there. Also talked about this on stage at SymfonyCon and didn't got any negative reaction, not even questions about this. The practice behind the deprecated feature is subject to trouble, I think the community already moved away from it.

Note that I'm not sure putting hashed passwords in the session storage should really be encouraged, so having a non-empty eraseCrentials (as generated by maker-bundle) might not be a best-practice either.

Let’s go for a dedicated interface then, leaving the config as it is today.

@nicolas-grekaseraseCredentials is not a proper solution to avoid including the hashed password in the serialized object. For that, the proper solution is__serialize.
Removing the hashed password from the object is very risky, because if you callflush() on the ORM after that, it will update thedatabase erasing the credentials (and then you cannot authenticate anymore)

Maybe the security system should always clone the object it stores before? Because I agree mutating is risky.

For that, the proper solution is __serialize

I'm wondering about this also: is the proper solution to implement__serialize /__unserialize?
@chalasr you're talking about having a DTO, but I'm not sure this is really a DX-friendly alternative. I wouldn't know how to implement that in just a few lines, while I could with added serialization logic.

Having a method on the class that is unsafe to call without first cloning the object might be a footgun in projects. And this would also require that the object is cloneable, which is not a requirement today (and for instance, I'm totally not sure about whether cloning a Doctrine ORM proxy instance works fine when the proxy has not been initialized yet or whether it produces a broken instance that cannot ever be initialized, while using a Doctrine entity as the user implementation is a common case and so we could end up with a proxy instance)

I don't think serializing an uninitialized entity can happen: it'd mean serializing an entity who's password was never checked. From the pov of the security component, this doesn't make sense.

But cloning usingclone is not needed if that's not safe: we can instead serialize then unserialize. That's another way to clone that's explicitly required for user objects. Maybe a better way forward?

So, it looks like we're good with adding the suggestion of implementing__serialize() as the recommended method, isn't it?

This is somewhat related to#59562 where I explain how the magic method can be used to tweak what's serialized.
Let's update this PR to give a hint in deprecations? Also some PHP doc somewhere?

Not the alternative I would take but that'll be for a blogpost, let's do it the fast way 👍 Thanks for your help on moving forward here, I'll update this asap.

See#59682 for what I had in mind.

Closing in favor of#59682