[issue10684] Folders get deleted when trying to change case with shutil.move (case insensitive file systems only)
Heikki Toivonen added the comment: You can't solve this by trying to do different things on different operating systems. This bug depends on file system properties, not OS. Also I don't think you can just lower case the path and do a comparison, because there are funky characters that don't round trip lower->upper->lower. And you certainly can't do this for just the last component of the path name - any component of the path could have changed case. I still think the best avenue would be to first try straight os.rename, and if that fails (maybe only if target exists), the logic that is currently in shutil.move. -- ___ Python tracker <http://bugs.python.org/issue10684> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10684] Folders get deleted when trying to change case with shutil.move (case insensitive file systems only)
Changes by Heikki Toivonen : -- assignee: -> ronaldoussoren components: +Macintosh nosy: +ronaldoussoren ___ Python tracker <http://bugs.python.org/issue10684> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10684] Folders get deleted when trying to change case with shutil.move (case insensitive file systems only)
Heikki Toivonen added the comment: I also noticed this last week. However, this is not Windows specific. It happens with file systems that are not case sensitive. Besides Windows (NTFS, FAT*) the other common platform is Macintosh (HFS+ with default settings). What happens is that we copy source into itself, then delete source. I am not sure what the optimal solution would be but an easy one would be to first try os.rename (which works in this case), but if that fails then do the stuff that is currently shutil.move. -- nosy: +heikki title: Folders get deleted when trying to change case with shutil.move (Windows) -> Folders get deleted when trying to change case with shutil.move (case insensitive file systems only) versions: +Python 2.6 ___ Python tracker <http://bugs.python.org/issue10684> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8998] add crypto routines to stdlib
Heikki Toivonen added the comment: More or less random opinions on things presented before: * I prefer having secure defaults to over documentation, because, well, people don't read documentation. * If not secure defaults, then pointing out in documentation the secure way AND providing examples that always show the secure way of doing things. * I can't comment on aes 192 vs 256 as I have not really kept up with that, but it would be good to ask the opinion(s) of the real experts in this field before choosing the defaults/recommending them. Of course, if you can point to an article where the experts already voice their (recent) recommendations, fine. * When I have thought about Python crypto in the stdlib, I've considered modeling it after hashlib, so you would get cipher = cryptolib.AES(bits=192, ...) etc. (Caveat: haven't thought it through.) * I'd prefer if the crypto API didn't become OpenSSL specific (like the SSL one is), which would theoretically allow switching in other crypto provider(s). * The library should make it easy to do the most common operations with as few steps as practically possible. * It would be nice if the library could provide the means to tweak lower level things if you needed to. Unfortunately this has a tendency to get messy quick, because crypto stuff tends to have lots of options to tweak. -- ___ Python tracker <http://bugs.python.org/issue8998> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8550] Expose SSL contexts
Heikki Toivonen added the comment: Since SSLv2 is insecure, could you at least add a warning for that protocol? I think there was a separate issue for removing it altogether, but could a warning be added here? The documentation should mention that verify_mode=CERT_REQUIRED is recommended for security. There should probably be an example of using SSL context in the documentation. I think you need to expose SSL_CTX_set_options(). Currently the code just sets all options, which means that the default protocol SSLv23 will accept SSLv2 which is insecure. Most people would want to probably do something like ctx.set_options(SSL_OP_ALL | SSL_OP_NO_SSLv2). Documentation should also mention that this is recommended for security. See man SSL_CTX_set_options. Otherwise I could not see issues with the code, apart from the still #if 0'd out sections and commented out sections, which you are planning on doing something about, right? -- ___ Python tracker <http://bugs.python.org/issue8550> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1589] New SSL module doesn't seem to verify hostname against commonName in certificate
Heikki Toivonen <[EMAIL PROTECTED]> added the comment: Ok, thank you for clarifications. Now I understand why the hostname checking isn't the solution that fits every problem. I am still not completely clear how you'd do the checking otherwise, for example to verify the service you are talking to is what you think it is. But still, I think dealing with email servers is another common use case where hostname check is adequate most of the time. I am sure there are other cases like this. Therefore I am still of the opinion that the default should be to do the hostname check. Yes, make it overridable, but doing the check is safer than not doing any checking IMO because even if the check is incorrect for a certain purpose the developer is likely to notice an error quickly and inclined to do some other security check instead of not doing anything and thinking they have a secure system. If you want to continue the discussion, we should maybe take this to some other forum, like comp.lang.python. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1589> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1589] New SSL module doesn't seem to verify hostname against commonName in certificate
Heikki Toivonen <[EMAIL PROTECTED]> added the comment: Could you clarify your comment regarding hostname check being false security? Just about all SSL texts I have read say you must do that, and that is what your web browser and email client does to ensure it is talking to the right host, for example. Without that check you are subject to a man in the middle attack. Or is there some other check you perform that is better? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1589> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3597] Allow application developers to select ciphers, and default to strong in ssl lib
Heikki Toivonen <[EMAIL PROTECTED]> added the comment: Yeah, compatibility can be a problem. The cipher list I used for M2Crypto was recommended in the book Network Security with OpenSSL (I think). Besides removing unsafe ciphers, it orders the remaining ciphers from strongest to weakest, based on the hope/assumption/practice that peers will hopefully select the first matching cipher. It is not foolproof, though, so for truly compatible application you'd probably need to try with different ciphers lists if you run into errors. However, I have never run into a problem myself with that list, nor has anyone reported any bugs against M2Crypto because of that. Defaulting to TLSv1 should select a better cipher list than otherwise, but I would be a bit concerned about that in turn being an even bigger compatibility issue. I guess I could ask around. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3597> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1589] New SSL module doesn't seem to verify hostname against commonName in certificate
Heikki Toivonen <[EMAIL PROTECTED]> added the comment: I would think most people/applications want to know to which host they are talking to. The reason I am advocating adding a default check to the stdlib is because this is IMO important for security, and it is easy to get it wrong (I don't think I have it 100% correct in M2Crypto either, although I believe it errs on the side of caution). I believe it would be a disservice to ship something that effectively teaches developers to ignore security (like the old socket.ssl does). A TLS extension also allows SSL vhosts, so static IPs are no longer strictly necessary (this is not universally supported yet, though). ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1589> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3597] Allow application developers to select ciphers, and default to strong in ssl lib
New submission from Heikki Toivonen <[EMAIL PROTECTED]>:
The 2.6 documentation states selecting the most compatible SSLv23 mode
may mean low quality ciphers, which does not really help the application
developers. It would be better to provide a way to set the allowed
ciphers. Even better, IMO, would be if the ssl module would default to
the stronger ciphers. I use the following default in M2Crypto:
set_cipher_list('ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH').
--
components: Library (Lib)
messages: 71406
nosy: heikki
severity: normal
status: open
title: Allow application developers to select ciphers, and default to strong in
ssl lib
type: security
versions: Python 2.6
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3597>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1589] New SSL module doesn't seem to verify hostname against commonName in certificate
Heikki Toivonen <[EMAIL PROTECTED]> added the comment: I would definitely recommend providing as strict as possible hostname verification in the stdlib, but provide application developers a way to override that. M2Crypto (and TLS Lite, from which I copied the approach to M2Crypto), provide a default post connection checker. See http://svn.osafoundation.org/m2crypto/trunk/M2Crypto/SSL/Connection.py and the set_post_connection_check_callback() as well as http://svn.osafoundation.org/m2crypto/trunk/M2Crypto/SSL/Checker.py. -- nosy: +heikki ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1589> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3596] Provide a way to disable SSLv2 (or better yet, disable by default)
New submission from Heikki Toivonen <[EMAIL PROTECTED]>: There should be a way to disable SSLv2 since it is insecure. It would be even better if SSLv2 was disabled out of the box, but maybe there could be a way to re-enable it. I made the default to disable SSLv2 in M2Crypto, but those that want it can explicitly request unsecure connection. You can take a look at http://svn.osafoundation.org/m2crypto/trunk/M2Crypto/SSL/Context.py to see how I did it. Modern web browsers are also removing SSLv2 support from them, so it should be really rare to actually need v2 anywhere. -- components: Library (Lib) messages: 71404 nosy: heikki severity: normal status: open title: Provide a way to disable SSLv2 (or better yet, disable by default) type: security versions: Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3596> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1443504] locale.getpreferredencoding() dies when setlocale fails
Heikki Toivonen added the comment: We noticed this too in Chandler. We worked around this issue with the patch I am attaching. Maybe not a correct fix, though. -- nosy: +heikki versions: +Python 2.5 Added file: http://bugs.python.org/file8833/patches-2.5.1-Linux _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1443504> _ patches-2.5.1-Linux Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
