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
