[Bug 1018905] New: Review Request: scap-security-guide - Security guidance and baselines in SCAP formats
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
Bug ID: 1018905 Summary: Review Request: scap-security-guide - Security guidance and baselines in SCAP formats Product: Fedora Version: rawhide Component: Package Review Severity: medium Priority: medium Assignee: nobody@fedoraproject.org Reporter: jlieskov@redhat.com QA Contact: extras-qa@fedoraproject.org CC: notting@redhat.com, package-review@lists.fedoraproject.org
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
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
Yohan Graterol yohangraterol92@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |yohangraterol92@gmail.com
--- Comment #1 from Yohan Graterol yohangraterol92@gmail.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
Simone Caronni negativo17@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |negativo17@gmail.com
--- Comment #2 from Simone Caronni negativo17@gmail.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
--- Comment #3 from Jan Lieskovsky jlieskov@redhat.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zbyszek@in.waw.pl Assignee|nobody@fedoraproject.org |zbyszek@in.waw.pl Flags| |fedora-review?
--- Comment #4 from Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl --- 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-secu... 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?
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
--- Comment #5 from Peter Vrabec pvrabec@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
--- Comment #6 from Jan Lieskovsky jlieskov@redhat.com --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
--- Comment #7 from Jan Lieskovsky jlieskov@redhat.com --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
--- Comment #8 from Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
--- Comment #9 from Jan Lieskovsky jlieskov@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
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|fedora-review? |fedora-review+
--- Comment #10 from Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
--- Comment #11 from Jan Lieskovsky jlieskov@redhat.com --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
--- Comment #12 from Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl --- Jan, please add the fedora‑cvs? flag!
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
Jan Lieskovsky jlieskov@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags| |fedora-cvs?
--- Comment #13 from Jan Lieskovsky jlieskov@redhat.com --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
Jon Ciesla limburgher@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|fedora-cvs? |fedora-cvs+
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
--- Comment #14 from Jon Ciesla limburgher@gmail.com --- Git done (by process-git-requests).
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |MODIFIED
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
--- Comment #15 from Fedora Update System updates@fedoraproject.org --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
--- Comment #16 from Fedora Update System updates@fedoraproject.org --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
--- Comment #17 from Fedora Update System updates@fedoraproject.org --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|MODIFIED |ON_QA
--- Comment #18 from Fedora Update System updates@fedoraproject.org --- scap-security-guide-0.1-3.fc20 has been pushed to the Fedora 20 testing repository.
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
Jan Lieskovsky jlieskov@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|fedora-cvs+ |fedora-cvs?
--- Comment #19 from Jan Lieskovsky jlieskov@redhat.com --- 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.]
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
Jon Ciesla limburgher@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|fedora-cvs? |fedora-cvs+
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
--- Comment #20 from Jon Ciesla limburgher@gmail.com --- Git done (by process-git-requests).
Left swells of InitialCC, not in FAS, can be added later.
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
--- Comment #21 from Shawn Wells swells@redhat.com --- (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!
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
Jon Ciesla limburgher@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |limburgher@gmail.com
--- Comment #22 from Jon Ciesla limburgher@gmail.com --- I see you just got sponsored, so you can add yourself in pkgdb now.
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ON_QA |CLOSED Fixed In Version| |scap-security-guide-0.1-3.f | |c18 Resolution|--- |ERRATA Last Closed| |2013-10-31 23:53:22
--- Comment #23 from Fedora Update System updates@fedoraproject.org --- scap-security-guide-0.1-3.fc18 has been pushed to the Fedora 18 stable repository.
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed In Version|scap-security-guide-0.1-3.f |scap-security-guide-0.1-3.f |c18 |c19
--- Comment #24 from Fedora Update System updates@fedoraproject.org --- scap-security-guide-0.1-3.fc19 has been pushed to the Fedora 19 stable repository.
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
--- Comment #25 from Fedora Update System updates@fedoraproject.org --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |ON_QA Resolution|ERRATA |--- Keywords| |Reopened
--- Comment #26 from Fedora Update System updates@fedoraproject.org --- scap-security-guide-0.1-15.el6 has been pushed to the Fedora EPEL 6 testing repository.
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ON_QA |CLOSED Fixed In Version|scap-security-guide-0.1-3.f |scap-security-guide-0.1-15. |c19 |el6 Resolution|--- |ERRATA Last Closed|2013-10-31 23:53:22 |2013-11-04 12:35:41
--- Comment #27 from Fedora Update System updates@fedoraproject.org --- scap-security-guide-0.1-15.el6 has been pushed to the Fedora EPEL 6 stable repository.
https://bugzilla.redhat.com/show_bug.cgi?id=1018905
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed In Version|scap-security-guide-0.1-15. |scap-security-guide-0.1-3.f |el6 |c20
--- Comment #28 from Fedora Update System updates@fedoraproject.org --- scap-security-guide-0.1-3.fc20 has been pushed to the Fedora 20 stable repository.
package-review@lists.fedoraproject.org
-
Red Hat Bugzilla