[issue17305] IDNA2008 encoding is missing
Derek Wilson added the comment: why the downgrade from security to enhancement and critical to high? this is a significant issue that can impact everything from phishing to TLS certificate domain validation and SNI. -- ___ Python tracker <https://bugs.python.org/issue17305> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31116] base85 z85 variant encoding
Derek Wilson added the comment:
z85 avoids all of:
` \ " ' _ , ;
Backtick and semicolon increase the number of places that z85 can be used
without issue over b85. All of these might not be as big an issue in python
as in other tools/languages but interoperability would still be improved
through the addition of z85.
- Derek
On Fri, Feb 14, 2020, 09:18 Dobatymo wrote:
>
> Dobatymo added the comment:
>
> base64.b85encode does not use ", ' or \ as well.
>
> That's the _b85alphabet
>
> _b85alphabet = (b"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ"
> b"abcdefghijklmnopqrstuvwxyz!#$%&()*+-;<=>?@^_`{|}~")
>
> --
> nosy: +Dobatymo
>
> ___
> Python tracker
> <https://bugs.python.org/issue31116>
> ___
>
--
___
Python tracker
<https://bugs.python.org/issue31116>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31116] base85 z85 variant encoding
New submission from Derek Wilson: Issue #17618 introduced base85 options into the base64 module including b85 and a85/adobe variants. There has since been introduced a variant that is easier to work with specifically as it avoids " ' \ characters which avoids quoting/escaping issues when working with base85 literals in python, json, xml, etc. https://rfc.zeromq.org/spec:32/Z85/ there is a reference implementation in c for which an extension could easily be built. alternately it would be very easy to add a _z85alphabet etc. to the base64 module to mirror what has been done with a/b85. 1) is there any interest in this being in the language 2) if so do we want python impl or c extension around ref impl? -- components: Library (Lib) messages: 299724 nosy: underrun priority: normal severity: normal status: open title: base85 z85 variant encoding type: enhancement versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31116> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3982] support .format for bytes
Derek Wilson added the comment: Gregory - I'm glad that you're willing to consider this again. It still is a constant issue for me, and .format with variable width fields in binary protocols is so the right tool for the job. If there is anything I can do to help get this added to 3.6 let me know. The forward/backward compatibility issue is secondary to me to the flexibility gained from having .format available for bytes. Also padding with null bytes that don't get converted would be awesome. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue3982> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18689] add argument for formatter to logging.Handler and subclasses in logging module
Derek Wilson added the comment: > It's not an ideal world. Sorry, but I think this change is too invasive to > consider. Obviously its not ideal, which is why my suggestion doesn't require intelligent 3rd party libraries and is explicitly not invasive. As I said in my previous comment, using a keyword only argument means: "If [3rd party libraries] haven't [properly handled **kwargs] then nothing changes for them and they just support exactly the same features they supported previously." The upshot is it is not invasive and no one needs to care unless they want to use the new functionality. As far as this change being needed or not, nothing "needs" to be made easier to use if it is possible to use it. But that isn't really a good reason not to improve things. I honestly think that part of the reason this hasn't come up is because the advanced features of logging are so difficult to use that people just don't use it to its fullest extent. On top of that, when learning python, logging is way harder to grok than it should be for someone new to python. Logging and unittest are two of the most important libraries for new pythonistas to learn, but they are also some of the most nebulous, stateful, magical, java-like, complicated, verbose, and difficult to master packages in python. They've been around for a while for sure - but doesn't that rather mean that they could use an update? I'm willing to submit a patch if it has the smallest chance of being considered? -- versions: +Python 3.6 -Python 3.4 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18689> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3982] support .format for bytes
Derek Wilson added the comment:
First off, +1 for this feature. It's not just for twisted, but anyone doing
anything with binary data (storage, compression, encryption and networking for
me) with python since 2.6 will very likely have been using .format for building
messages. I know I have and obviously others have been doing so as well.
The advantages of .format to me are:
* compatible with 2.6 (porting and single code base support easier)
* ease of composition (the format langauge makes it easy to build complex data
structures out of bytes)
* readability (named fields make complex formats obvious)
* consistency (manipulating a block of bytes or characters can be done in a
similar way)
Specific comments on the patch supplied by terry.reedy:
* it doesn't support named fields
* it doesn't handle padding
* it doesn't handle nested formats (like
'{0:{1}{2}}'.format(data,pad_char,pad_width)
* formatting byte strings with a width embedds the repr of the byte string (
bf(b'{:10}', [b'test']) == b b'test' )
Really this isn't a good way to solve the problem.
Has a PEP been created for this? If not how can I help make that happen?
Including this in 3.5 would be so helpful for us low level systems programmers
out there who have lots of code using .format for binary interfaces in python
2.6/2.7 already.
Also, not to add to derailment, but if we're adding a .format for python3 bytes
it would be great if .format could pad with the null byte ('\0') which it
currently converts to spaces internally (which is strange). Since this
unexpected conversion is bad (so padding with null doesn't happen in python2)
its more like a bug fix... actually - maybe that's a separate bug to file on
the current .format for text...
--
nosy: +underrun
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3982
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3982] support .format for bytes
Derek Wilson added the comment: sorry, terry's patch does handle padding - just with the caveats i listed later. i should have removed that bullet. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3982 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21416] argparse should accept bytes arguments as originally passed
New submission from Derek Wilson:
If I create an argument parser like:
parser = argparse.ArgumentParser()
parser.add_argument('somebytes', type=bytes, help='i want some bytes')
parser.parse_args()
the parse_args() call will raise an exception printing usage info indicating
that an invalid bytes value was passed if any of the bytes on the command
line are 127.
if i'm specifying that i want bytes then i should expect that the argument
should be interpreted as bytes and not text.
I get that #8776 was closed because it makes sense not to clutter up internals,
but in this instance i am building a command line parser and telling it exactly
what i expect. if the solution from #8776 of os.fsencode(sys.argv) will
definitely always work then argparse should do this internally if i tell it i
expect bytes on the command line.
--
components: Library (Lib)
messages: 217761
nosy: underrun
priority: normal
severity: normal
status: open
title: argparse should accept bytes arguments as originally passed
type: behavior
versions: Python 3.4, Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21416
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17305] IDNA2008 encoding missing
Derek Wilson added the comment: It is worth noting that the do exist some domains that have been registered in the past that work with IDNA2003 but not IDNA2008. There definitely needs to be IDNA2008 support, for my use case I need to attempt IDNA2008 and then fall back to IDNA2003. When support for IDNA2008 is added, please retain support for IDNA2003. I would say that ideally there would be a codec that could handle both - attempt to use IDNA2008 and on error fallback to idna2003. I realize this isn't official but it would certainly be useful. -- nosy: +underrun ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17305 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20209] Deprecate PROTOCOL_SSLv2
Derek Wilson added the comment: sslv2 should not be deprecated yet. in the field of security research it is highly valuable to locate servers that are still using sslv2 because it is a security risk. i'm fine with making it not used by default, but there is no reason to remove the capability from the language itself. thats way overkill. once sslv2 is no longer in the wild i have no problem with deprecation but the fact is that there is still a strong reason to keep the capability around. -- nosy: +underrun ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20209 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8220] site.py's Quitter pollutes builtins with exit and quit for non-interactive use
Derek Wilson added the comment: could this be reconsidered for 3.5+? most of the legacy code that you were worried about breaking would not port without tonnes of work anyway. it would also be nice to modify quitter's repr actually exit (so you don't get that ridiculously annoying Use exit() or Ctrl-D (i.e. EOF) to exit message). but that would be dangerous to do if it were not available only in the interactive interpreter. while that is my motivation for wanting quitter out of the global namespace, i do understand that is a different ticket. which i will submit. :-) -- nosy: +underrun versions: +Python 3.5 -Python 2.5, Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8220 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20016] make site.py Quitter call itself on repr
New submission from Derek Wilson: calling exit() or quit() is actually very cumbersome especially as most other commandline tools that have a command interface allow you to exit or quit by typing exit or quit and not by calling a function. if quitter's builtins are only available in the interactive interpreter this seems like it would be perfectly safe. now that we are looking at 3.x going forward, perhaps we can reopen this: http://bugs.python.org/issue8220 -- components: Extension Modules files: quit_from_repr.patch keywords: patch messages: 206537 nosy: underrun priority: normal severity: normal status: open title: make site.py Quitter call itself on repr versions: Python 3.5 Added file: http://bugs.python.org/file33194/quit_from_repr.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20016 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18616] enable more ssl socket options with get_server_certificate
Derek Wilson added the comment: any thoughts on this? there's a lot of room for improvement in python ssl... -- versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18616 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18233] SSLSocket.getpeercertchain()
Derek Wilson added the comment: I could really use this sooner than later... and sometimes having a full-featured (or even secure) interface is not what you want. Consider zmap and masscan etc and ssl mapping (similar to what the EFF did a couple years back - https://www.eff.org/observatory - but with the full chain instead of just the cert). The desire here would be low level, low overhead, no validation on the fly: All you want is the cert chain. There are plenty of research and security applications where a simple wrapper around OpenSSL that returns DER bytes would be desirable. Please reconsider this patch for inclusion in 3.4 ... -- versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18233 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5715] listen socket close in SocketServer.ForkingMixIn.process_request()
Derek Wilson added the comment: this would still be nice to have fixed ... any progress? -- nosy: +underrun versions: +Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5715 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18679] include a codec to handle escaping only control characters but not any others
Derek Wilson added the comment:
Any update on this? Just so you can see what my work around is, I'll paste in
the code I'm using. The major issue I have with this is that performance
doesn't scale to large strings.
This is also a bytes-to-bytes or str-to-str encoding, because this is the type
of operation that one plans to do with the data one has.
Having a full fledged streaming codec to handle this would be very helpful when
writing applications that stream tab and newline separated utf-8 data over
stdin/stdout.
text_types = (str, )
escape_tm = dict((k, repr(chr(k))[1:-1]) for k in range(32))
escape_tm[0] = '\0'
escape_tm[7] = '\a'
escape_tm[8] = '\b'
escape_tm[11] = '\v'
escape_tm[12] = '\f'
escape_tm[ord('\\')] = ''
def escape_control(s):
if isinstance(s, text_types):
return s.translate(escape_tm)
else:
return s.decode('utf-8',
'surrogateescape').translate(escape_tm).encode('utf-8', 'surrogateescape')
def unescape_control(s):
if isinstance(s, text_types):
return s.encode('latin1', 'backslashreplace').decode('unicode_escape')
else:
return s.decode('utf-8', 'surrogateescape').encode('latin1',
'backslashreplace').decode('unicode_escape').encode('utf-8', 'surrogateescape')
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18679
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18689] add argument for formatter to logging.Handler and subclasses in logging module
Derek Wilson added the comment: dictConfig and fileConfig are nice for static needs, but when I want to quickly enable a complex (but not complicated) logging flow I find it just as tedious as the current situation with the direct API. ... as at the very least every handler would need to be changed to accommodate the new kwarg Adding a keyword only argument to the base handler and the other handler classes is a nearly trivial change in terms of lines and complexity of the code. Also, this isn't going to work for third-party handlers which are out there already, since they won't necessarily recognise a new kwarg. I don't see that as a problem. If 3rd party handlers are intelligent then they will include **kargs in their __init__ and pass that forward to the initialization of their parent. If they haven't done so then nothing changes for them and they just support exactly the same features they supported previously. -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18689 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18679] include a codec to handle escaping only control characters but not any others
Derek Wilson added the comment:
using repr(x)[1:-1] is not safe for my use case as i need this for encoding and
decoding data. the deserialization of repr would be eval, and aside from the
security issues with that, if I strip the quotes off I can't reliably eval the
result and get back the original. On top of that, quote escape handling makes
this non-portable to other languages/tools that do understand control character
escapes. Consider:
s = Α\t'''Ω
print(s)
Α '''Ω
e = repr(s)[1:-1]
print(e)
Α\t\'\'\'Ω
how do i know what to quote e with before I eval it to get back the value? I
can't even try all the quoting options and stop when i don't get a syntax error
because more than one could work and give me a bad result:
d = eval('{}'.format(e))
d == s
False
print(d)
Α '''Ω
Aside from python not being able to handle the repr(x)[1:-1] case itself, the
goal is to use output generated in common tools from cut to hadoop where tab is
a field separator (aside: wouldn't adoption of ascii 0x1f as a common unit
separator be great). Sometimes it is useful to separate newlines in data from a
literal new line in formats (again like hadoop or unix utilities) that treat
lines as records (and here again ascii 0x1e would have been a nice solution).
But we have to work with what we've got and there are many tools that care
about tab separated fields and per line records. In these cases, the right tool
for the interoperability job is a codec that simply backslash escapes control
characters and nothing else.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18679
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18679] include a codec to handle escaping only control characters but not any others
Derek Wilson added the comment:
ast.literal_eval('%s' % e)
this doesn't work if you use the wrong quote. without introspecting the data in
e you can't reliably choose whether to use '%s' '%s' '%s' or
'''%s'''. which ones break (and break siliently) depend on the data.
e.encode().decode('unicode-escape').encode('latin1').decode()
so ... encode the repr()[1:-1] string in utf-8 bytes, decode backslash escape
sequences and individual bytes as if they are latin1, encode as latin1 (which
is just byte for byte serialization), then decode the byte representation as if
it is utf-8 encoded to recombine the characters that were broken with the
'unicode-escape' decode earlier?
this may work for my example, but this looks and feels very hacky for something
that should be simple and straight forward. and again tools other than python
will run into escaped quotes in the data which may cause problems.
e.encode('latin1', 'backslashescape').decode('unicode-escape')
when i execute this i get a traceback
LookupError: unknown error handler name 'backslashescape'
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18679
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18689] add argument for formatter to logging.Handler and subclasses in logging module
New submission from Derek Wilson:
It is common when setting up a logger to create both a handler and a formatter.
Nice format strings make logging better. Like this:
fmt_string = %(asctime)s [%(levelname)-9s] %(name)s: %(message)s
We would use it like so:
from logging import getLogger, StreamHandler, Formatter
logger = getLogger('mypackage.mymodule')
handler = StreamHandler()
formatter = Formatter(fmt_string)
handler.setFormatter(formatter)
logger.addHandler(handler)
logger.warning('she called out a warning...')
But its nice to separate adding handlers from using loggers. so in mymodule I
might do:
logger = getLogger('mypackage.mymodule')
logger.warning('do not pass go...')
and in whatever entry point cares about logging from mypackage (like a cli or
another module importing my package that wants log data) I would do:
base_logger = getLogger('mypackage')
handler = StreamHandler()
formatter = Formatter(fmt_string)
handler.setFormatter(formatter)
base_logger.addHandler(handler)
but usually, at this point, i don't care about this base_logger at all and i've
got a bunch of refs to things i don't need anymore - the only purpose of all
this code is to handle any logging that may be done elsewhere in the package.
If handlers allowed passing in a formatter into __init__, then we could reduce
the above to something like this:
getLogger('mypackage').addHandler(StreamHandler(
fmt=Formatter(fmt_string)))
Using a kwarg would make it so we don't need to worry about existing argument
order so that should be completely backward compatible.
It'd be extra friendly if Handler could introspect fmt and see if it is an
instance str and if so create a Formatter in itself ... that way we could do:
getLogger('mypackage').addHandler(StreamHandler(fmt=fmt_string))
This would reduce the barrier to entry to customizing logging functionality and
might go a long way toward increasing effective use of the same.
--
components: Library (Lib)
messages: 194706
nosy: underrun
priority: normal
severity: normal
status: open
title: add argument for formatter to logging.Handler and subclasses in logging
module
type: enhancement
versions: Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18689
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18679] include a codec to handle escaping only control characters but not any others
Derek Wilson added the comment:
e.encode('latin1', 'backslashreplace').decode('unicode-escape')
this works, but still the quotes are backslash escaped.
translate will do what i need for my use case, but it doesn't support streaming
for larger chunks of data.
it is nice that there is a workaround but i do still think this is a valuable
enough feature that there should be a builtin codec for it.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18679
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18679] include a codec to handle escaping only control characters but not any others
New submission from Derek Wilson:
Escaping strings for serialization or display is a common problem. Currently,
in python3, in order to escape a sting, you need to do this:
'my\tstring'.encode('unicode_escape').decode('ascii')
This would give you a string that was represented like this:
'my\\tstring'
But this does not present a suitable representation when the string contains
unicode characters. Consider this example:
s = 'Α\tΩ'
There is no method to write this string this with only the control character
escaped.
Even python itself recognizes this as a problem and implemented a solution
for it.
s = 'Α\tΩ'
print(s)
Α Ω
print(repr(s))
'Α\tΩ'
print(s.encode('unicode_escape').decode('ascii'))
\u0391\t\u03a9
What I want is public exposure of the functionality to represent control
characters with their common \ escape sequences (or \x## for control characters
where necessary - for instance unit and record separators).
I have numerous use cases for this and python's own str.__repr__ implementation
shows that the functionality is valuable. I would bet that the majority of
cases where people use unicode_escape something like a control_escape is more
along the lines of what is desired.
And while we're at it, it would be great if this were a unicode-unicode codec
like the rot_13 codec. My desired soluiton would look like this:
import codecs
s = 'Α\tΩ'
e = codecs.encode(s, 'control_escape'))
print(e)
Α\tΩ
print(codecs.decode(e, 'control_escape'))
Α Ω
If this is something that could be included in python 3.4, that would be
awesome. I am willing to work on this if so.
--
components: Library (Lib)
messages: 194625
nosy: underrun
priority: normal
severity: normal
status: open
title: include a codec to handle escaping only control characters but not any
others
type: enhancement
versions: Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18679
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18616] enable more ssl socket options with get_server_certificate
New submission from Derek Wilson: ssl.get_server_certificate does not allow advanced options like what ciphers to use (for ssl2 for instance) or SNI for virtual hosts with multiple ssl sites on one IP address. Adding **kwargs enables any current and future SSLSocket options to be passed along to the underlying connection. wrap_socket doesn't include all the options (npn and sni for instance), so I use SSLSocket instead. -- components: Extension Modules files: ssl_get_server_certificate_kwargs.patch keywords: patch messages: 194083 nosy: underrun priority: normal severity: normal status: open title: enable more ssl socket options with get_server_certificate type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file3/ssl_get_server_certificate_kwargs.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18616 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18369] X509 cert class for ssl module
Derek Wilson added the comment: actually, i suppose rather than change a bunch of existing functions/methods to handle X509 certs it would make more sense to add new methods to the X509 cert class (like match_hostname) so that old stuff doesn't break. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18369 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18369] X509 cert class for ssl module
Derek Wilson added the comment: For ssl.match_hostname to work with this, you need to get the info dict first. I've attached at patch for it. -- nosy: +underrun Added file: http://bugs.python.org/file31047/ssl_pyx509cert_match_hostname_fix.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18369 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18546] ssl.get_server_certificate like addition for cert chain
New submission from Derek Wilson: the ssl.get_server_certificate function is very useful for just requesting a cert. It would also be very useful to have a parallel function, possibly ssl.get_server_cert_chain that does the same thing except but provides a tuple of PEM encoded certs comprising the chain provided by the peer. It would also be very useful, given that we have the ability to collect certs and cert chains without validating them, to have a separate convenience method for validation of certs given a cert (or chain) and the file/path to trusted CA root certs. This way we could collect a cert chain once and validate against different ca cert stores, or collect a set of cert chains and do batch validation. oh, and I'd love to see the _ssl._decode_certificate function exposed so that we can get easily get python data structure from certs. If any of this sounds useful I would be happy to submit patches. -- components: Extension Modules messages: 193654 nosy: underrun priority: normal severity: normal status: open title: ssl.get_server_certificate like addition for cert chain type: enhancement versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18546 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18546] ssl.get_server_certificate like addition for cert chain
Derek Wilson added the comment: very cool - i had seen a couple of those patches and they look good. Most of what I asked for is implemented in supporting bits for those issues. Is their anything you could use some help on? I'm very interested in seeing better ssl support in python. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18546 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18293] ssl.wrap_socket (cert_reqs=...), getpeercert, and unvalidated certificates
Derek Wilson added the comment: Custom cert validation may make sense in edge cases, so this looks interesting. But I got here looking to file a bug on the returning empty dict from SSLContext.getpeercert - I don't feel like that makes sense. Its not like a peer cert doesn't exist just because it doesn't pass verification. And I know I can get the binary DER cert, but then I need to figure out how to parse it myself? pyasn1 makes me cry. It would be really nice if we could get the decoded-into-dict peer cert even when verification fails or when CERT_NONE is set. If it isn't possible (or advisable) for getpeercert to return the dict, exposing cert decoder would be really useful. Is this related enough to this request or should I file a separate issue? -- nosy: +underrun ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18293 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18233] SSLSocket.getpeercertchain()
Changes by Derek Wilson jderekwil...@gmail.com: -- nosy: +Derek.Wilson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18233 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15468] Edit docs to hide hashlib.md5()
Derek Wilson added the comment: Attached patch mentioning availability of md5 under FIPS compliance and the use of OpenSSL algorithms when available and altering the initial example to use sha1 instead of md5. -- keywords: +patch nosy: +Derek.Wilson Added file: http://bugs.python.org/file26609/issue15468.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15468 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6056] socket.setdefaulttimeout affecting multiprocessing Manager
Derek Wilson jderekwil...@gmail.com added the comment: Thanks, Jim, here is an updated patch. 1) I feel like it is clearly not-a-feature. Currently 2.7 crashes if remote managers are used and socket.setdefaulttimeout is anything other than None. Crashing seems bad and all this does is keep multiprocessing connection sockets non-blocking even if a default timeout is specified (so it maintains current behavior rather than crashing). 2) This problem is still evident on 2.7, 3.2 and 3.3 beta 1. This patch is against the current dev tip as of a few days ago. 3) here it is! 4) I agree that setblocking is more clear. I made the change. My test modifications cover the entire suite twice, once without a default timeout and once with. This may be excessive? I'm not sure where non-blocking sockets might pop up as an issue since there is C code that relies on blocking sockets and I haven't dug that deep. -- Added file: http://bugs.python.org/file26497/mp6056fix.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6056 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6056] socket.setdefaulttimeout affecting multiprocessing Manager
Derek Wilson jderekwil...@gmail.com added the comment: Any chance this patch will be accepted (or at least reviewed) soon? -- type: behavior - crash versions: +Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6056 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6056] socket.setdefaulttimeout affecting multiprocessing Manager
Derek Wilson jderekwil...@gmail.com added the comment: While having multiprocessing use a timeout would be great, I didn't really have the time to fiddle with the c code. Instead of using the socket timeout, I'm modifying all the sockets created by the socket module to have no timeout (and thus to be blocking) which makes the multiprocessing module 'immune' to the socket module's default timeout. For testing, I just run the test suite twice, once with the initial default socket timeout and once with a 60 second timeout. Nothing there failed with this issue. It is worth noting, however, that when using a default socket timeout, for some reason processes that have have put data into a queue no longer block at exit waiting for the data to be consumed. I'm not sure if there is some additional cleanup code that uses sockets and might need to block? Or maybe whatever the issue was with blocking sockets is not an issue with non-blocking sockets? -- keywords: +patch Added file: http://bugs.python.org/file22376/mpsock.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6056 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6056] socket.setdefaulttimeout affecting multiprocessing Manager
Derek Wilson jderekwil...@gmail.com added the comment: I was wrong about exit behavior of a process that has put to a queue -- it seems to behave as expected. i had been playing with a proxy to a queue rather than a queue (to which, if you put, the process can exit right away because the actual put happens in the process that owns the queue). I think this works as intended, but lmk. Also, I haven't really played with the tests that much, so that bit could use some review. It hasn't broken anything in any of my real world tests though. Also, have I mentioned that the multiprocessing module is amazing? Cause it is. I sort of feel like antigravity == multiprocessing ... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6056 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6056] socket.setdefaulttimeout affecting multiprocessing Manager
Derek Wilson jderekwil...@gmail.com added the comment: This should be higher priority as one of the major benefits of the multiprocessing module is remote process management in a completely transparent manner. socket timeouts are very important in this context as blocking forever waiting for a connection is not always an option. The problem of not being able to use a default socket timeout for other purposes in combination with multiprocessing managers is definitely an issue, but making multiprocessing actually use the timeout itself if set would be a huge advantage. This might not be the place to ask for it, but it would make sense for manager objects to gain a timeout attribute to be used as a timeout for local or remote communications. At the very least, the manager.connect() method should accept a timeout argument. -- nosy: +Derek.Wilson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6056 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
