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
