[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#853903: RFS: scap-security-guide/0.1.31-6 [ITP] -- security guides and conformity checks using SCAP standard



Hi Gianfranco,

Le 2017-02-02 18:13, Gianfranco Costamagna a écrit :
control: owner -1 !
control: tags -1 moreinfo
control: forcemerge 853903 852415


Hello

lets see a preliminary review:

1) one single changelog entry, targeting sid and initial release (Closes: #ITP)
2) debian/rules, lots of comented out noise, please remove
3) copyright not in dep-5 format, and some stuff is LGPL-2+ e.g.
shared/transforms/pcidss/something
some other is MIT (Ubuntu/16.04 some subdirs), something else
CC-BY-SA, JQuery license,
Public domain, GPL and probably something more


4) compat is now 10, please bump also debhelper to >=10
5) how do you use libopenscap8? dynamic loading or linking?
if you link it, just build-depend on the -dev package and add
shlibs:Depends to the runtime dependencies
(avoiding nightmares on libopenscap8 SONAME changes)
6) quilt dependency is useless, and probably also some others, e.g.
coreutils, part of Essentials packages
(you can't remove it on a system)
also probably sed and not sure about the others (to find them I
usually try to remove them on my system)
7) ssg-base depends on libopenscap8
everything else depends on ssg-base, so transitively also against
libopenscap8 making it useless to be replicated,
right?


8) does not build twice in a row (not a real issue)
9) debian/ssg-base.prerm what???
10) debian/README <--- useless?
11) debian/README.Debian might be made more aware of directories, e.g.
/usr/share/ssg" might save some sed'ing before running the command,
unless you want to change packagename in the near future


Thank's for this reply. Here is the various updates/answers:

1) Exact, targeting sid only by now.
2) Corrected. No more noise in rules file
3) Corrected. All various upstream and debian files copyrights and licenses are defined properly in debian/copyright
4) Corrected.
5) libopenscap is used as a binary at build time (using oscap xccdf ... to generate guides and benchmarks). There is no link or dynamic loading. libopenscap is not a library but a binary tools suite (even if its name make it look like a lib :-) )
6) Corrected.
7) Corrected.
8) Ok. I have to check why. I build through gbp and pbuilder so I didn't see this issue 9) Deleted that file. Waiting for upstream changelog instead of using inproper spec file. I've posted an issue in the upstream repository to have a real changelog file.
10) File deleted.
11) I've updated the file to be more explicit. Yet I think that it still need some more content.


http://debomatic-amd64.debian.net/distribution#unstable/scap-security-guide/0.1.31-6/buildlog

since this is just some xml files that are needed by libopenscap8...
what about suggesting this new package or merging it on that above tool?

I don't undestand why the tool and the profiles have to be kept separate

Why libopenscap8 & scap-workbench & scap-security-guide are separated:

libopenscap8 is a set of tool using the SSG benchmarks to validate the current OS security policy in comparison with official ones such as PCI-DSS, NIST SP-800, ANSSI best practices, etc. Nevertheless, the following case exists:
1) Hosting security policy in a security server
2) Hosting libopenscap on various targets
3) Launching security policy validation on remote targets automatically using ansible, foreman, oscap-ssh or other to validate the policy of each remote host from a single policy server and aggregate the results

In that case, the security policy server only hosts the security policies, not the libopenscap8. You will have something like that:
https://www.theforeman.org/plugins/foreman_openscap/0.4/

I've updated the scap-security-guide package to set libopenscap as "Recommends" instead of Depends at runtime for all binary pacakges.

All these updates have been made in the 0.31.1-8 release of the package:

https://mentors.debian.net/debian/pool/main/s/scap-security-guide/scap-security-guide_0.1.31-8.dsc


Regards,

--
Philippe THIERRY
Doctor - Engineer
RT and hardened Embedded Systems
+33(0)6.64.16.97.30


Reply to: