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

[Maura Dailey]

I'm so sorry I didn't see this response earlier. It definitely works 
again in the current git checkout. As for my custom stylesheet, for 
testing purposes, I merely copied the entire security guide template 
folder and made modifications to security-guide.xsl and dbout-html.xsl. 
I reworked the header generation section a little and changed some of 
the formatting in the CSS section. I've attached my modified copies of 
security-guide.xsl and dbout-html.xsl.

Thanks,
Maura Dailey

On 11/08/2012 09:02 AM, Peter Vrabec wrote:
> 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.
>>
>
> _______________________________________________
> Open-scap-list mailing list
> Open-scap-list at redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mods.tar.bz2
Type: application/x-bzip
Size: 7266 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/open-scap-list/attachments/20121119/f4aad9d2/attachment.bin>