[Python-Dev] PEP 594: Removing dead batteries from the standard library (original) (raw)

Steven D'Aprano steve at pearwood.info
Wed May 22 20:58:31 EDT 2019

On Wed, May 22, 2019 at 01:31:18PM +0200, Christian Heimes wrote:

On 22/05/2019 12.19, Steven D'Aprano wrote: > I don't think this PEP should become a document about "Why you should > use PAM". I appreciate that from your perspective as a Red Hat security > guy, you want everyone to use best practices as you see them, but it > isn't Python's position to convince Linux distros or users to use PAM.

I think the PEP should make clear why spwd is bad and pining for The Fjords. The document should point users to correct alternatives. There is no correct and secure way to use the spwd module to verify user accounts. Any use of spwd for logins introduces critical security bugs.

When you use absolute language about security without considering threat models, like "there is no ... way" and "Any use", you lose credibility in my eyes.

I have a Linux desktop where I am the only user but not the only user account. If I use spwd, what vulnerabilty am I introducing? That's not a rhetorical question. If spwd does introduce a threat that isn't already there, then please educate me, I genuinely want to know.

But if it doesn't, then you ought to tone down the absolutist language about "no way" and "any use" because that is factually untrue.

Later, you wrote:

Steven, I feel like you are turning my own words and arguments against me.

Yes? Is that supposed to be a bad thing?

If you make an argument which is intended to support the PEP, but it actually undercuts the PEP, then you should fix the argument or acknowledge that the case for the PEP is not as strong as you hoped.

We do you no favours by ignoring weak or incoherent arguments.

PEPs are supposed to be fair, not partisan. Of course you have a position on this matter: you want to see spwd removed, and you want to put the best possible case for it. But to be a fair PEP, you also need to acknowledge counter-arguments and weaknesses in the argument, not just hope people won't notice them and then protest when they do.

By the way, all relevant BSD, Linux, and Darwin (macOS) distributions come with PAM support. Almost all use PAM by default. AFAIK only the minimal Alpine container does not have PAM installed by default. This is not Red Hat trying to evangelize the world. PAM is the industry standards on Unix-like OS.

I appreciate that PAM is the standard, but Unix-like users are often an individualistic lot and "PAM is the default" doesn't mean "everyone uses PAM". See, for example, Arfrever's earlier post.

This PEP isn't about using PAM. It's about removing spwd and crypt. It's okay to say that PAM is the industry standard, you don't have to justify that in depth on the PEP. Nor do you need to justify why most people should be using PAM, but you ought to acknowledge that there may be some people who aren't.

For those who (rightly or wrongly) won't, can't or simply don't know how to use PAM, removing spwd is a functional regression. As PEP author, your job is to justify that functional regression and offer an alternative. We have a number of options:

As PEP author, you get to choose which option the PEP suggests, but if you pick the one that undercuts the argument for removal, don't be surprised if people notice and consider the case for removal to be weak.

-- Steven

More information about the Python-Dev mailing list