[Python-Dev] PEP 594: Removing dead batteries from the standard library
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
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
- 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.
More information about the Python-Dev