On 11.03.2014 13:18, Victor Stinner wrote:

Hi,

Thanks David! I added a summary of security improvements: http://docs.python.org/dev/whatsnew/3.4.html#summary-release-highlights

Can someone please review it? Don't hesitate to modify the text directly. Check also if the summary is complete.

Thanks a lot David and Victor! The list of security improvements is missing one, maybe two points that are IMHO relevant: * All stdlib modules now support server cert verification including hostname matching and CRL. * http://bugs.python.org/issue16499 isolated mode is a security improvement, too. Should the section or Whats New in general mention that Python builds without compiler warnings on most platforms and that we aim for zero warnings on all supported platforms and compilers? And there is the point with Coverity Scan. We have reached zero defects about half a year ago and fixed all new defects in a matter of days. I'll try to keep the defect rate down to zero in the future, too. The tool has helped me to identify a bunch of security-relevant issues like buffer overflows, invalid casts and more. It's something worth mentioning. But I don't want it to sound like an advert... Suggestions? Christian

Am 13.03.2014 12:34, schrieb Stephen J. Turnbull:

Christian Heimes writes:

...

But I don't want it to sound like an advert... Suggestions?

Not to worry. It *can't* be an advert -- it's all true, and there are no irrelevant half-naked glistening bodies. (Former newts in the pond don't count.)

Seriously, while "expect a clean build" is not "news" for Python, it's useful to state that we're at zero warnings nearly across the board, including Coverity. Accompanied by an open invitation for reports to the contrary, that's hardly like a commercial.

I think Chris meant he'd sound like an ad for Coverity. Georg

On 3/13/2014 7:34 AM, Stephen J. Turnbull wrote:

Christian Heimes writes:

...

But I don't want it to sound like an advert... Suggestions?

Not to worry. It *can't* be an advert -- it's all true, and there are no irrelevant half-naked glistening bodies. (Former newts in the pond don't count.)

Seriously, while "expect a clean build" is not "news" for Python,

It is for a Windows repository build. I just rebuilt: 3.3 gives lots of warning from multiple files; 3.4 none.

Accompanied by an open invitation for reports to the contrary, that's hardly like a commercial.

Now that no warnings is a serious goal for 3.4+, I will report them should they recur. -- Terry Jan Reedy

14.03.14 07:59, Brian Curtin написав(ла):

On Thu, Mar 13, 2014 at 8:29 PM, Terry Reedy wrote:

...

Now that no warnings is a serious goal for 3.4+, I will report them should they recur.

If we're at no warnings, and no warnings is a serious goal, warnings should be errors.

Sources still are not C89-clean and gcc -std=c89 emits warnings/errors.

Le 13/03/2014 11:49, Christian Heimes a écrit :

Thanks a lot David and Victor! The list of security improvements is missing one, maybe two points that are IMHO relevant:

* All stdlib modules now support server cert verification including hostname matching and CRL.

CRL? really? I don't remember us doing automatic CRL downloads.

And there is the point with Coverity Scan. We have reached zero defects about half a year ago and fixed all new defects in a matter of days. I'll try to keep the defect rate down to zero in the future, too. The tool has helped me to identify a bunch of security-relevant issues like buffer overflows, invalid casts and more. It's something worth mentioning. But I don't want it to sound like an advert... Suggestions?

I don't think it should be mentioned at all. General code quality improvements are a given in any release, the fact that the issues were detected by Coverity rather than human scrutiny is a non-information (except as advertising for Coverity). Regards Antoine.

On Thu, 13 Mar 2014 14:57:41 +0100 Victor Stinner wrote:

2014-03-13 11:49 GMT+01:00 Christian Heimes :

...

* All stdlib modules now support server cert verification including hostname matching and CRL.

* http://bugs.python.org/issue16499 isolated mode is a security improvement, too.

Ok, I added these two items.

Antoine wrote:

...

CRL? really? I don't remember us doing automatic CRL downloads.

It's just the "support", nothing is automatic. I understood that you *can* load CRL and ask for CRL validation, but it must be done explicitly. There is a function to retrieve system CRLs on Windows.

Then you should perhaps make your phrasing more explicit, because people may wrongly assume that CRL checking will be done automatically (IMHO). (especially since hostname checking, AFAIK, *is* automatic now) Regards Antoine.

On Thu, 13 Mar 2014 15:23:14 -0500, "Andrew M. Hettinger" wrote:

...

On Thu, 13 Mar 2014 14:57:41 +0100 Victor Stinner wrote:

...

2014-03-13 11:49 GMT+01:00 Christian Heimes :

...

* All stdlib modules now support server cert verification including hostname matching and CRL.

* http://bugs.python.org/issue16499 isolated mode is a security improvement, too.

Ok, I added these two items.

Antoine wrote:

...

CRL? really? I don't remember us doing automatic CRL downloads.

It's just the "support", nothing is automatic. I understood that you *can* load CRL and ask for CRL validation, but it must be done explicitly. There is a function to retrieve system CRLs on Windows.

Then you should perhaps make your phrasing more explicit, because people may wrongly assume that CRL checking will be done automatically (IMHO).

(especially since hostname checking, AFAIK, *is* automatic now) Sorry if I'm out of line on my first post to this list, but I've been using

Antoine Pitrou wrote on 03/13/2014 01:46:12 PM: the ssl module in 3.4 some lately (indeed, I have an open RFE on it for 3.5).

While hostname checking can be done automatically, it's not the default (and if it will even work at all depends on the version of openssl installed). I suppose I could see it changed to read:

* All stdlib modules now support server cert verification including hostname matching and CRL verification (but not automatic download).

Of course, the reality is, using the ssl module requires a vary careful attention to detail, and probably always will. If a programmer is just going by the "What's New" section for security related code, I'm not sure there's much you can to to save them. ;p

I opened issue 20913 to request that some sort of "best practices" documentation be added either to the SSL docs or as a separate chapter in the library reference. I do not feel competent to adjust the content of the security entries in whatsnew, so I have not. If someone wants to propose a patch or make an edit before Larry copies the files, please feel free. --David

2014-03-11 13:28 GMT+01:00 Nick Coghlan :

I was thinking of adding a new "Migrating from Python 2" section at the end of the porting guide, noting the changed recommendations in the migration guide (i.e. people that read it a while ago should read it again), as well as the restoration of the binary and text transform codec aliases. Sound reasonable?

Such info is useful, but I don't think that the What's New in Python 3.4 document is the right place. Or maybe add a link to another document. Victor

On 12 Mar 2014 02:21, "Eric V. Smith" wrote:

On 3/11/2014 9:05 AM, Victor Stinner wrote:

...

2014-03-11 13:28 GMT+01:00 Nick Coghlan :

...

I was thinking of adding a new "Migrating from Python 2" section at the end of the porting guide, noting the changed recommendations in the migration guide (i.e. people that read it a while ago should read it again), as well as the restoration of the binary and text transform codec aliases. Sound reasonable?

Such info is useful, but I don't think that the What's New in Python 3.4 document is the right place. Or maybe add a link to another document.

I think if the guidance has changed over time, then mentioning it in a What's New document, with a pointer to other documentation, is reasonable.

Yeah, that's what I meant - Brett already updated the guide, this would just be a pointer to that. I'll commit something tonight. Cheers, Nick.

Eric.

_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com