On Thu, Jan 10, 2013 at 11:35 PM, Cron Daemon wrote:
> /home/docs/devguide/documenting.rst:766: WARNING: term not in glossary:
> bytecode
FYI, this warning is spurious (second time at least). I made an issue
about it here:
http://bugs.python.org/issue16928
--Chris
On Thu, Jan 10, 2013 at 09:57:30PM +, Vinay Sajip wrote:
> My point was that the GnuPG usage looked like an example where fds other than
> 0, 1 and 2 might be used by design in not-uncommonly-used programs. From a
> discussion I had with Barry Warsaw a while ago, I seem to remember that there
>
On Fri, Jan 11, 2013 at 5:30 PM, Charles-François Natali <
cf.nat...@gmail.com> wrote:
> > That could always be overcome by passing close_fds=False explicitly to
> > subprocess from my code, though, right? I'm not doing that now, but then
> I'm not
> > using the esoteric options in python-gnupg co
On Fri, 11 Jan 2013 04:20:21 +0100 (CET)
ezio.melotti wrote:
>
> diff --git a/Lib/test/test_crypt.py b/Lib/test/test_crypt.py
> --- a/Lib/test/test_crypt.py
> +++ b/Lib/test/test_crypt.py
> @@ -1,7 +1,11 @@
> from test import support
> import unittest
>
> -crypt = support.import_module('crypt
> That could always be overcome by passing close_fds=False explicitly to
> subprocess from my code, though, right? I'm not doing that now, but then I'm
> not
> using the esoteric options in python-gnupg code, either.
You could do that, or better explicitly support this option, and only
specify th
On Fri, Jan 11, 2013 at 2:57 PM, wrote:
> results for aef7db0d3893 on branch "default"
>
>
> test_dbm leaked [2, 0, 0] references, sum=2
> test_dbm leaked [2, 2, 1] memory blocks, sum=5
Hmm, I'm starting to wonder if there's something to this one - it
On 1/10/2013 8:54 AM, Nick Coghlan wrote:
On Wed, Jan 9, 2013 at 7:01 AM, Yury V. Zaytsev wrote:
Anyways, the point is that it's a recurrent problem, and we hit it every
single time with each new machine, so I hope you can understand why I
decided to post, even though the original message appea
Robert Whitney writes:
> I believe the exploit in use on the Python Wiki could have
> been the following remote arbitrary code execution exploit that
> myself and some fellow researchers have been working with over the
> past few days.
AFAIK, Python has a security policy. One point of t
2013/1/10 Tres Seaver :
> Why would we wander away from POSIX semantics here? There are good
> reasons not to close open descriptors (the 'pipe()' syscall, for
> instance), and there is no POSIXy way to ask for them *not* to be closed.
There are different methods to disable the close-on-exec flag
Robert Whitney wrote:
> To Whoever this may concern,
>
> I believe the exploit in use on the Python Wiki could have been the
> following remote arbitrary code execution exploit that myself and some
> fellow researchers have been working with over the past few days. I'm
> not sure if this has
2013/1/10 Charles-François Natali :
>> Network servers like inetd or apache MPM (prefork) uses a process
>> listening on a socket, and then fork to execute a request in a child
>> process. I don't know how it works exactly, but I guess that the child
>> process need a socket from the parent to send
Charles-François Natali gmail.com> writes:
>
> > How would that sit with the current proposal? I maintain a wrapper,
> > python-gnupg,
> > which communicates with the GnuPG process through subprocess. Although there
> > is
> > no in-built use of these parameters, users are allowed to pass additi
To Whoever this may concern,
I believe the exploit in use on the Python Wiki could have been the
following remote arbitrary code execution exploit that myself and some
fellow researchers have been working with over the past few days. I'm
not sure if this has quite been reported to the Moin de
> How would that sit with the current proposal? I maintain a wrapper,
> python-gnupg,
> which communicates with the GnuPG process through subprocess. Although there
> is
> no in-built use of these parameters, users are allowed to pass additional
> parameters to GnuPG, and they might use these esote
Charles-François Natali gmail.com> writes:
> > Do you have an example of what that "something" may be?
> > Apart from standard streams, I can't think of any inherited file
> > descriptor an external program would want to rely on.
>
> Indeed, it should be really rare.
GnuPG allows communicating
> Network servers like inetd or apache MPM (prefork) uses a process
> listening on a socket, and then fork to execute a request in a child
> process. I don't know how it works exactly, but I guess that the child
> process need a socket from the parent to send the answer to the
> client. If the sock
2013/1/10 Antoine Pitrou :
>> I changed my mind, the PEP does not propose to change the *default*
>> behaviour (don't set close-on-exec by default).
>>
>> But the PEP proposes to *add a function* to change the default
>> behaviour. Application developers taking care of security can set
>> close-on-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/10/2013 01:30 PM, Antoine Pitrou wrote:
> On Thu, 10 Jan 2013 12:47:23 -0500 Tres Seaver
> wrote:
>> Why would we wander away from POSIX semantics here? There are good
>> reasons not to close open descriptors (the 'pipe()' syscall, for
>> in
On Thu, 10 Jan 2013 12:47:23 -0500
Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 01/10/2013 07:52 AM, Antoine Pitrou wrote:
> > Le Thu, 10 Jan 2013 12:59:02 +0100, Victor Stinner
> > a écrit :
> >
> >> 2013/1/10 Charles-François Natali :
> >>> Disclaimer: I'm not s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/10/2013 07:52 AM, Antoine Pitrou wrote:
> Le Thu, 10 Jan 2013 12:59:02 +0100, Victor Stinner
> a écrit :
>
>> 2013/1/10 Charles-François Natali :
>>> Disclaimer: I'm not saying we should be changing all FDs to
>>> close-on-exec by default like
On Wed, Jan 9, 2013 at 7:01 AM, Yury V. Zaytsev wrote:
> Anyways, the point is that it's a recurrent problem, and we hit it every
> single time with each new machine, so I hope you can understand why I
> decided to post, even though the original message appeared back in May.
Thank you for speakin
Well, if we're at the "bikeshedding about names" stage, that means that no
serious issues with the proposal are left. So it's a sign of progress.
On Wed, Jan 9, 2013 at 12:42 AM, Stephen J. Turnbull wrote:
> Is this thread really ready to migrate to python-dev when we're still
> bikeshedding met
On Tue, 2013-01-08 at 15:09 +0100, Antoine Pitrou wrote:
>
> The original e-mail is quite old (it was sent in May) :-)
I'm sorry about that! I've just stumbled upon this thread and got scared
that --without-threads might be going away soon...
We've just been porting Python to a new supercomputer
Le Thu, 10 Jan 2013 12:59:02 +0100,
Victor Stinner a écrit :
> 2013/1/10 Charles-François Natali :
> > Disclaimer: I'm not saying we should be changing all FDs to
> > close-on-exec by default like Ruby did, I'm just saying that
> > there's a real problem.
>
> I changed my mind, the PEP does not
2013/1/10 Charles-François Natali :
> Disclaimer: I'm not saying we should be changing all FDs to
> close-on-exec by default like Ruby did, I'm just saying that there's a
> real problem.
I changed my mind, the PEP does not propose to change the *default*
behaviour (don't set close-on-exec by defau
Am 10.01.2013 11:48, schrieb Antoine Pitrou:
> Having an official afterfork facility would still help. I currently
> rely on multiprocessing.util.register_after_fork(), even though it's an
> undocumented API (and, of course, it works only for those child
> processes launched by multiprocessing, not
> 2. the solution you're proposing doesn't close the file descriptors
> after fork() but after *exec()*.
Exact. My PEP cannot solve all issues :-) I will update it to make it
more explicit.
> Having an official afterfork facility would still help.
Yes. IMO it is a different topic: you can also c
Le Thu, 10 Jan 2013 11:35:29 +0100,
Charles-François Natali a écrit :
> > So, I read your e-mail again and I'm wondering if you're making a
> > logic error, or if I'm misunderstanding something:
> >
> > 1. first you're talking about duplicate file or socket objects after
> > *fork()* (which is an
> So, I read your e-mail again and I'm wondering if you're making a logic
> error, or if I'm misunderstanding something:
>
> 1. first you're talking about duplicate file or socket objects after
> *fork()* (which is an issue I agree is quite annoying)
>
> 2. the solution you're proposing doesn't clo
Hello,
Le Wed, 9 Jan 2013 13:48:49 +0100,
Victor Stinner a écrit :
>
> Until recently (2011-05-24, issue #5715), the listening socket was not
> closed after fork for the ForkingMixIn flavor. This caused two issues:
> it's a security leak, and it causes "address already in use" error if
> the se
> The SocketServer class creates a socket to listen on clients, and a
> new socket per client (only for stream server like TCPServer, not for
> UDPServer).
>
> Until recently (2011-05-24, issue #5715), the listening socket was not
> closed after fork for the ForkingMixIn flavor. This caused two iss
31 matches
Mail list logo
