This is just a note that we have one bug blocking 2.7 final at the moment: http://bugs.python.org/issue9144 -- Regards, Benjamin
On Sat, Jul 3, 2010 at 1:28 PM, Benjamin Peterson <benjamin@python.org> wrote:
This is just a note that we have one bug blocking 2.7 final at the moment: http://bugs.python.org/issue9144
I added Jesse to the nosy list for that as well. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Fri, Jul 2, 2010 at 11:40 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On Sat, Jul 3, 2010 at 1:28 PM, Benjamin Peterson <benjamin@python.org> wrote:
This is just a note that we have one bug blocking 2.7 final at the moment: http://bugs.python.org/issue9144
I added Jesse to the nosy list for that as well.
Cheers, Nick.
Committed the patch for 9144 - Brett broke mah imports!
On Sat, Jul 3, 2010 at 4:28 AM, Benjamin Peterson <benjamin@python.org> wrote:
This is just a note that we have one bug blocking 2.7 final at the moment: http://bugs.python.org/issue9144
I've just made http://bugs.python.org/issue7673 a release blocker too, I'm afraid. It's a potential security vulnerability in the audioop module. (CVE-2010-2089). It's got a reviewed patch, and is ready to be committed, but if you're not comfortable with fixing it this late then that's completely understandable. Mark
On Sat, 3 Jul 2010 11:17:16 +0100 Mark Dickinson <dickinsm@gmail.com> wrote:
On Sat, Jul 3, 2010 at 4:28 AM, Benjamin Peterson <benjamin@python.org> wrote:
This is just a note that we have one bug blocking 2.7 final at the moment: http://bugs.python.org/issue9144
I've just made http://bugs.python.org/issue7673 a release blocker too, I'm afraid. It's a potential security vulnerability in the audioop module. (CVE-2010-2089). It's got a reviewed patch, and is ready to be committed, but if you're not comfortable with fixing it this late then that's completely understandable.
Interestingly, Victor filed both the issue and the initial patch five months before the CVE alert. Well done Victor!
Le samedi 03 juillet 2010 12:17:16, Mark Dickinson a écrit :
On Sat, Jul 3, 2010 at 4:28 AM, Benjamin Peterson <benjamin@python.org> wrote:
This is just a note that we have one bug blocking 2.7 final at the moment: http://bugs.python.org/issue9144
I've just made http://bugs.python.org/issue7673 a release blocker too, I'm afraid. It's a potential security vulnerability in the audioop module. (CVE-2010-2089)
At least, Fedora consider it as a security vulnerability: https://bugzilla.redhat.com/show_bug.cgi?id=598197 I agree because the crash is caused by the input data.
It's got a reviewed patch, and is ready to be committed
Thanks because my first patch was incomplete :-)
but if you're not comfortable with fixing it this late then that's completely understandable.
In the worst case, a function rejects valid data. If I have to choose, I prefer to reject valid data than a security vulnerability. But audioop has tests and I don't think that my patch breaks anything :-) -- Victor Stinner http://www.haypocalc.com/
Le samedi 03 juillet 2010 14:26:53, Victor Stinner a écrit :
In the worst case, a function rejects valid data. If I have to choose, I prefer to reject valid data than a security vulnerability. But audioop has tests and I don't think that my patch breaks anything :-)
I checked the test suite: *all* audioop function are tested at least once. So, can I / should I commit the patch? -- Victor Stinner http://www.haypocalc.com/
On Sat, 3 Jul 2010 14:40:57 +0200 Victor Stinner <victor.stinner@haypocalc.com> wrote:
Le samedi 03 juillet 2010 14:26:53, Victor Stinner a écrit :
In the worst case, a function rejects valid data. If I have to choose, I prefer to reject valid data than a security vulnerability. But audioop has tests and I don't think that my patch breaks anything :-)
I checked the test suite: *all* audioop function are tested at least once.
So, can I / should I commit the patch?
In my opinion you can.
On Sat, Jul 3, 2010 at 3:26 PM, Victor Stinner <victor.stinner@haypocalc.com> wrote:
In the worst case, a function rejects valid data. If I have to choose, I prefer to reject valid data than a security vulnerability. But audioop has tests and I don't think that my patch breaks anything :-)
But Python tests lack coverage stats, so it is hard to say anything. Even with tests it is not always possible to be even 80% sure if behavior is complicated or depends on the input data. -- anatoly t.
But Python tests lack coverage stats, so it is hard to say anything. FYI: http://coverage.livinglogic.de/
Regards
On 7/4/2010 2:31 AM, Éric Araujo wrote:
But Python tests lack coverage stats, so it is hard to say anything. FYI: http://coverage.livinglogic.de/
Turns out the audioop is one of the best covered modules, at 98% -- Terry Jan Reedy
On Mon, Jul 5, 2010 at 5:20 AM, Terry Reedy <tjreedy@udel.edu> wrote:
On 7/4/2010 2:31 AM, Éric Araujo wrote:
But Python tests lack coverage stats, so it is hard to say anything.
Turns out the audioop is one of the best covered modules, at 98%
Alas, those are only the stats for the audioop test suite. audioop itself is written in C, so the automatic coverage stats generated by livinglogic don't provide any details. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 05.07.10 16:19, Nick Coghlan wrote:
On Mon, Jul 5, 2010 at 5:20 AM, Terry Reedy <tjreedy@udel.edu> wrote:
On 7/4/2010 2:31 AM, Éric Araujo wrote:
But Python tests lack coverage stats, so it is hard to say anything.
Turns out the audioop is one of the best covered modules, at 98%
Alas, those are only the stats for the audioop test suite. audioop itself is written in C, so the automatic coverage stats generated by livinglogic don't provide any details.
http://coverage.livinglogic.de/ *does* include coverage info for stuff written in C, see for example: http://coverage.livinglogic.de/Objects/unicodeobject.c.html However it *is* strange that test_audioop.py gets executed, but audioop.c doesn't seem to be. Servus, Walter
On Tue, Jul 6, 2010 at 1:10 PM, Walter Dörwald <walter@livinglogic.de> wrote:
http://coverage.livinglogic.de/ *does* include coverage info for stuff written in C, see for example:
http://coverage.livinglogic.de/Objects/unicodeobject.c.html
However it *is* strange that test_audioop.py gets executed, but audioop.c doesn't seem to be.
It looks as though none of the extension modules (besides those that are compiled statically into the interpreter) are reporting coverage. I wonder whether the correct flags are being passed to the module build stage? Incidentally, there doesn't seem to be any of the usual 'make' output I'd associate with the module-building stage in the build log at: http://coverage.livinglogic.de/buildlog.txt For example, I'd expect to see the string 'mathmodule' somewhere in that output. Mark
On 06.07.10 15:07, Mark Dickinson wrote:
On Tue, Jul 6, 2010 at 1:10 PM, Walter Dörwald <walter@livinglogic.de> wrote:
http://coverage.livinglogic.de/ *does* include coverage info for stuff written in C, see for example:
http://coverage.livinglogic.de/Objects/unicodeobject.c.html
However it *is* strange that test_audioop.py gets executed, but audioop.c doesn't seem to be.
It looks as though none of the extension modules (besides those that are compiled statically into the interpreter) are reporting coverage. I wonder whether the correct flags are being passed to the module build stage? Incidentally, there doesn't seem to be any of the usual 'make' output I'd associate with the module-building stage in the build log at:
http://coverage.livinglogic.de/buildlog.txt
For example, I'd expect to see the string 'mathmodule' somewhere in that output.
True, there seems to be a problem. I'm running ./configure --enable-unicode=ucs4 --with-pydebug and then make coverage This doesn't seem to build extension modules. However as far as I understand the Makefile, "make coverage" should build extension modules: # Default target all: build_all build_all: $(BUILDPYTHON) oldsharedmods sharedmods gdbhooks coverage: @echo "Building with support for coverage checking:" $(MAKE) clean $(MAKE) all CFLAGS="$(CFLAGS) -O0 -pg -fprofile-arcs -ftest-coverage" LIBS="$(LIBS) -lgcov" # Build the shared modules sharedmods: $(BUILDPYTHON) @case $$MAKEFLAGS in \ *s*) $(RUNSHARED) CC='$(CC)' LDSHARED='$(BLDSHARED)' LDFLAGS='$(LDFLAGS)' OPT='$(OPT)' ./$(BUILDPYTHON) -E $(srcdir)/setup.py -q build;; \ *) $(RUNSHARED) CC='$(CC)' LDSHARED='$(BLDSHARED)' LDFLAGS='$(LDFLAGS)' OPT='$(OPT)' ./$(BUILDPYTHON) -E $(srcdir)/setup.py build;; \ esac I'm rerunning now with "make && make coverage" to see if this fixes anything. Servus, Walter
On Tue, Jul 6, 2010 at 10:10 PM, Walter Dörwald <walter@livinglogic.de> wrote:
On 05.07.10 16:19, Nick Coghlan wrote: http://coverage.livinglogic.de/ *does* include coverage info for stuff written in C, see for example:
Ah, I missed that. Cool.
However it *is* strange that test_audioop.py gets executed, but audioop.c doesn't seem to be.
There do seem to be a *lot* of N/A's against the C code (that's why I thought the C code wasn't included in the stats collection in the first place). Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (10)
-
anatoly techtonik -
Antoine Pitrou -
Benjamin Peterson -
Jesse Noller -
Mark Dickinson -
Nick Coghlan -
Terry Reedy -
Victor Stinner -
Walter Dörwald -
Éric Araujo