Version Tagged as 2.1.1 is not 2.1.1

[eyespies]

I just started using this cookbook and the corresponding Inspec tests (thank you for these!). I added the cookbook and ran the tests, however the tests fail with the following:

  ✔  os-09: Check for .rhosts and .netrc file
     ✔  [] should be empty
  ×  os-10: CIS: Disable unused filesystems (8 failed)
     ×  File /etc/modprobe.d/dev-sec.conf content should match "install cramfs /bin/true"
     expected nil to match "install cramfs /bin/true"
     ×  File /etc/modprobe.d/dev-sec.conf content should match "install freevxfs /bin/true"
     expected nil to match "install freevxfs /bin/true"
     ×  File /etc/modprobe.d/dev-sec.conf content should match "install jffs2 /bin/true"
     expected nil to match "install jffs2 /bin/true"
     ×  File /etc/modprobe.d/dev-sec.conf content should match "install hfs /bin/true"
     expected nil to match "install hfs /bin/true"
     ×  File /etc/modprobe.d/dev-sec.conf content should match "install hfsplus /bin/true"
     expected nil to match "install hfsplus /bin/true"
     ×  File /etc/modprobe.d/dev-sec.conf content should match "install squashfs /bin/true"
     expected nil to match "install squashfs /bin/true"
     ×  File /etc/modprobe.d/dev-sec.conf content should match "install udf /bin/true"
     expected nil to match "install udf /bin/true"
     ×  File /etc/modprobe.d/dev-sec.conf content should match "install vfat /bin/true"
     expected nil to match "install vfat /bin/true"

I checked my local cookbook in ~/.berkshelf/os-hardening-2.1.1/ and the metadata.json does show it as version 2.1.1, however it is missing all of the code / attributes that are in the master branch to disable those file systems are not in the Tag 2.1.1.

It seems that the metadata.rb was merged / committed to that tag, but the actual changes were committed to master and not the tag. Would it make sense to bump the version to 2.1.2 and create a new tag off master for 2.1.2 so that the changes are published properly?

[artem-sidorenko]

@eyespies thanks for this issue!

Its not related to tagging, the problem you are facing here is fixed with GH-169, which is not part of 2.1.1. How it looks like: you are using the inspec tests from master of linux-baseline (which includes this tests), but in the same time you use the 2.1.1 version of this cookbook from supermarket (which does not have the FS blacklisting implementation). As a workaround you can use the master branch of this cookbook, or disable this tests in the linux-baseline.

The idea was to have GH-169 as part of new major release (3.0.0), as this is a new and unexpected behavior for minor/patch releases. I also want to have some more changes for that. @eyespies I'll close this issue, feel free to reopen/comment if needed

@atomic111 @chris-rock FYI, mismatch of versioning between tests and implementation. I remember we had such issues somewhere else in the past

[eyespies]

@artem-sidorenko - thank you for the response. So if I understand, GH-169 is not yet in a released version, correct? And until it is released, I need to not only add chef-os-hardening to my metadata.rb, but also add a custom reference to the master branch of this repo in Berksfile so that Berks pulls the latest code from master (which is also listed as version 2.1.1)?

If so, I think the confusion is that GH-169 is committed to master and when the merge was done for GH-169, the version number in metadata.rb was not bumped, so you have the Supermarket version showing 2.1.1 (without GH-169 commits) and then you have the master branch (with GH-169 code commits) showing 2.1.1, but it is not accessible from Chef Supermarket.

Shouldn't GH-169 have included a version bump? Or is this where you get to tell me to read the CONTRIBUTING file before asking so many questions ;) ?

[artem-sidorenko]

@artem-sidorenko - thank you for the response. So if I understand, GH-169 is not yet in a released version, correct? And until it is released, I need to not only add chef-os-hardening to my metadata.rb, but also add a custom reference to the master branch of this repo in Berksfile so that Berks pulls the latest code from master (which is also listed as version 2.1.1)?

yes, yes

Shouldn't GH-169 have included a version bump? Or is this where you get to tell me to read the CONTRIBUTING file before asking so many questions ;) ?

@eyespies its okay to ask so many questions :) I do not think its covered in our CONTRIBUTING file. The release way is usually different for different projects/cookbooks:

• some cookbooks get always released after a single PR merge, so you always have a version bump after PR merge
• some cookbooks get released after a set of changes, where version bump is done at some point manually

The best way to determine the used release procedure in my eyes is to have a look to the git log. This cookbooks are handled this way:

• for small, backward compatible changes minor releases are done pretty fast
• for bugfixes, patch releases are done pretty fast
• everything else goes into a next major release
• In order to have it simple, similar to other cookbooks, we are not using any stable branches and parallel release maintenance.
• Version bump happens usually in the release commit, together with changelog update. This commit gets the git version tag and this commit is uploaded to the supermarket.

[robcoward]

Any chance of a version bump so that #169 can get released please ?

[artem-sidorenko]

@robcoward there are some PRs pending for review, there is also an upcoming PR with selinux feature. After they all are merged - there will be a new major release. Is it ok for you?

[robcoward]

Hi @artem-sidorenko thanks for the prompt reply. If its coming soon, I'm happy to wait 😃

It will be good to get the cookbook back inline with the inspec profile, with it remedying the issues highlighted by the tests. Your hard work is much appreciated.