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: scap-security-guide-bounces(a)lists.fedorahosted.org
[mailto:scap-security-guide-bounces@lists.fedorahosted.org] 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"
<rui-p-bernardino(a)telecom.pt>
To: "SCAP Security Guide" <scap-security-guide(a)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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide