https://bugzilla.redhat.com/show_bug.cgi?id=1018905 --- Comment #8 from Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> --- (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 -- 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