https://bugzilla.redhat.com/show_bug.cgi?id=1018905
--- Comment #9 from Jan Lieskovsky <jlies...@redhat.com> --- (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 -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/package-review
