Bug 538218

Summary: Format string error in python/rpmps-py.c:rpmps_append?
Product: [Fedora] Fedora Reporter: Dave Malcolm <dmalcolm>
Component: rpmAssignee: Panu Matilainen <pmatilai>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: ffesti, jnovy, pmatilai
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-11-20 10:23:19 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Dave Malcolm 2009-11-17 23:26:48 UTC
Description of problem:
The function "rpmps_append" has this code:
    char *pkgNEVR, *altNEVR, *str1;
    unsigned long ulong1;
    int ignoreProblem;
    rpmProblemType type;
    fnpyKey key;

    if (!PyArg_ParseTuple(value, "ssOiisN:rpmps value tuple",
			&pkgNEVR, &altNEVR, &key,
			&type, &ignoreProblem, &str1,
			&ulong1))

The final parameter, &ulong1, is thus an unsigned long*

However the conversion code 'N' doesn't seem to be a supported format code; 'k' is the correct format code for extracting unsigned long values; see http://docs.python.org/c-api/arg.html

Is this a supported API?

[david@brick check-cpython]$ python
Python 2.6.4 (r264:75706, Oct 29 2009, 22:44:06) 
[GCC 4.4.1 20090725 (Red Hat 4.4.1-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import rpm
>>> ps = rpm.ps()
>>> ps.append()
Segmentation fault

Found using my static checker tool:
http://dmalcolm.livejournal.com/3689.html

Version-Release number of selected component (if applicable):
at commit 16f9d7f4dcce8edc6458cd94ee0c7afda2c5dece ; not sure how to post this in the upstream tracker at rpm.org.

Comment 1 Panu Matilainen 2009-11-18 07:24:38 UTC
Heh, the invalid 'N' conversion has been there since 2004 and you're the first one to notice. I guess it's safe to say nobody uses the interface... might as well just remove it.

Thanks for spotting that.

Comment 2 Panu Matilainen 2009-11-20 10:23:19 UTC
"Fixed" upstream now, by killing the broken (and useless) interface.