The text of the PEP has too much on motivation and rationale: maybe that
would be suitable for an informative PEP.
The proposal itself is under-specified.
But the real weakness cannot be fixed by improving the text: it is in the
key characteristic of the proposal, which wants to have its cake and
I think it's too much effort for too little gain.
The motivation feels very weak; surely writing
os.system("echo " + message_from_user)
is just as easy (as is the %s spelling), so the security issue can hardly
be blamed on PEP 498.
I also don't think that the current way to address such secur
On Fri, Sep 4, 2015 at 6:45 PM, Eric V. Smith wrote:
> I've made a number of small changes to PEP 498. I don't think any of the
> changes I've made in the last week are substantive. Mostly I've
> clarified how it works and removing some limitations. The only
> meaningful change is that expression
Hi Nick,
You are giving
runcommand(sh(i"cat {filename}"))
as an example that avoids injection attacks. While this is true, I think
this is still a terrible anti-pattern[1] that should not be entombed in
a PEP as a positive example.
Could you consider removing it?
(It doubly wastes resources
On Sep 04 2015, "Eric V. Smith" wrote:
> I've made a number of small changes to PEP 498. I don't think any of the
> changes I've made in the last week are substantive. Mostly I've
> clarified how it works and removing some limitations. The only
> meaningful change is that expressions are now surro
I've made a number of small changes to PEP 498. I don't think any of the
changes I've made in the last week are substantive. Mostly I've
clarified how it works and removing some limitations. The only
meaningful change is that expressions are now surrounded by parens
before they're evaluated. This a
On September 4, 2015 at 7:08:36 PM, Guido van Rossum (gu...@python.org) wrote:
> I'm no expert, but from the bug report and the man page you quoted it does
> sound like getentropy() should only be used to seed a PRNG. It also sounds
> like reading /dev/[u]random should be considered a PRNG. For evi
I'm no expert, but from the bug report and the man page you quoted it does
sound like getentropy() should only be used to seed a PRNG. It also sounds
like reading /dev/[u]random should be considered a PRNG. For evidence, the
man page on OS X says: "The random device produces uniformly distributed
r
Hi,
I followed discussions on the new systems getrandom() on Linux and
getentropy() on OpenBSD. I wanted to use them in Python to avoid the
need of a file descriptor to read /dev/urandom.
Linux getrandom() is also more secure than /dev/urandom because it
blocks until /dev/urandom is feeded with e
ACTIVITY SUMMARY (2015-08-28 - 2015-09-04)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open5057 (+15)
closed 31704 (+33)
total 36761 (+48)
Open issues wit
Hi Armin,
On 04.09.2015 02:29, Armin Rigo wrote:
Hi Valentine,
On Thu, Sep 3, 2015 at 9:15 PM, Valentine Sinitsyn
wrote:
That does not make it ok to have del called several time, does it?
That's a tricky question.
If the Python documentation now says something like ``the __del__
method is
11 matches
Mail list logo
