https://bugzilla.redhat.com/show_bug.cgi?id=1202604 --- Comment #12 from Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> --- (In reply to Stephen Gallagher from comment #11) > (In reply to Zbigniew Jędrzejewski-Szmek from comment #10) > > TemporaryFile and NamedTemporaryFile and mkstemp share the implementation, > > so there's no difference in security, only in the way that file is > > automatically deleted. > > > > I generally avoid assuming implementations when the documentation implies > otherwise. From the docs, it sounds like mkstemp() is *guaranteed* to behave > this way, whereas there is no mention of security from NamedTempFile in the > docs. The fact that it's currently implemented the same isn't necessarily > relevant. I'm a big fan of NamedTemporaryFile and TemporaryFile ;) The docs could use some freshening, that's true. But they do say that "[NamedTemporaryFile] perates exactly as TemporaryFile does, except that the file is guaranteed to have a visible name in the file system", and TemporaryFile "is created using mkstemp". (This is the part that is wrong, because both mkstemp and *TemporaryFile call to a helper function, but TemporaryFile does not actually call mkstemp.) http://bugs.python.org/issue23725 > If I went this route, do you think I should rename the package to simply 'sscg' then? Yes, makes sense. > > > > In the python code, a bare try: ... except: (without any exception na > > > > after "except") is used. In some places the exception is re-raised, but in > > > > others not. This is a problem because the script might be ended with ^C (or > > > > a signal) and silently "swallow" the exception. The script should always > > > > exit after being interrupted. It also should not print an error message like > > > > "Failed to write..." when killed. > > > Ah, where did I do that? It wasn't intentional. > > I'm not sure about what one specifically you're asking... "bare" except is > > used almost everywhere. > > > > In src/sscg/main.py there is this: > > > > try: > > os.unlink(file) > > except: > > # Nothing we can do if we get an error > > pass > > I should probably log an error there, but no matter what exception I get, > there's no solution... Logging is one thing. I was worried about the following scenario: try: os.unlink(file) <----------------- ^C is pressed here except: <----------------- KeyboadInterruptException is caught here # Nothing we can do if we get an error pass <----------------- nothing happens <----------------- program continues running With a slow filesystem, or a hanging network filesystem this kind of race is quite possible. > > > > > > > It seems that gettext is called on formatted arguments: > > > > _("Could not write to {0}. Error: {1}".format(...)) > > > > but it should be before: > > > > _("Could not write to {0}. Error: {1}").format(...) > > > > > > > > > > Typo, thanks for catching it. > > > > > > Yes, binary is the default. But decoding goes from bytes to unicode (i.e. > > text, i.e. str in Python 3). Encoding goes from text (i.e. str) to a > > specific encoding, for example UTF-8, and the bytes type. So you were > > writing text to a binary file. This actually does not work in Python 3: > > > > >>> f = tempfile.NamedTemporaryFile() > > >>> f.write('blah') > > Traceback (most recent call last): > > File "<stdin>", line 1, in <module> > > File "/usr/lib64/python3.4/tempfile.py", line 399, in func_wrapper > > return func(*args, **kwargs) > > TypeError: 'str' does not support the buffer interface > > > > although it does work under Python 2. > > Well, the problem here is that pyOpenSSL behaves differently between python2 > and python3. On python2, crypto.dump_certificate() returns a str, but it > returns a binary type on python3. To support both language versions, I just > always pipe it through a conversion to UTF-8. I could do it the opposite > direction if that seems more sensible. UTF-8 *is* binary. Under python 2 you get a sequence of UTF-8 octets which you can directly write to a binary file. Under python 3 you get the same thing. The difference is that Python 3 makes the distinction between bytes and text, and considers this UTF-8-encoded Unicode string to be binary, and Python 2 does not make the distinction, so it allows it to be used as both, in some circumstances. The distinction is blurry, but under Python 2 'str' is binary. I haven't tested this, but I'm pretty sure that if use the exact same code under Python 2 and 3, and not do any conversions, things should just work. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review