[Python-Dev] PEP 594: Removing dead batteries from the standard library

[Steven D'Aprano]

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:

- tell them to re-implement spwd (but that undercuts your argument 
  for removal);

- tell them to use a third party module (but which?);

- add a replacement module that Does The Right Thing;

- or at least a recipe somewhere (but once the spwd module is 
  removed, where will the recipe live?);

- anything else?


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