Re: [Python-Dev] PEP 506 secrets module

2015-10-15 Thread Chris Rebert
On Thu, Oct 15, 2015 at 5:57 PM, Steven D'Aprano  wrote:
> Hi,
>
> As extensively discussed on Python-Ideas, the secrets module and PEP 506
> is (I hope) ready for pronouncement.
>
> https://www.python.org/dev/peps/pep-0506/

{{{
Comparison To Other Languages
[...]
Javascript
Based on a rather cursory search [20], there do not appear to be any
well-known standard functions for producing strong random values in
Javascript,
[...]
[20] Volunteers and patches are welcome.
}}}

Looks like client-side JS has window.crypto.getRandomValues() for this:
https://developer.mozilla.org/en-US/docs/Web/API/RandomSource/getRandomValues
Similarly, Node.js offers crypto.randomBytes():
https://nodejs.org/api/crypto.html#crypto_crypto_randombytes_size_callback

Also, it's spelled "JavaScript", not "Javascript".

Additionally, it looks like there's some kind of bold formatting error
in the answer to "Q: What about a password generator?" in the HTML
version of the PEP.

> There is code and tests here:
>
> https://bitbucket.org/sdaprano/secrets

I think there's a timing-related flaw in the current fallback
implementation of equal():
https://bitbucket.org/sdaprano/secrets/pull-requests/1

Cheers,
Chris
--
https://github.com/cvrebert
___
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/archive%40mail-archive.com


Re: [Python-Dev] WebM MIME type in mimetypes module

2014-12-03 Thread Chris Rebert
On Tue, Dec 2, 2014 at 6:16 PM, Terry Reedy tjre...@udel.edu wrote:
 On 12/2/2014 7:07 PM, Chris Rebert wrote:

 Hi all,

 I'm seeking to move http://bugs.python.org/issue16329 towards conclusion.
 Since the discussion on the issue itself seems to have petered out, I
 thought I'd bring it up here.

 To summarize the issue, it proposes adding an entry for WebM (
 http://www.webmproject.org/docs/container/#naming ) to the mimetypes
 standard library module's file-extension to MIME-type database.
 (Specifically: .webm = video/webm )
 Mozilla, Microsoft, Opera, and freedesktop.org (the de facto standard
 *nix MIME type database package) all acknowledge the existence of a
 video/webm MIME type (see the issue for relevant links), and this MIME
 type is in WebM's documentation.
 However, there is no official IANA registration for WebM's MIME type,
 and none seems to be forthcoming/planned.

 As R.D.M. said in the issue:

 So we have two choices:
 leave it to the platform mime types file to define because it is not even
 on track to be an official IANA standard,
 or include it with a comment that it is a de-facto standard.
 [...]
 I guess I'd be OK with adding it as a de-facto standard, though I'm not
 entirely comfortable with it. But that would represent a change in policy,
 so others may want to weigh in.

 Nobody has weighed in during the subsequent ~2 years, so I'm hoping a
 few of y'all could weigh in one way or the other, and thus bring the
 issue to a definitive conclusion.

 If it has remained a defacto standard for the two years since your made that
 list, that would be a point in favor of recognizing it.  Have .webm files
 become more common in actual use?

I can't really speak to that personally one way or the other, but some
researching shows it's used by YouTube and Wikimedia Commons, and the
format in general seems to continue to enjoy a reasonably good level
of support (see http://en.wikipedia.org/wiki/WebM#Vendor_support ,
http://caniuse.com/#search=webm ).

Cheers,
Chris
___
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/archive%40mail-archive.com


[Python-Dev] WebM MIME type in mimetypes module

2014-12-02 Thread Chris Rebert
Hi all,

I'm seeking to move http://bugs.python.org/issue16329 towards conclusion.
Since the discussion on the issue itself seems to have petered out, I
thought I'd bring it up here.

To summarize the issue, it proposes adding an entry for WebM (
http://www.webmproject.org/docs/container/#naming ) to the mimetypes
standard library module's file-extension to MIME-type database.
(Specifically: .webm = video/webm )
Mozilla, Microsoft, Opera, and freedesktop.org (the de facto standard
*nix MIME type database package) all acknowledge the existence of a
video/webm MIME type (see the issue for relevant links), and this MIME
type is in WebM's documentation.
However, there is no official IANA registration for WebM's MIME type,
and none seems to be forthcoming/planned.

As R.D.M. said in the issue:
 So we have two choices:
 leave it to the platform mime types file to define because it is not even on 
 track to be an official IANA standard,
 or include it with a comment that it is a de-facto standard.
[...]
 I guess I'd be OK with adding it as a de-facto standard, though I'm not 
 entirely comfortable with it. But that would represent a change in policy, so 
 others may want to weigh in.


Nobody has weighed in during the subsequent ~2 years, so I'm hoping a
few of y'all could weigh in one way or the other, and thus bring the
issue to a definitive conclusion.

Cheers,
Chris
--
https://github.com/cvrebert
___
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/archive%40mail-archive.com


Re: [Python-Dev] Putting the Mac Build in the Apple App Store

2013-06-04 Thread Chris Rebert
On Jun 3, 2013 9:45 PM, Raymond Hettinger raymond.hettin...@gmail.com
wrote:

 Does anyone know what we would need to do to get Python in the Apple
application store as a free App?

 The default security settings on OS X 10.8 block the installation of the
DMG (or any software downloaded outside the app store).   A number of my
students are having difficulty getting around it will help.

 If we were in the app store, installation and upgrade would be a piece of
cake.

If you need another option, you could try installing Python via Homebrew (
http://brew.sh ). Homebrew itself is also easy to install.
(Although admittedly I haven't tried Homebrew's Python, but my experience
with their other packages has been good.)

Cheers,
Chris
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Validating SSL By Default (aka Including a Cert Bundle in CPython)

2013-06-02 Thread Chris Rebert
On Jun 2, 2013 10:22 PM, Donald Stufft don...@stufft.io wrote:

 As of right now, as far as I can tell, Python does not validate HTTPS 
 certificates by default. As far as I can tell this is because there is no 
 guaranteed certificates available.

Relevant: http://bugs.python.org/issue13647

 So I would like to propose that CPython adopt the Mozilla SSL certificate 
 list and include it in core, and switch over the API's so that they verify 
 HTTPS by default. This is what most people are going to expect when using a 
 https url (Especially after learning that Python 2.x doesn't verify TLS, but 
 Python 3.x does).

 Ideally this would take the shape of attempting to locate the system 
 certificate store if possible, and if that doesn't work falling back to the 
 bundled certificates. That way the various Linux distros can easily have 
 their copies of Python depend solely on their built in certs, but Windows, 
 OSX, Source compiles etc will all still have a fallback value.

There's an existing request for this:
http://bugs.python.org/issue13655

Cheers,
Chris
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] marking os.system() as deprecated in the docs

2010-07-26 Thread Chris Rebert
Hello,

I'd like to propose formally marking os.system() as deprecated in the
docs for next release of Python (v3.2 ?).

The docs for os.system() /already/ include the following paragraph,
which is basically tantamount to calling system() deprecated and very
much resembles the deprecation notes for the os.popen*() family.

The subprocess module provides more powerful facilities for spawning
new processes and retrieving their results; using that module is
preferable to using this function. Use the subprocess module. Check
especially the Replacing Older Functions with the subprocess Module
section.


I'm merely suggesting slapping a formal .. deprecated:: tag  box
around this paragraph to make system()'s status more obvious. I am
***not*** suggesting the function be scheduled for removal or anything
like that.

I figure since this would be a substantive change (the docs currently
don't outright say deprecated), it would need dev approval, hence
this message. I've already written the absolutely /trivial/ docs
patch.

So, any objections?

Cheers,
Chris
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] marking os.system() as deprecated in the docs

2010-07-26 Thread Chris Rebert
 On Sun, Jul 25, 2010 at 11:42 PM, Chris Rebert py...@rebertia.com wrote:
 Hello,

 I'd like to propose formally marking os.system() as deprecated in the
 docs for next release of Python (v3.2 ?).

 The docs for os.system() /already/ include the following paragraph,
 which is basically tantamount to calling system() deprecated and very
 much resembles the deprecation notes for the os.popen*() family.
 
 The subprocess module provides more powerful facilities for spawning
 new processes and retrieving their results; using that module is
 preferable to using this function. Use the subprocess module. Check
 especially the Replacing Older Functions with the subprocess Module
 section.
 

Emphasizing the following paragraph from my original email:

 I'm merely suggesting slapping a formal .. deprecated:: tag  box
 around this paragraph to make system()'s status more obvious. I am
 ***not*** suggesting the function be scheduled for removal or anything
 like that.

 I figure since this would be a substantive change (the docs currently
 don't outright say deprecated), it would need dev approval, hence
 this message. I've already written the absolutely /trivial/ docs
 patch.

 So, any objections?

On Mon, Jul 26, 2010 at 7:29 AM, Guido van Rossum gu...@python.org wrote:
 Unless, it's as simple as replacing os.system(x) with
 subprocess.system(x), I'm against this removal of a handy shorthand.

[Addressing Steven's reply as well]

In hindsight, I should have used a word other than deprecate
(despite no longer matching the Sphinx directive) that's not
overloaded with Python baggage about removal; I intended it here in
its plain English meaning of merely to express disapproval of or to
play down.

Allow me to reiterate: I am *NOT* suggesting os.system() be removed or
prepared for removal. I'm only suggesting the docs be /slightly/
tweaked to make it /slightly/ more obvious that os.system() is
dispreferred over the subprocess module. Removing os.system() would
have backward compatibility and cross-language API problems; I agree
it would be a bad idea; which is why I'm not proposing that.

 Ditto for popen.

Funny you should bring up os.popen(). Its docs are currently MIA in
3.x, for unclear reasons:
http://bugs.python.org/issue9382

Cheers,
Chris

 --
 --Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Mail Archives

2010-02-02 Thread Chris Rebert
On Tue, Feb 2, 2010 at 1:50 AM,  ben.yo...@sungard.com wrote:
 Hi,

 Currently the Python-Dev archives at
 http://mail.python.org/pipermail/python-dev/ doesn't appear to have been
 updated for the last week or so. Is that a known issue?

I think so: http://mail.python.org/pipermail/python-dev/2010-January/097388.htm

Cheers,
Chris
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] subprocess docs patch

2010-02-01 Thread Chris Rebert
On Mon, Feb 1, 2010 at 12:14 AM, Martin v. Löwis mar...@v.loewis.de wrote:
 Any help you could provide would be appreciated.

 Please use unified diffs in the future.

Duly noted.

 I'm -0 on this patch; it still has the negative, cautionary-patronizing
 tone (Do not, can be tricky, be mindful),

Thanks to yours and other feedback, I've tried to address this in a
newer version of the patch.

 as if readers are unable
 to grasp the description that they just read (and indeed, in the patch,
 you claim that readers *are* unable to understand how command lines
 work).

I don't think I made any statement quite that blunt; however, as the
c.l.p threads that drove me to write this patch show, there are indeed
some people who don't (correctly) understand the details of command
line tokenization.

Thanks for responding!

Cheers,
Chris
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] subprocess docs patch

2010-01-31 Thread Chris Rebert
Hello mighty Python developers,

I was wondering if someone could take a gander at, and hopefully act
upon, a patch I submitted a while ago for the subprocess module's
docs.
It's been languishing in the bug tracker:

http://bugs.python.org/issue6760

Any help you could provide would be appreciated.

Cheers,
Chris
--
If life seems jolly rotten. There's something you've forgotten.
And that's to laugh and smile and dance and sing.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com