[Open-scap] Noticed path construction problem with XCCDF's generate custom --stylesheet Option

[Peter Vrabec]

Hi Maura,

$oscap xccdf generate custom ... was fixed in repository.

commit: 1ad1a222b684eb11f3cc6e85fe5443f5a16901a7

The functionality will be available again in next release 0.9.2. If you 
can share your stylesheet with us I can check if everything work before 
we do the release.

Peter.

On 11/04/2012 10:40 AM, Simon Lukasik wrote:
> On 11/02/2012 09:24 PM, Maura Dailey wrote:
>> In the recent openscap-0.9.1 release, the XCCDF custom option that let
>> you specify your own XSL stylesheets is broken. I just confirmed it
>> today in the git repository as well. I haven't tracked exactly when the
>> problem cropped up, but in the oscap_apply_xslt_path function, the
>> contents of the path specified with the --stylesheet option are incorrectly
>> appended to the compile time configured XSL directory. On RHEL 6, that
>> defaults to /usr/share/openscap/xsl/.
>>
>>
>> The command I have used successfully in the past, as part of the RHEL6
>> scap-security-guide project, is:
>> $ oscap xccdf generate custom --stylesheet
>> /home/maura/myxsls/transform.xsl --profile allrules
>> scap-security-guide/RHEL6/output/ssg-rhel6-xccdf.xml > somehtml.html
>>
>>
>> Now I get the following error messages:
>>
>> (When I use the openscap-0.9.1 rpm provided by EPEL):
>> OpenSCAP Error:: XSLT file '/home/maura/myxsls/transform.xsl' not found
>> in path '/usr/share/openscap/xsl' when trying to transformation
>> 'scap-security-guide/RHEL6/output/ssg-rhel6-xccdf.xml' [oscapxml.c:329]
>>
>> This looks in an actual folder that was probably specified at compile time.
>>
>>
>> (When I use a fresh git checkout configured with the prefix /home/maura):
>> OpenSCAP Error:: XSLT file '/home/maura/myxsls/transform.xsl' not found
>> in path '/home/maura/share/openscap/xsl' when trying to transformation
>> 'scap-security-guide/RHEL6/output/ssg-rhel6-xccdf.xml' [oscapxml.c:337]
>>
>> Same story, different compile time path.
>>
>>
>> For testing purposes, I actually copied the entire xsl directory that is
>> installed by OpenSCAP and normally used by default when the generate
>> guide option is specified. The only change I made was to rename
>> security-guide.xsl to transform.xsl. The behavior in a previous release
>> was to take either a relative or absolute path to an XSL file that it
>> would then attempt to apply. This exact same command did create a
>> property formatted HTML file a few weeks ago. It only broke when our
>> systems got upgraded to the latest release.
>>
>> I haven't had the time to trace back exactly how much of the code makes
>> this fundamental assumption about file paths or figure out where to
>> insert branches that could catch the use of the stylesheet option and
>> react accordingly, but the line "char * xsltpath =
>> oscap_sprintf("%s%s%s", path_to, "/", xsltfile);" seems to indicate that
>> there is an assumption that XSL files will always be in compile time
>> configured paths (the function oscap_apply_xslt_path is always called
>> with path_to set to either OSCAP_XSLT_PATH or OSCAP_SCHEMA_PATH).
>>
>> - Maura Dailey
>>
>
> It is valid bug. I have created ticket #263 for this. -- As I believe,
> we could have it fixed in next release.
>
> Thank You for report and sorry for troubles.
>