[PATCH] Replace constants for profile value in XCCDF descriptions

Jan Lieskovsky jlieskov at redhat.com
Wed Jun 4 11:03:51 UTC 2014


Hello Rui,

----- Original Message -----
> From: "Rui Pedro Bernardino" <rui-p-bernardino at telecom.pt>
> To: "SCAP Security Guide" <scap-security-guide at lists.fedorahosted.org>
> 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
> scap-security-guide at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> 


More information about the scap-security-guide mailing list