Spec URL: http://fedorapeople.org/~jlieskov/scap-security-guide.spec SRPM URL: http://fedorapeople.org/~jlieskov/scap-security-guide-0.1-2.fc19.src.rpm Description: The scap-security-guide project provides security configuration guidance in formats of the Security Content Automation Protocol (SCAP). It provides a catalog of practical hardening advice and links it to government requirements where applicable. The project bridges the gap between generalized policy requirements and specific implementation guidance. Fedora Account System Username: jlieskov
Hello Jan, To Fedora you need remove the line "rm -rf $RPM_BUILD_ROOT" after macro %install >%install >rm -rf $RPM_BUILD_ROOT The installation is made by "root" >%defattr(-,root,root,-) That is not necessary.
Hello, also the following are not needed for Fedora: - %clean section - BuildRoot tag - Group tag Actually they are now required only for RHEL 5 packages.
(In reply to Yohan Graterol from comment #1) > Hello Jan, > > To Fedora you need remove the line "rm -rf $RPM_BUILD_ROOT" after macro > %install > > >%install > >rm -rf $RPM_BUILD_ROOT > > The installation is made by "root" > > >%defattr(-,root,root,-) > > That is not necessary. Thanks Yohan, applied your proposals. Submitted new versions of both the spec and source RPM package at: Spec URL: http://fedorapeople.org/~jlieskov/scap-security-guide.spec (afbe8a9815c030f924518d5d1be141fecb2eb430) SRPM URL: http://fedorapeople.org/~jlieskov/scap-security-guide-0.1-2.fc19.src.rpm (3d6c46153c94b983ef86fe83844e52698c320fcf) Regards, Jan.
BuildRoot is not needed. Rerequires: filesystem, coreutils, is also not needed. "The scap-security-guide project provides security configuration guidance in formats of the Security Content Automation Protocol": this sentence is somehow grammatically incorrect. Gzipping of manpages will be done automatically, just copy it into the right place. If the compression method changes, spec will not have to be adjusted. Drop the chcon. Every package I have seen installs man pages without this. Drop %clean. Change .gz to *. in %files, so that it works if the compression changes. Fedora 19 version is hardcoded in various places. Is the package really so version specific, that it must be specific for each version of Fedora? You most certainly want to build this for F20 and rawhide too... Source refers to your personal page. Why can't you use an "real" URL like https://git.fedorahosted.org/cgit/scap-security-guide.git/snapshot/scap-security-guide-d478d863b4166d105dbdd1b577d27edb3f847a86.tar.bz2? This has the advantage that it's easier to see the origin of sources. Please add LICENSE to %files. Directories without known owners: /usr/share/xml/scap/ssg/fedora, /usr/share/xml, /usr/share/xml/scap, /usr/share/xml/scap/ssg/fedora/19, /usr/share/xml/scap/ssg Hm, binary package requires openscap-utils, which in turn requires openscap, totalling 2.8 MB. Why does this requirement exist?
Jan, why do you use fedora release number a path? I mean /usr/share/xml/scap/ssg/fedora/19/ I would prefer the path that doesn't change in each Fedora release so users and tools can rely on it.
(In reply to Peter Vrabec from comment #5) Hi Peter, > Jan, why do you use fedora release number a path? I mean > /usr/share/xml/scap/ssg/fedora/19/ > > I would prefer the path that doesn't change in each Fedora release so users > and tools can rely on it. My original motivation was to have possibility how to distinguish the specific cases when certain SCAP content rules (for example for Fedora 18 and Fedora 19 would differ). That's why the path was hard-coded there. But since we have solved this internally already (we will deal with these cases on the level of the XCCDF file definition), then there truly isn't a need the Fedora release number to be hard-coded in the path. Will change the proposal yet. Thanks && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
(In reply to Zbigniew Jędrzejewski-Szmek from comment #4) Thank you a lot for your comments, Zbigniew. Fixed those sections marked as fixed below with new: Spec URL: http://fedorapeople.org/~jlieskov/scap-security-guide.spec SRPM URL: http://fedorapeople.org/~jlieskov/scap-security-guide-0.1-3.rc1.fc19.src.rpm > BuildRoot is not needed. > Rerequires: filesystem, coreutils, is also not needed. Both of the above are fixed in this version. > > "The scap-security-guide project provides security configuration guidance in > formats of the Security Content Automation Protocol": this sentence is > somehow grammatically incorrect. Reformulated description of the package to hear like: %description The scap-security-guide project provides guide for configuration of the system from final system's security point of view. The guidance is specified in the Security Content Automation Protocol (SCAP) format and consitutes a catalog of practical hardening advice linked to government requirements where applicable. The project bridges the gap between generalized policy requirements and specific implementation guidelines. Fixed - hopefully better now. > > Gzipping of manpages will be done automatically, just copy it into the right > place. If the compression method changes, spec will not have to be adjusted. Fixed. > > Drop the chcon. Every package I have seen installs man pages without this. > > Drop %clean. > > Change .gz to *. in %files, so that it works if the compression changes. All three of the above fixed. Please have a look at new version. > > Fedora 19 version is hardcoded in various places. Is the package really so > version specific, that it must be specific for each version of Fedora? You > most certainly want to build this for F20 and rawhide too... The original motivation for this was to have a way / possibility how to distinguish cases, when for example Fedora18 and Fedora19 wouldn't have the same content (IOW there would be certain Fedora release specific rules). But after internal discussion we have agreed to handle this on the level of XCCDF content definition, so removed the hard-coded Fedora release version from final files path, provided by package (though still left it in file names generated from SSG Makefile as at the moment not sure having for example universal ssg-fedora-xccdf.xml file would cover all cases. We might change this in the future yet if the reality shows all cases [scanning Fedora18 guest on Fedora19 host] would be still possible while having this filenames scheme). > > Source refers to your personal page. Why can't you use an "real" URL like > https://git.fedorahosted.org/cgit/scap-security-guide.git/snapshot/scap- > security-guide-d478d863b4166d105dbdd1b577d27edb3f847a86.tar.bz2? This has > the advantage that it's easier to see the origin of sources. Agree this way the tarball source might be more transparent to final users. Though as of right now didn't find a way how to successfully predict future git commit's id (in the moment i am commiting the change to local repository don't know the id yet. Editing the spec file afterwards, committing again and squashing / merging the change from latest commit into previous one [in order the source URL to be correct] generates a new commit id. So far didn't find a way how to know next upcoming Git commit id in the moment of git commit (IOW not to need yet another one just to note the correct source URL in the spec file from the previous commit). Not to mention, that patches posted to scap-security-guide mailing list require review, and sometimes happens someone else commits my change from their local version of the Git repository (so even if i would overcome the previous point, the source URL might result being invalid after certain commits). Long story short for now I have left it point to my personal page on FP.org. > > Please add LICENSE to %files. Added. > > Directories without known owners: /usr/share/xml/scap/ssg/fedora, > /usr/share/xml, /usr/share/xml/scap, /usr/share/xml/scap/ssg/fedora/19, > /usr/share/xml/scap/ssg While I would like to apply this proposal, not sure how to achieve it - can you hint? Should scap-security-guide package create new dedicated user and change ownership on those files them to be owned by that new user afterwards? Just OOC what's wrong with those XML files being owned by root? AFAIHL no package providing content under /usr/share/xml/* changes ownership of those by-package newly provided files. > > Hm, binary package requires openscap-utils, which in turn requires openscap, > totalling 2.8 MB. Why does this requirement exist? Because the proposed scap-security-guide package provides only SCAP XML content (i.e. set of rules) for scanning Fedora hosts / systems. But the tools actually performing the scan come from openscap-utils (oscap CLI tool) or scap-workbench (scap-workbench GUI tool) packages, which in turn relies on openscap package. Not sure how this point could be solved without depending on those packages. Please re-review && let me know your thoughts. Thank you for your comments && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
(In reply to Jan Lieskovsky from comment #7) > %description > The scap-security-guide project provides guide for configuration of the > system from final system's security point of view. The guidance is specified > in the Security Content Automation Protocol (SCAP) format and consitutes > a catalog of practical hardening advice linked to government requirements > where applicable. The project bridges the gap between generalized policy > requirements and specific implementation guidelines. The scap-security-guide project provides [a] guide for configuration of the system from [the] final system's security point of view. The guidance is specified in the Security Content Automation Protocol (SCAP) format and cons[t]itutes a catalog of practical hardening advice[,] linked to government requirements where applicable. The project bridges the gap between generalized policy requirements and specific implementation guidelines. > Fixed - hopefully better now. I think one additional sentence, which gives an indication how this is to be used, would be great. Something like "The administrator can use ... from openscap-utils or openscap-workbench to verify that the system conforms to guidelines." Or something like that, because the name "-guide" suggests that this is just documentation. > > Gzipping of manpages will be done automatically, just copy it into the right > > place. If the compression method changes, spec will not have to be adjusted. > > Fixed. > > > > > Drop the chcon. Every package I have seen installs man pages without this. > > > > Drop %clean. > > > > Change .gz to *. in %files, so that it works if the compression changes. > > All three of the above fixed. Please have a look at new version. Looks fine. > > Fedora 19 version is hardcoded in various places. Is the package really so > > version specific, that it must be specific for each version of Fedora? You > > most certainly want to build this for F20 and rawhide too... > > The original motivation for this was to have a way / possibility how to > distinguish cases, when for example Fedora18 and Fedora19 wouldn't have the > same content (IOW there would be certain Fedora release specific rules). > > But after internal discussion we have agreed to handle this on the level > of XCCDF content definition, so removed the hard-coded Fedora release version > from final files path, provided by package (though still left it in > file names generated from SSG Makefile as at the moment not sure having for > example universal ssg-fedora-xccdf.xml file would cover all cases. We might > change this in the future yet if the reality shows all cases [scanning > Fedora18 guest on Fedora19 host] would be still possible while having this > filenames scheme). > > > > > Source refers to your personal page. Why can't you use an "real" URL like > > https://git.fedorahosted.org/cgit/scap-security-guide.git/snapshot/scap- > > security-guide-d478d863b4166d105dbdd1b577d27edb3f847a86.tar.bz2? This has > > the advantage that it's easier to see the origin of sources. > > Agree this way the tarball source might be more transparent to final users. > Though as of right now didn't find a way how to successfully predict future > git commit's id (in the moment i am commiting the change to local repository > don't know the id yet. Editing the spec file afterwards, committing again > and squashing / merging the change from latest commit into previous one [in > order the source URL to be correct] generates a new commit id. > > So far didn't find a way how to know next upcoming Git commit id in the > moment of git commit (IOW not to need yet another one just to note the > correct source URL in the spec file from the previous commit). > > Not to mention, that patches posted to scap-security-guide mailing list > require review, and sometimes happens someone else commits my change from > their local version of the Git repository (so even if i would overcome the > previous point, the source URL might result being invalid after certain > commits). > > Long story short for now I have left it point to my personal page on FP.org. OK, I wasn't aware that this is all generated in this way. If current arrangement works for you, that's fine. > > Directories without known owners: /usr/share/xml/scap/ssg/fedora, > > /usr/share/xml, /usr/share/xml/scap, /usr/share/xml/scap/ssg/fedora/19, > > /usr/share/xml/scap/ssg > > While I would like to apply this proposal, not sure how to achieve it - can > you hint? Should scap-security-guide package create new dedicated user and > change ownership on those files them to be owned by that new user afterwards? > > Just OOC what's wrong with those XML files being owned by root? AFAIHL no > package providing content under /usr/share/xml/* changes ownership of those > by-package newly provided files. This is about "owning" in the sense of RPM package ownership: currently, when I do 'rpm -qf /usr/share/xml/scap', rpm tell me that the directory is unowned. This means that if I uninstall the package, the directory won't be deleted. repoquery is quite useful in researching ownership. Basically, you should add 'Requires: xml-common', because it owns /usr/share/xml, and change %{_datadir}/xml/scap/ssg/fedora/* to %{_datadir}/xml/scap. This way all files and directories should be "owned". > > Hm, binary package requires openscap-utils, which in turn requires openscap, > > totalling 2.8 MB. Why does this requirement exist? > > Because the proposed scap-security-guide package provides only SCAP XML > content (i.e. set of rules) for scanning Fedora hosts / systems. But the > tools actually performing the scan come from openscap-utils (oscap CLI tool) > or scap-workbench (scap-workbench GUI tool) packages, which in turn relies > on openscap package. > > Not sure how this point could be solved without depending on those packages. OK, that's fine then. One last question: can the .html file be installed as %doc? This would make it much easier to find for the user. With unversioned docdirs [1] the path would be something like /usr/share/doc/scap-security-guide/ssg-fedora-guide.html. [1] https://fedoraproject.org/wiki/Changes/UnversionedDocdirs
(In reply to Zbigniew Jędrzejewski-Szmek from comment #8) Thank you for the second round of review, Zbigniew. Much appreciated. Fixed the points below with new spec and srpm versions as follows: Spec URL: http://fedorapeople.org/~jlieskov/scap-security-guide.spec SRPM URL: http://fedorapeople.org/~jlieskov/scap-security-guide-0.1-3.rc2.fc19.src.rpm > (In reply to Jan Lieskovsky from comment #7) > > > %description > > The scap-security-guide project provides guide for configuration of the > > system from final system's security point of view. The guidance is specified > > in the Security Content Automation Protocol (SCAP) format and consitutes > > a catalog of practical hardening advice linked to government requirements > > where applicable. The project bridges the gap between generalized policy > > requirements and specific implementation guidelines. > > The scap-security-guide project provides [a] guide for configuration of the > system from [the] final system's security point of view. The guidance is > specified > in the Security Content Automation Protocol (SCAP) format and cons[t]itutes > a catalog of practical hardening advice[,] linked to government requirements > where applicable. The project bridges the gap between generalized policy > requirements and specific implementation guidelines. > > > Fixed - hopefully better now. > I think one additional sentence, which gives an indication how this is to be > used, would be great. Something like "The administrator can use ... from > openscap-utils or openscap-workbench to verify that the system conforms to > guidelines." Or something like that, because the name "-guide" suggests that > this is just documentation. Now it reads like: %description The scap-security-guide project provides a guide for configuration of the system from the final system's security point of view. The guidance is specified in the Security Content Automation Protocol (SCAP) format and constitutes a catalog of practical hardening advice, linked to government requirements where applicable. The project bridges the gap between generalized policy requirements and specific implementation guidelines. The Fedora system administrator can use the oscap CLI tool from openscap-utils package, or the scap-workbench GUI tool from scap-workbench package to verify that the system conforms to provided guideline. Refer to scap-security-guide(8) manual page for further information. Let me know. > > > > Gzipping of manpages will be done automatically, just copy it into the right > > > place. If the compression method changes, spec will not have to be adjusted. > > > > Fixed. > > > > > > > > Drop the chcon. Every package I have seen installs man pages without this. > > > > > > Drop %clean. > > > > > > Change .gz to *. in %files, so that it works if the compression changes. > > > > All three of the above fixed. Please have a look at new version. > Looks fine Thanks. . > > > > Fedora 19 version is hardcoded in various places. Is the package really so > > > version specific, that it must be specific for each version of Fedora? You > > > most certainly want to build this for F20 and rawhide too... > > > > The original motivation for this was to have a way / possibility how to > > distinguish cases, when for example Fedora18 and Fedora19 wouldn't have the > > same content (IOW there would be certain Fedora release specific rules). > > > > But after internal discussion we have agreed to handle this on the level > > of XCCDF content definition, so removed the hard-coded Fedora release version > > from final files path, provided by package (though still left it in > > file names generated from SSG Makefile as at the moment not sure having for > > example universal ssg-fedora-xccdf.xml file would cover all cases. We might > > change this in the future yet if the reality shows all cases [scanning > > Fedora18 guest on Fedora19 host] would be still possible while having this > > filenames scheme). > > > > > > > > Source refers to your personal page. Why can't you use an "real" URL like > > > https://git.fedorahosted.org/cgit/scap-security-guide.git/snapshot/scap- > > > security-guide-d478d863b4166d105dbdd1b577d27edb3f847a86.tar.bz2? This has > > > the advantage that it's easier to see the origin of sources. > > > > Agree this way the tarball source might be more transparent to final users. > > Though as of right now didn't find a way how to successfully predict future > > git commit's id (in the moment i am commiting the change to local repository > > don't know the id yet. Editing the spec file afterwards, committing again > > and squashing / merging the change from latest commit into previous one [in > > order the source URL to be correct] generates a new commit id. > > > > So far didn't find a way how to know next upcoming Git commit id in the > > moment of git commit (IOW not to need yet another one just to note the > > correct source URL in the spec file from the previous commit). > > > > Not to mention, that patches posted to scap-security-guide mailing list > > require review, and sometimes happens someone else commits my change from > > their local version of the Git repository (so even if i would overcome the > > previous point, the source URL might result being invalid after certain > > commits). > > > > Long story short for now I have left it point to my personal page on FP.org. > OK, I wasn't aware that this is all generated in this way. If current > arrangement works for you, that's fine. Ok, good. > > > > Directories without known owners: /usr/share/xml/scap/ssg/fedora, > > > /usr/share/xml, /usr/share/xml/scap, /usr/share/xml/scap/ssg/fedora/19, > > > /usr/share/xml/scap/ssg > > > > While I would like to apply this proposal, not sure how to achieve it - can > > you hint? Should scap-security-guide package create new dedicated user and > > change ownership on those files them to be owned by that new user afterwards? > > > > Just OOC what's wrong with those XML files being owned by root? AFAIHL no > > package providing content under /usr/share/xml/* changes ownership of those > > by-package newly provided files. > This is about "owning" in the sense of RPM package ownership: > currently, when I do 'rpm -qf /usr/share/xml/scap', rpm tell me that the > directory is unowned. This means that if I uninstall the package, the > directory won't be deleted. Ah, right, good point. > > repoquery is quite useful in researching ownership. > > Basically, you should add 'Requires: xml-common', because it owns > /usr/share/xml, and change %{_datadir}/xml/scap/ssg/fedora/* to > %{_datadir}/xml/scap. This way all files and directories should be "owned". Thanks, updated / fixed this point. > > > > Hm, binary package requires openscap-utils, which in turn requires openscap, > > > totalling 2.8 MB. Why does this requirement exist? > > > > Because the proposed scap-security-guide package provides only SCAP XML > > content (i.e. set of rules) for scanning Fedora hosts / systems. But the > > tools actually performing the scan come from openscap-utils (oscap CLI tool) > > or scap-workbench (scap-workbench GUI tool) packages, which in turn relies > > on openscap package. > > > > Not sure how this point could be solved without depending on those packages. > OK, that's fine then. Ok, good. Thanks. > > One last question: can the .html file be installed as %doc? > This would make it much easier to find for the user. With unversioned > docdirs [1] the path would be something like > /usr/share/doc/scap-security-guide/ssg-fedora-guide.html. > > [1] https://fedoraproject.org/wiki/Changes/UnversionedDocdirs Some internal negotiation was needed due this one, but at the end I have made the HTML form of the guide to be stored under the %doc directory, as you wanted. So this should be fixed too. Please have a look. Together with that simplified the core location a bit. Originally there was: ../fedora/content/*.xml ../fedora/guide/*.html New version contains just: ../fedora/*.xml (IOW removed the content subdir) Also, removed the 'fedora19' from OVAL / XCCDF filenames, so new version produces just: ssg-fedora-xccdf.xml, ssg-fedora-oval.xml etc. Let me know your thoughts on this. Thank you a lot. Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
Looks fine now. Rpmlint only complains about spelling, all false positives. Note that scap-secuirity-guide(8) still refers to the old path (with /content/). Package is APPROVED.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #10) > Looks fine now. Thank you, Zbigniew. > > Rpmlint only complains about spelling, all false positives. Yeah, noticed those yesterday, but those were just red herrings. > > Note that scap-secuirity-guide(8) still refers to the old path (with > /content/). Thank you, good catch. Fixed now yet: Spec URL: http://fedorapeople.org/~jlieskov/scap-security-guide.spec SRPM URL: http://fedorapeople.org/~jlieskov/scap-security-guide-0.1-3.rc3.fc19.src.rpm > > Package is APPROVED. Thank you, much appreciated. Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
Jan, please add the fedora‑cvs? flag!
New Package SCM Request ======================= Package Name: scap-security-guide Short Description: Security guidance and baselines in SCAP formats Owners: jlieskov Branches: f18 f19 f20 InitialCC: jlieskov pvrabec
Git done (by process-git-requests).
scap-security-guide-0.1-3.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/scap-security-guide-0.1-3.fc20
scap-security-guide-0.1-3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/scap-security-guide-0.1-3.fc19
scap-security-guide-0.1-3.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/scap-security-guide-0.1-3.fc18
scap-security-guide-0.1-3.fc20 has been pushed to the Fedora 20 testing repository.
Package Change Request ====================== Package Name: scap-security-guide New Branches: el6 Owners: jlieskov InitialCC: pvrabec swells [The Fedora SCAP content has been already packaged for Fedora 18, Fedora 19, and upcoming Fedora 20. We need yet to package SCAP content for Red Hat Enterprise Linux 6: https://git.fedorahosted.org/cgit/scap-security-guide.git/tree/RHEL6 for EPEL6 repository yet. The package name will be the same, just the *.spec file's changelog entries and content would (slightly) differ. Thank you, Jan.]
Git done (by process-git-requests). Left swells of InitialCC, not in FAS, can be added later.
(In reply to Jon Ciesla from comment #20) > Git done (by process-git-requests). > > Left swells of InitialCC, not in FAS, can be added later. Hi Jon, my FAS username is "shawndwells" Thanks!
I see you just got sponsored, so you can add yourself in pkgdb now.
scap-security-guide-0.1-3.fc18 has been pushed to the Fedora 18 stable repository.
scap-security-guide-0.1-3.fc19 has been pushed to the Fedora 19 stable repository.
scap-security-guide-0.1-15.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/scap-security-guide-0.1-15.el6
scap-security-guide-0.1-15.el6 has been pushed to the Fedora EPEL 6 testing repository.
scap-security-guide-0.1-15.el6 has been pushed to the Fedora EPEL 6 stable repository.
scap-security-guide-0.1-3.fc20 has been pushed to the Fedora 20 stable repository.