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