Thanks Jan for exhaustive explanation, I now understand the problem. I do use 'meld' to *manually* merge my version with SSG's (and that is one of the reasons why I'm attempting to push some of my customizations), so it is quite possible something got damaged in the process.
But what happens if the original source already has trailing whitespace, as in (using :set list): ssg/RHEL/6/input/system/accounts/pam.xml:498: module. In the file <tt>/etc/pam.d/system-auth</tt>, append <tt>remember=24</tt> to the $ line which refers to the <tt>pam_unix.so</tt> module, as shown:$ My patch proposal: -module. In the file <tt>/etc/pam.d/system-auth</tt>, append <tt>remember=24</tt> to the $ +module. In the file <tt>/etc/pam.d/system-auth</tt>, append <tt>remember=<sub idref="var_password_history_retain_limit" /></tt> to the $ Does this mean I should remove the trailing whitespace in future patches? Upstream has quite a few... RHEL/6/input $ grep -rE " +$" * | wc -l 767 Regards -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jan Lieskovsky Sent: quarta-feira, 4 de Junho de 2014 12:04 To: SCAP Security Guide Subject: Re: [PATCH] Replace constants for profile value in XCCDF descriptions Hello Rui, ----- Original Message ----- > From: "Rui Pedro Bernardino" <[email protected]> > To: "SCAP Security Guide" <[email protected]> > Sent: Wednesday, June 4, 2014 12:04:33 PM > Subject: RE: [PATCH] Replace constants for profile value in XCCDF > descriptions > > > > Hi > > > > (…) > > > > Patch generates some whitespace errors: > > $ git apply /tmp/rui1.patch > /tmp/rui1.patch:156: trailing whitespace. > module. In the file <tt>/etc/pam.d/system-auth</tt>, append > <tt>remember=<sub idref="var_password_history_retain_limit" /></tt> to > the > /tmp/rui1.patch:382: trailing whitespace. > Set this to <tt><sub idref="var_auditd_space_left_action"/></tt> > (instead of the default which is <tt>suspend</tt>) > warning: 2 lines add whitespace errors. > > > > Not sure what this means. I’m new to git and my dev system cannot send > e-mails to the Internet; some of the submit steps are manual, perhaps > I messed things up. Sorry. Those trailing whitespace / whitespace noise errors shouldn't depend on the fact if you have sent the patch (set of patches) via git-send-email command (IOW in automated way) or manually via attaching the patch as attachment to the post. Rather they are sign there's is whitespace (space or tab character) present as the last character at some line of the patch before the newline character. You can see these by using e.g :set list vi / vim command, or when using e.g. gedit by enabling its "Draw Spaces" plug-in (gedit -> Edit -> Preferences -> Plugins tab, select Draw Spaces from the list, check it in, possibly fine-tune it's properties by clicking the 'Preferences' button & select what kind of whitespace should gedit display). Once enabled, you will see: * $ as the last character in vim. If there's whitespace before it (iow line doesn't end up with some word immediately followed by $ character), that's it, * . (dots) at the place of space, newline is represented as <__|. If you see some dots after end of previous word and before the <__| character, that's it. To fix these, it's just easy as open the patch text editor & remove those characters. Caution: While git is able to detect these, it's not always correct about their location (iow about the exact line number). It's possible the whitespace error is present couple of rows above / below the line as reported by git warning. There are multiple reasons why whitespace noise errors are wrong. To mention some of them: * it might lead to falsey diffs which claim lines have been changed when in fact the only thing that changed was spacing (this can lead to make future finding what actually changed in the file from hard to impossible), * it can cause problems in the functionality of scripts for space / indent sensitive languages (e.g. Python) - unnoticed whitespace might later cause particular script to be doing something else, it was intended to, * while the above point wouldn't be such problem for XML (it would just display one more space at the place where one should be displayed) [IOW instead of leaving the formatting to the tools, you require one / more space(s) to be inserted at that place), the generated document wouldn't look the way it should. And there are more reasons, why leaving whitespace noise at the patch line end is bad habit depending on the underlying programming language used (just google for more of them if interested). Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team P.S.: To check if proposed patch wouldn't introduce whitespace noise, once patch generated via format-patch clone a clear copy of recent repo under different subdir & try to apply it via git-apply. If there's some whitespace warning, fix the part & retry [*] [*] This isn't to say I have never proposed a patch which contained whitespace noise. Just to say that if git reports whitespace noise warnings, those should be fixed (for the above snippet of reasons at the very least) > > > (…) > > ..... the XCCD variable does not get populated here. > > > > It does get populated on eval reports and on guides. However it > doesn’t populate on table-* files so it may need a few adjustments. > > > I'm using: > $ rpm -qa openscap openscap-utils > openscap-utils-1.0.8-1.el6_5.x86_64 > openscap-1.0.8-1.el6_5.x86_64 > > Same here. > > Did these substitutions work for you? > > I’ve been using this for quite some time on our profiles (we have our > own policies). I think this behavior is better than using text (eg) > “The DoD requirement is 14. The FISMA requirement is 12. (…)” or > having sysadmins figure out the specific compliance values elsewhere. > > > > Regards > > > > _______________________________________________ > scap-security-guide mailing list > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > _______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide _______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
