Bug 1018905 - Review Request: scap-security-guide - Security guidance and baselines in SCAP formats
Summary: Review Request: scap-security-guide - Security guidance and baselines in SCAP...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Zbigniew Jędrzejewski-Szmek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-14 16:30 UTC by Jan Lieskovsky
Modified: 2013-11-10 07:11 UTC (History)
9 users (show)

Fixed In Version: scap-security-guide-0.1-3.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-11-04 17:35:41 UTC
zbyszek: fedora-review+
gwync: fedora-cvs+


Attachments (Terms of Use)

Description Jan Lieskovsky 2013-10-14 16:30:52 UTC
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

Comment 1 Yohan Graterol 2013-10-14 16:55:14 UTC
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.

Comment 2 Simone Caronni 2013-10-14 17:16:29 UTC
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.

Comment 3 Jan Lieskovsky 2013-10-14 17:29:57 UTC
(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.

Comment 4 Zbigniew Jędrzejewski-Szmek 2013-10-14 23:48:12 UTC
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?

Comment 5 Peter Vrabec 2013-10-15 09:11:05 UTC
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.

Comment 6 Jan Lieskovsky 2013-10-15 10:05:13 UTC
(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

Comment 7 Jan Lieskovsky 2013-10-15 16:33:05 UTC
(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

Comment 8 Zbigniew Jędrzejewski-Szmek 2013-10-15 18:17:46 UTC
(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

Comment 9 Jan Lieskovsky 2013-10-16 16:26:48 UTC
(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

Comment 10 Zbigniew Jędrzejewski-Szmek 2013-10-16 17:26:02 UTC
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.

Comment 11 Jan Lieskovsky 2013-10-17 14:36:21 UTC
(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

Comment 12 Zbigniew Jędrzejewski-Szmek 2013-10-21 17:06:43 UTC
Jan, please add the fedora‑cvs? flag!

Comment 13 Jan Lieskovsky 2013-10-21 18:55:24 UTC
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

Comment 14 Gwyn Ciesla 2013-10-21 19:08:51 UTC
Git done (by process-git-requests).

Comment 15 Fedora Update System 2013-10-22 15:43:43 UTC
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

Comment 16 Fedora Update System 2013-10-22 15:44:45 UTC
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

Comment 17 Fedora Update System 2013-10-22 15:45:18 UTC
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

Comment 18 Fedora Update System 2013-10-22 18:54:45 UTC
scap-security-guide-0.1-3.fc20 has been pushed to the Fedora 20 testing repository.

Comment 19 Jan Lieskovsky 2013-10-24 15:10:44 UTC
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.]

Comment 20 Gwyn Ciesla 2013-10-24 15:15:35 UTC
Git done (by process-git-requests).

Left swells of InitialCC, not in FAS, can be added later.

Comment 21 Shawn Wells 2013-10-25 01:00:17 UTC
(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!

Comment 22 Gwyn Ciesla 2013-10-25 17:19:56 UTC
I see you just got sponsored, so you can add yourself in pkgdb now.

Comment 23 Fedora Update System 2013-11-01 03:53:22 UTC
scap-security-guide-0.1-3.fc18 has been pushed to the Fedora 18 stable repository.

Comment 24 Fedora Update System 2013-11-01 03:54:38 UTC
scap-security-guide-0.1-3.fc19 has been pushed to the Fedora 19 stable repository.

Comment 25 Fedora Update System 2013-11-01 12:28:40 UTC
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

Comment 26 Fedora Update System 2013-11-01 21:06:58 UTC
scap-security-guide-0.1-15.el6 has been pushed to the Fedora EPEL 6 testing repository.

Comment 27 Fedora Update System 2013-11-04 17:35:41 UTC
scap-security-guide-0.1-15.el6 has been pushed to the Fedora EPEL 6 stable repository.

Comment 28 Fedora Update System 2013-11-10 07:11:41 UTC
scap-security-guide-0.1-3.fc20 has been pushed to the Fedora 20 stable repository.


Note You need to log in before you can comment on or make changes to this bug.