Abdur-Rahmaan Janhangeer writes: > This whole thread reminds me of a comment of > Miguel Grinberg i remember somewhere when discussing > secrets. Some go for .env some for env variables but he suggested > focusing the attention on not letting people getting access to the > server instead of trying to be clever about hiding secrets.
'Support For Private' is really a quite different discussion from 'Defending Secrets', though. It's true that hiding secrets is not a good idea (in particular, on a computer where "dd /dev/sda1 | grep" means everything hidden is hiding in plain sight). On the other hand, if something is an important secret, you should do both: restrict access to the secret for users who have access to the server, and restrict access to the server. (By definition, you can't completely deny access to a server, there has to be some way for clients to get service!) The fundamental issue is a zero-sum game, attacker vs. defender. In Support For Private, however, we're talking about a positive-sum game. Code writers need to communicate with code readers, both human and machine, while avoiding mistakes. In fact, this is almost a purely cooperative game. Another difference is that Secrets Defense is a *repeated* game, like chess: you play, someone wins, you set up the board again and play the same game. Here we have a *stochastic* game, like business, where playing changes the game a bit. The idea of 'private' is to "defend" the API, for example avoiding build up of metastasized technical debt (trying to keep the technical debt in one place, contained within the provider of the API). Here some conflict of interest comes in: consumers of the API want more flexibility or less bureaucracy either for runtime or writetime efficiency. But the discussion is likely to need to be even more nuanced, as the API itself may need to evolve and may represent technical debt. Then it is indeed convenient to be able to change 'private' to '' in one place rather than a global search-replace on '_identifier' to 'identifier'. Of course all of these positive-sum, dynamic considerations enter into the Secrets Defense game too, but that one is much simpler and more encapsulated (yes, I know about GPG and simplicity :-/, but really, it is a much simpler situation). I think it's reasonable to think of repetition of a static game there in a way it simply isn't for 'private' in a programming language. Steve _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RINZTK4WP6MTZNJSN3BBGMX6RI43UYN2/ Code of Conduct: http://python.org/psf/codeofconduct/
