[issue22391] MSILIB truncates last character in summary information stream
New submission from Kevin Phillips:
I recently exploited a subtle bug with the msilib module's GetProperty method
on the SummaryInformation class. When retrieving string-typed properties from
the stream the last character in the string gets truncated, replaced by a
null-byte.
I am using Python v3.2.5 64bit on Windows 7, and I've managed to reproduce the
error with the following code snippet:
filename = "sample.msp"
patch_database = msilib.OpenDatabase(filename, msilib.MSIDBOPEN_READONLY |
msilib.MSIDBOPEN_PATCHFILE)
summary_info = patch_database.GetSummaryInformation(20)
print (summary_info.GetProperty(msilib.PID_REVNUMBER))
The PID_REVNUMBER returns the patch-GUID for the Windows Installer patch file.
In this example the GUID is returned properly however the character string is
supposed to be delimited by curly braces - { }. Examination of the returned
byte array shows that the leading curly brace is included by the final curly
brace is not. Closer examination also shows that the last character in the byte
array is \x00.
While it is possible, in this situation, to circumvent the bug by simply
removing the trailing bytes and replacing them with a closing curly brace, this
may not be so easy to work around for general character strings if the last
character in the sequence is not static. As such I'd highly recommend fixing
this in the source for the msilib module.
--
components: Library (Lib), Windows
messages: 226789
nosy: Kevin.Phillips
priority: normal
severity: normal
status: open
title: MSILIB truncates last character in summary information stream
type: behavior
versions: Python 3.2
___
Python tracker
<http://bugs.python.org/issue22391>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22391] MSILIB truncates last character in summary information stream
Kevin Phillips added the comment:
I should mention that I did discover some source code on GitHub, presumably for
this wrapper module, and I believe I found a few questionable parts in the
logic for this library that may help explain the cause of this problem:
https://github.com/python-git/python/blob/master/PC/_msi.c
Here are some snippets from the summary_getproperty function that may help:
char sbuf[1000];
char *sval = sbuf;
DWORD ssize = sizeof(sval);
First, here, I believe the ssize value is not going to be initialized as one
would expect at first glance. Since sval is a pointer and sizeof() returns the
size of it's parameter, in this case a pointer, ssize will represent the
pointer size on the target platform. In this case, on a 64bit OS, it's likely
going to be set to 8, which I suspect the expected value for ssize is going to
be 1000 - the size of the static array sbuff.
status = MsiSummaryInfoGetProperty(si->h, field, &type, &ival,
&fval, sval, &ssize);
if (status == ERROR_MORE_DATA) {
sval = malloc(ssize);
status = MsiSummaryInfoGetProperty(si->h, field, &type, &ival,
&fval, sval, &ssize);
}
Now, in this snippet it tries to load the string value from the file, and if
the input buffer is not of sufficient size it reallocates the pointer to an
appropriate size. Given the fact that ssize is probably initialized to 8 (or
less) it is pretty safe to assume the first call to MsiSummaryInfoGetProperty
changes this value to the length of the data stored in the file. Closer
examination of the documentation for this Windows API function reveals that in
this case ssize will be set to the number of characters required 'not including
the terminating null character'.
(http://msdn.microsoft.com/en-us/library/aa370409(v=vs.85).aspx)
result = PyString_FromStringAndSize(sval, ssize);
Then finally I noticed this function call. I suspect the problem may lie here.
I'm not too familiar with the Python SDK but it sounds like when using Unicode
strings - as all string are in Python 3 - you are supposed to use
PyUnicode_FromStringAndSize instead. So perhaps there might be something
getting lost in the translation, either via the use of this function or perhaps
subsequent marshalling of the string object into the Python runtime, due to the
encoding changes... not sure. It could be something as simple as one of the
function calls used therein assume that the 'size' count includes a null-byte
while others don't. It's hard to say without digging into the libs some more.
I hope this helps.
--
___
Python tracker
<http://bugs.python.org/issue22391>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22919] Update PCBuild for VS 2015
Kevin Phillips added the comment: This change has the adverse side effect of requiring users of Python 3.5 to use the Visual Studio 2015 runtime library. Further, as is documented on Microsoft's website, the minimum system requirements for installing and running this runtime is Windows 7 SP1 or newer. As a result, adopting this new compiler for the Python runtime prevents users of operating systems older than this from using this version. Even users with Windows 7 pre service pack are unable to use it. Based on a quick review of the comment thread here, the choice for adopting the 2015 compiler was relatively arbitrary and thus an older version, say 2013 for example, could have been used instead and older operation systems would still be supported with little to no impact on Python. While this is unfortunate to say the least, what makes matters worse is there appears to be little to no information on the Python.org website indicating that the minimum system requirements have now been affected in this way. Also, for users attempting to install v3.5 on a system older than this are presented with a cryptic error message basically just saying that "some unknown error has occurred", leaving them scratching their head trying to figure out what's wrong. Seeing as how you can't go back in time and fix this in 3.5.0, I am hoping that at the very least you could add some information about this to some obvious location on the main Python.org website, and maybe consider updating the installation for future 3.5.x releases such that a check is done to see if the operating system meets these new minimum requirements and present the user with some helpful information that would lead them to a resolution. -- nosy: +Kevin.Phillips ___ Python tracker <http://bugs.python.org/issue22919> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24572] IDLE Text Output Bug with ASCII Codes
Changes by Kevin Phillips (kmecpp) : -- title: IDLE Bug -> IDLE Text Output Bug with ASCII Codes ___ Python tracker <http://bugs.python.org/issue24572> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24572] IDLE Bug
New submission from Kevin Phillips (kmecpp): This appears to be a bug with IDLE that happens when printing out ASCII codes. I posted the issue to stackoverflow when I came accross it because I didn't know what the problem was, so there is a more detailed description of the there: http://stackoverflow.com/q/31235670/3476226 -- components: IDLE files: python_bug.png messages: 246343 nosy: Kevin Phillips (kmecpp) priority: normal severity: normal status: open title: IDLE Bug type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file39873/python_bug.png ___ Python tracker <http://bugs.python.org/issue24572> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24572] IDLE Text Output With ASCII Codes Not Working
Changes by Kevin Phillips (kmecpp) : -- title: IDLE Text Output Bug with ASCII Codes -> IDLE Text Output With ASCII Codes Not Working ___ Python tracker <http://bugs.python.org/issue24572> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
