Martin Panter
Martin Panter
About the Upverter project, I had a look at that early this year and their Altium support was not much use. It did not parse the blocks of the OLE...
I expect it uses something like Latin-1 or Windows-1252. I am happy to change line 996 to decode with Latin-1. However I noted under that I saw the byte 0x8E...
I've never really investigated making a Py PI package, but I'm open to the idea if someone wants to do the work or show me the way.
Probably also more agreeable with the GPL that way as well
Seems like shutil.\_unpack_tarfile() is affected. I guess it could at least do with one of those warnings in the documentation for make_archive(). The patch for this bug looks a bit...
bpo-17102 is open about the specific problem of escaping the destination directory. Maybe it is a duplicate, but this bug also discusses other problems.
bpo-29788 proposes an option to disable the vulnerability in the CLI
I am torn on this. On one hand, it would be good to be consistent with the single-argument behaviour. But on the other hand, APIs normally accept arbitrary bytes-like objects...
If asyncio users shouldn’t close sockets, are they still allowed to do other operations on them, e.g. call methods like getpeername(), recv()? I haven’t followed this closely, maybe another option...
The above changes were merged into the upstream "Pyrescene" project: * Set_message_id() fix: * Encoded test byte string: * Handle basestring: * Use BytesIO: and See also PR #4 with...