Yeah, we have more. Definitely nice to have, we should put RPM -V checkup onto our scrum. I'd recommend to change component to Katello and push this upstream only.

I've discussed this failure already with jortel.  The alternative is to adjust the %postinstall script (removing the setfacl) and use the proper .spec syntax in %files.  However, this causes rpmlint to fail.

> 09:09 jortel: now I remember why I used setfacl instead of %attr, see: http://fpaste.org/x6F9/
> 09:10 jortel: setfacl "get around" these lint errors

Pick your poison.  I'm more comfortable with the verify error, than I am with rpmlint failures.  Any other thoughts?

From a support perspective, it is very very common to examine the output of rpm -V to detect causes of errors in a product.  That said it is not uncommon to have a set of files that you ignore because they always show up.  So while I'm not arguing for the going with the rpm lint error, it is one more 'exception' support will have to remember when supporting the product. 

One question i guess is does that directory NEED to be world writable ?  As that seems kinda bad.

Gathering rpm -V output is turned off by default for sosreport in RHEL 6, so this should not be a big deal.  Even if someone turns it on to collect -Va output, as this will just report an error for this package it should not be a show-stopper.

As long as we document this issue before it is fixed we should be fine.

*** Bug 813941 has been marked as a duplicate of this bug. ***

So i see it as this:

1.  The rpm requires a world writable directory
2.  rpm lint complains about this because world writable directories are bad
3.  We hacked around this to hush rpmlint (pushing the permission setting to %postinstall)
4.  Because we hacked around this rpm -V throws a warning.


I would argue that we shouldn't hack around this (step 3 is a mistake).  We are essentially ignoring what rpmlint is saying by making sure rpmlint can't see that we are making the rpm world writable which is BAD imho.  

Talking with jortel this should be fixed in a future version of gofer.  So to me rpmlint should complain until we upgrade to that version.

So i would argue that if its a blocker that rpmlint it throwing an error, then it is a blocker that we need to move to a newer version of gopher that does not require a world writable directory.

rpmlint is not customer facing so I would say that we have two choices.

1. Let rpmlint complain (thus rpm -V will not).
2. Update to a more secure version of gofer.

And what of the pulp issue where the UG are changing?

FYI Katello passes this test with only one exception. We "hack" seeds.rb script. Not sure if /var/log/katello is also right (we change permissions there using Puppet).

# rpm -V katello katello-common katello-cli katello-certs-tools katello-selinux katello-all katello-configure
..5....T.    /usr/share/katello/db/seeds.rb
SM5..UGT.  c /etc/httpd/conf.d/katello.conf
S.5..UGT.  c /etc/katello/katello.yml
S.5....T.  c /etc/katello/thin.yml
S.5....T.  c /etc/sysconfig/katello
.M.......    /var/log/katello

The primary offenders here are pulp, python-gofer and gofer.

Fixed in gofer around 0.68.
Tested with gofer 0.71 installed.  'rpm -V gofer python-gofer' reported not issues.

getting rid of 6.0.0 version since that doesn't exist

These bugs have been resolved in upstream projects for a period of months so I'm mass-closing them as CLOSED:UPSTREAM.  If this is a mistake feel free to re-open.