[issue36489] add filename_extension_map and/or content-types_map dict(s) to mimetypes

2019-04-03 Thread Daniel Black


Daniel Black  added the comment:

Thanks Karthikeyan. That is a bit cumbersome but gets it done. Any value seen 
in adding as proposed?

--

___
Python tracker 
<https://bugs.python.org/issue36489>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue36489] add filename_extension_map and/or content-types_map dict(s) to mimetypes

2019-03-30 Thread Daniel Black


New submission from Daniel Black :

In https://bugs.python.org/issue36460 (which should be probably be disregarded 
until AMP is in RFC) I discovered that the types_map dictionary within the 
mimetypes module is a key: str to key: str (1:1) relationship. The reality is 
that many filename extensions commonly support multiple content-types and even 
sub types. A more useful structure might look like:

(fne is "file name extension" aka foo)

{
  '.fne': ['type1/subtype', 'type2/subtype'],
  '.htm': ['text/html', 'text/css', 'text/javascript'],
  '.html': ['text/html', 'text/css', 'text/javascript']
} 

However this seems to compete with the functionality of the types map so 
another consideration is content-types_map where the content-type is the key 
and the pair values are lists of valid filename extensions:

{
  'audio/x-aiff': ['.aifc', '.aiff', '.au'],
  'text/html': ['.html', '.htm']
}

--
messages: 339221
nosy: Daniel Black
priority: normal
severity: normal
status: open
title: add filename_extension_map and/or content-types_map dict(s) to mimetypes

___
Python tracker 
<https://bugs.python.org/issue36489>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue36460] Add AMP MIME type support

2019-03-28 Thread Daniel Black


Daniel Black  added the comment:

That's exactly what I meant: use, but in a way that cares how that data is
structured. Thanks for the pointer, I'll take a look.

--

___
Python tracker 
<https://bugs.python.org/issue36460>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue36460] Add AMP MIME type support

2019-03-28 Thread Daniel Black


Daniel Black  added the comment:

I see! Okay... I'll consider a solution to the filetype portion of the
mimetypes map. Do you happen to know which other modules may depend on that
structure?

Yes... the lightning is silly.

Dan Black
http://dan.black
917-873-3970

On Thu, Mar 28, 2019 at 10:55 AM R. David Murray 
wrote:

>
> R. David Murray  added the comment:
>
> That link should do for our purposes here.
>
> The fact that it is an 'x-' mimetype means it has not been approved at
> any level.  There might be an in progress application to the mimetype
> registry, but if so the web site doesn't mention it anywhere obvious.
>
> I'm not sure about the filetype problem, but I'm guessing amp isn't the
> only mimetype that will have this issue going forward, so we probably need
> to come up with a solution.  You don't need support from the mimetypes
> module to create or manipulate emails using the content-type, though,
> so it isn't a blocker on that side.
>
> That lightning thing is *seriously* hokey :(
>
> --
>
> ___
> Python tracker 
> <https://bugs.python.org/issue36460>
> ___
>

--

___
Python tracker 
<https://bugs.python.org/issue36460>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue36460] Add AMP MIME type support

2019-03-28 Thread Daniel Black


Daniel Black  added the comment:

I'm not sure there's an RFC. I searched ietf but found none related to AMP
in MIME and AMP along search results were many (not accurate). I actually
doubt there's an RFC specific to AMP. What I meant is that AMP is itself
RFC compliant with RFC 2045-2050. As for official documentation here is the
link to the AMP project's description which gives some context:
https://amp.dev/documentation/guides-and-tutorials/integrate/add-email.html?format=email

Let me know if you need more information.

Dan Black
http://dan.black
917-873-3970

On Thu, Mar 28, 2019 at 8:41 AM R. David Murray 
wrote:

>
> R. David Murray  added the comment:
>
> Can you provide some links to relevant RFCs or other official documents?
>
> --
>
> ___
> Python tracker 
> <https://bugs.python.org/issue36460>
> ___
>

--

___
Python tracker 
<https://bugs.python.org/issue36460>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue21207] urandom persistent fd - not re-openned after fd close

2014-04-22 Thread Daniel Black

Daniel Black added the comment:

maybe you've thought and dismissed this already but os.close could call 
dev_urandom_close for the urandom_fd. Then there's no fstat calls in every 
random access. As a sweeping close all isn't going to occur that often and 
extra open probably isn't that much overhead.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21207
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue21207] urandom persistent fd - not re-openned after fd close

2014-04-22 Thread Daniel Black

Daniel Black added the comment:

fine by me. was just a thought

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21207
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue21207] urandom persistent fd - not re-openned after fd close

2014-04-16 Thread Daniel Black

Changes by Daniel Black daniel.s...@internode.on.net:


--
nosy: +grooverdan

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21207
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8109] Server-side support for TLS Server Name Indication extension

2013-04-10 Thread Daniel Black

Daniel Black added the comment:

nice patch. Thanks for finding the bug. I like the solution with test case.

Just needs a small enhancement of documention to ensure other users expect this 
behaviour.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8109
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue17510] assertEquals deprecated in test_program.py (unittest)

2013-03-21 Thread Daniel Black

New submission from Daniel Black:

Following #9424 here's a patch that changes assertEquals - assertEqual for 
Lib/unittest/test/test_program.py

against hg tip as of now

--
components: Tests
files: unittest.patch
keywords: patch
messages: 184906
nosy: grooverdan
priority: normal
severity: normal
status: open
title: assertEquals deprecated in test_program.py (unittest)
type: enhancement
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file29533/unittest.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17510
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue17181] SSLContext.set_servername_callback should be able to set argument

2013-02-11 Thread Daniel Black

New submission from Daniel Black:

I think my original implementation of the SNI callback to see a original 
sslcontext was wrong. It would be much more useful for the 
SSLContext.set_servername_callback to take a callable and an object as an 
argument.

This would allow constructs like the following where self can be used within 
the callback. Example:

def cb_sni(ssl_sock, server_name, self):
self.sniname = server_name

self.context.set_servername_callback(cb_sni, self)

The original functionality can still occur with:

self.context.set_servername_callback(cb_sni, self.context)

Agree?

--
components: Library (Lib)
messages: 181889
nosy: grooverdan, pitrou
priority: normal
severity: normal
status: open
title: SSLContext.set_servername_callback should be able to set argument
type: enhancement
versions: Python 3.5

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17181
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue10852] SSL/TLS sni use in smtp, pop, imap, nntp, ftp client libs by default

2013-02-11 Thread Daniel Black

Daniel Black added the comment:

Ack. Have fix. Simple if self.certfile or self.keyfile: test added before 
load_cert_chain.

part way through developing test. Thinking #17181 would help.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10852
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue17107] test_sni in test_urllib2net could be enabled

2013-02-03 Thread Daniel Black

Daniel Black added the comment:

ask and you shall receive :-)

--
keywords: +patch
nosy: +grooverdan
versions: +Python 3.5
Added file: http://bugs.python.org/file28948/https_sni_test.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17107
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue10852] SSL/TLS sni use in smtp, pop, imap, nntp, ftp client libs by default

2011-01-24 Thread Daniel Black

Daniel Black daniel.s...@internode.on.net added the comment:

ok. should library/ssl.rst be updated to use a SSLContext example?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10852
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue10852] SSL/TLS sni use in smtp, pop, imap, nntp, ftp client libs by default

2011-01-24 Thread Daniel Black

Daniel Black daniel.s...@internode.on.net added the comment:

I thought previous comments you wanted SSLContext to become the primary api 
rather than wrap_socket? Coding this into the examples is probably a good way 
of making this happen.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10852
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue10851] further extend ssl SNI and ciphers API

2011-01-07 Thread Daniel Black

Daniel Black daniel.s...@internode.on.net added the comment:

acknowledged. Makes sense.

--
resolution:  - rejected
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10851
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2973] _ssl compiler warnings

2011-01-06 Thread Daniel Black

Daniel Black dan...@cacert.org added the comment:

out of date?

still occurs on:
AMD64 Leopard 2.7: http://www.python.org/dev/buildbot/all/builders/AMD64 
Leopard 2.7/builds/308/steps/compile/logs/warnings (57)
PPC Leopard 2.7: http://www.python.org/dev/buildbot/all/builders/PPC Leopard 
2.7/builds/532/steps/compile/logs/warnings (20)
PPC Tiger 2.7: http://www.python.org/dev/buildbot/all/builders/PPC Tiger 
2.7/builds/532/steps/compile/logs/warnings (25)

PPC Leopard 3.1: http://www.python.org/dev/buildbot/all/builders/PPC Leopard 
3.1/builds/674/steps/compile/logs/warnings (20)
x86 gentoo 3.1 : http://www.python.org/dev/buildbot/all/builders/x86 gentoo 
3.1/builds/1412/steps/compile/logs/warnings (8)
x86 FreeBSD 3.1: http://www.python.org/dev/buildbot/all/builders/x86 FreeBSD 
3.1/builds/719/steps/compile/logs/warnings (7)
3.1.dmg: 
http://www.python.org/dev/buildbot/all/builders/3.1.dmg/builds/339/steps/compile/logs/warnings
 (20)

btw I don't think the gentoo ones are accurate - old versions of openssl have 
been gone for a while:
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/openssl/openssl-0.9.7m.ebuild?hideattic=0view=log

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2973
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue10851] further extend ssl SNI and ciphers API

2011-01-06 Thread Daniel Black

New submission from Daniel Black daniel.s...@internode.on.net:

as a further extension to issue #5639 (sni) and issue #8322 this patch provides 
the ability to set ciphers in the  SSLContext.wrap_socket and server_hostname 
in ssl.wrap_socket. This just makes all the ssl apis look the same. 
Restructured the documentation associated with these functions to all be around 
the wrap_socket method.

--
components: Library (Lib)
files: p3k-sni-ciphers.patch
keywords: patch
messages: 125612
nosy: grooverdan, pitrou
priority: normal
severity: normal
status: open
title: further extend ssl SNI and ciphers API
versions: Python 3.3
Added file: http://bugs.python.org/file20296/p3k-sni-ciphers.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10851
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8109] Support for TLS Server Name Indication extension

2011-01-06 Thread Daniel Black

Daniel Black daniel.s...@internode.on.net added the comment:

issue #5639 only has functionality for client side SNI. Server side SNI is 
still missing.

For server side SNI to be supported a server program should be able to retrieve 
the server name provided by the client call and alter the server 
certificate/key before the server completes the TLS/SSL connection.

--
nosy: +grooverdan

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8109
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue10852] SSL/TLS sni use in smtp, pop, imap, nntp, ftp client libs by default

2011-01-06 Thread Daniel Black

New submission from Daniel Black daniel.s...@internode.on.net:

Like r85793, sni is enabled by default for url and https classes. This 
continues the consistency throughout the python libraries by adding it to other 
places where wrap_socket is used to instigate a SSL/TLS connection.

--
components: Library (Lib)
files: sni-pop-smtp-imap-nntp.patch
keywords: patch
messages: 125621
nosy: grooverdan, pitrou
priority: normal
severity: normal
status: open
title: SSL/TLS sni use in smtp,pop,imap,nntp,ftp client libs by default
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file20299/sni-pop-smtp-imap-nntp.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10852
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue10853] SSL/TLS sni use in smtp, pop, imap, nntp, ftp client libs by default

2011-01-06 Thread Daniel Black

New submission from Daniel Black daniel.s...@internode.on.net:

Like r85793, sni is enabled by default for url and https classes. This 
continues the consistency throughout the python libraries by adding it to other 
places where wrap_socket is used to instigate a SSL/TLS connection.

--
components: Library (Lib)
files: sni-pop-smtp-imap-nntp.patch
keywords: patch
messages: 125622
nosy: grooverdan, pitrou
priority: normal
severity: normal
status: open
title: SSL/TLS sni use in smtp,pop,imap,nntp,ftp client libs by default
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file20300/sni-pop-smtp-imap-nntp.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10853
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue10852] SSL/TLS sni use in smtp, pop, imap, nntp, ftp client libs by default

2011-01-06 Thread Daniel Black

Daniel Black daniel.s...@internode.on.net added the comment:

dup #10853

--
nosy:  -pitrou
resolution:  - duplicate
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10852
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5639] Support TLS SNI extension in ssl module

2010-05-23 Thread Daniel Black

Daniel Black dan...@cacert.org added the comment:

 msg106323 - Author: Antoine Pitrou (pitrou) Date: 2010-05-22 20:17

I quite like your proposed alternative here. Not sure when/if I'll get to 
implement this.

 msg106324  - Author: Jean-Paul Calderone (exarkun) Date: 2010-05-22 22:17
Sorry I don't like this as much. I believe following the RFC for TLS SNI should 
be implicit and not something the programmer need to put effort into achieving. 
I acknowledge this approach does go against some explicit behaviour programming 
quality metrics.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5639
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5639] Support TLS SNI extension in ssl module

2009-09-04 Thread Daniel Black

Daniel Black dan...@cacert.org added the comment:

Hey Phil,
 (Sorry for dropping this, lost available time)
know the feeling :-(

 use of SNI needs to be something that can be disabled
maybe. See small rational below:

 and people need to be able to connect to host A while supplying host B
This seems to be a fringe case for usage and I seem to thing adding this
would overly complicate the API. When testing hosts you would have all
the names in DNS I'd assume.

 Unless s.connect() gains a keep_original_hostname=False option (?),
this is hard to do.
Is this starting to look too complicated?

Options for client side SNI:
1. wrapssl() - defaults to SNI enabled on SSL2/TLS1 connections (compile
time/module level/object variable disable if really needed?)
2. wrapssl(server_hostname=True/False) - enable SNI using the connect
hostname (if domainname and not IP/socket)
3. wrapssl(server_hostname=True/False/String) - True - enable SNI as
above, False/None- don't use SNI or use hostname if a String.
4. wrapssl(server-hostname=String)
5. connect() should an override_server_hostname=False
more?

 Then there's the principle of least surprise -- while it would be nice
to get SNI working automatically for everyone, it's still plausible that
amongst the various TLS servers out there are some which break horribly
for SNI and upgrading Python shouldn't break the tools in use.

Small rational to enable SNI by default:
1. SNI probably won't break too much stuff.
It was only in July 2009 that Apache-2.2.12 got officially released with
proper SNI support. Patches existed before then however deployment was
limited. mod_gnutls did implemented this earlier however I never thought
this was widely used.
Vista IE7 got SNI support in ~2005
(http://blogs.msdn.com/ie/archive/2005/10/22/483795.aspx)
FF got SNI support in the 2.0 release (October 24, 2006, wikipedia) 
(https://bugzilla.mozilla.org/show_bug.cgi?id=116169#c26)
The OpenSSL server side API for SNI required the registration of a
callback to receive the SNI name. It is possible that there are some
faulty implementations in this part of the server code. The default case
that a TLS server doesn't account for SNI is very safe as it won't ever
get a callback for it.
The existence of wide spread client side support with limited server
support hasn't broken the web.

 So I tend towards favouring make use of the newer, less well tested, 
protocol feature something that has to be explicitly enabled, even if 
it adds a line to boilerplate -- if SNI ever takes over the world (as 
Host: headers in HTTP have) then it can be defaulted on in future 
perhaps?

2. I think with p3k there is an opportunity to put something in that may
break stuff. The release noted didn't guarantee stuff would work compatibly.

3. supporting SNI clients by default may actually break less stuff that
not supporting SNI client. e.g. Webhosting companies may embrace the SNI
features of Apache for maximum IP utilization breaking the non-SNI aware
clients (which won't be the majority of web browsers).

 With checking for an IP address?
To be RFC compliant IP addresses shouldn't be used in SNI. Apart from
socket family checking (AF_INET/AF_INET6) and doing a regex on the name
I couldn't see an easy way to do this even looking at the low level
socketmodule.c file. Maybe I need to look deeper. I could cheat and look
at the Firefox crypto (NSS) code though.

just my current thoughts

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5639
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6814] xrange removal from documentation

2009-09-01 Thread Daniel Black

New submission from Daniel Black dan...@cacert.org:

xrange still exists in bits of documentation here and there.

patch fixes it.

--
assignee: georg.brandl
components: Documentation
files: xrange-doco.patch
keywords: patch
messages: 92120
nosy: georg.brandl, grooverdan
severity: normal
status: open
title: xrange removal from documentation
versions: Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14813/xrange-doco.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6814
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5885] uuid.uuid1() is too slow

2009-09-01 Thread Daniel Black

Daniel Black dan...@cacert.org added the comment:

This is a slightly crude module version. The speedups were only 10%

Python 3.2a0 (py3k:74612M, Sep  1 2009, 18:11:58)   
[GCC 4.3.2] on linux2  

Using the same test from Wang Chun:
before:
uuid1(100)
101.759 microseconds

after:
uuid1(100)
91.663 microseconds

The delays are clearly in the _byte array copying as indicated by the
test below:
 import sys, time, uuid
 def uu(n):
...  t = time.time()
...  for x in range(n):
... uuid._uuid_generate_time_fast()
...  print('%.3f microseconds' % ((time.time() - t) * 100.0 / n))
...
[72265 refs]
 uu(100)
13.157 microseconds
[72267 refs]

I would expect fixing this for the ctypes version would have a similar
speedup.

--
keywords: +patch
nosy: +grooverdan
Added file: http://bugs.python.org/file14814/uuid_c_module.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5885
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5885] uuid.uuid1() is too slow

2009-09-01 Thread Daniel Black

Daniel Black dan...@cacert.org added the comment:

to prove it a bit more - ctype benchmark
 import ctypes, ctypes.util
 def uu1(n):
...  t = time.time()
...  _buffer = ctypes.create_string_buffer(16)
...  for x in range(n):
... uuid._uuid_generate_time(_buffer)
...  print('%.3f microseconds' % ((time.time() - t) * 100.0 / n))
...
 uu1(100)
15.819 microseconds

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5885
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5639] Support TLS SNI extension in ssl module

2009-08-31 Thread Daniel Black

Daniel Black dan...@cacert.org added the comment:

The small deficiency with these patches is that the specified
server_hostname is almost always the hostname that is used in the socket
pair of connect. Is it appropriate to grab the hostname value and use it
in the SNI extension header?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5639
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2973] _ssl compiler warnings

2009-08-31 Thread Daniel Black

Daniel Black dan...@cacert.org added the comment:

The changeset that changed the definitions is here:
http://cvs.openssl.org/chngview?cn=12024 (2004-Mar-14 23:15:13 (UTC))

As you can see there is no easy identifier in the changeset (i'm not
sure how portable an ifdef on a typedef is (possible
asn1_const_ctx_st/ASN1_const_CTX)).

The patch i've done goes of then next OPENSSL_VERSION_NUMBER change
which occurred here
http://cvs.openssl.org/filediff?f=openssl/crypto/opensslv.hv1=1.36.2.35v2=1.36.2.36
(2004/03/17 11:40:44) ~3 days later.

Same patch applies to p3k

--
keywords: +patch
nosy: +grooverdan
versions: +Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: 
http://bugs.python.org/file14811/issue2973-D2I_PARAMETER_2_TYPE.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2973
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3212] ssl module - should test for a wrong cert

2009-08-31 Thread Daniel Black

Daniel Black dan...@cacert.org added the comment:

Is fixed in p3k Mon Sep 8 16:45:19 2008 UTC
http://svn.python.org/view/python/branches/py3k/Lib/test/test_ssl.py?r1=65837r2=66311

--
nosy: +grooverdan
versions: +Python 3.1, Python 3.2

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3212
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6813] update format() documentation and tutorial

2009-08-31 Thread Daniel Black

New submission from Daniel Black dan...@cacert.org:

Release notes show the use of '{}'.format('this') and the attached patch
updates this to be the default example in the tutorial. Library
references are updated to show field_name as optional and a few examples
are added.

Relates to the improvements from issue 5237.

--
assignee: georg.brandl
components: Documentation
files: documentation-str-format.patch
keywords: patch
messages: 92119
nosy: georg.brandl, grooverdan
severity: normal
status: open
title: update format() documentation and tutorial
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14812/documentation-str-format.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6813
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5639] Support TLS SNI extension in ssl module

2009-08-30 Thread Daniel Black

Daniel Black dan...@cacert.org added the comment:

patch against TRUNK (2.7) with self tests and doco. Essentially the same
code as pdp with a SSLv2 check before using the SNI extension.

Contains some spacing cleanups that where highlighted by vim.

--
nosy: +grooverdan
Added file: 
http://bugs.python.org/file14808/python-HEAD-74602-ssl_client_sni.path

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5639
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5639] Support TLS SNI extension in ssl module

2009-08-30 Thread Daniel Black

Daniel Black dan...@cacert.org added the comment:

py3k version

--
Added file: http://bugs.python.org/file14809/python-3K-74602-ssl_client_sni.path

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5639
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5639] Support TLS SNI extension in ssl module

2009-08-30 Thread Daniel Black

Changes by Daniel Black dan...@cacert.org:


--
versions: +Python 2.7, Python 3.2 -Python 2.6

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5639
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5639] Support TLS SNI extension in ssl module

2009-08-30 Thread Daniel Black

Daniel Black dan...@cacert.org added the comment:

current self tests cannot fully test the existence of the SNI extension
as there is no server side support.

This client script run with argument sni.velox.ch will show the Great!
Your client its ClientHello: sni.velox.ch on the output.

--
nosy: +janssen
type:  - feature request
Added file: http://bugs.python.org/file14810/pytest.py

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5639
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com