On Thu, 22 Oct 2015 08:46:13 -0600, Tim Flink wrote:
> How much effort would it be to not only run "rpmlint"
> update packages added via bodhi but also "createrepo_c"?
Assuming that I understand what you're asking, it wouldn't be a lot of
effort but it would take enough to make me ask how often this would
catch something that wouldn't otherwise be caught.
Nobody knows. It has happened a few times over a period of years, but it
has been news to me that the creatrepo* tools create repo metadata which
make it impossible to detect the problem with tools like repoclosure.
It also depends on what other error conditions createrepo_c can detect
(and how often it runs into its own bugs).
Primarily, I'd like to see createrepo_c reject packages it cannot handle
instead of skipping invalid input data it fails to parse.
Tomas Mlcoch on devel@ list argues that it is not an option for createrepo_c
to exit with error condition, because that might be exploited by packagers
for a denial-of-service attack on the updates repo compose process and
then would require admins to remove the broken packages.
I wonder if rpmgrill  would end up being a better use of time -
love to see that included as a regular task but haven't made the time
to get that working yet.
I'm not sure if this particular issue is included in the current
battery of things run through rpmgrill but AFAIK, more checks can be
added through extending or adding plugins.
Haven't heard about that before.
rpmlint cannot detect the problem. So far it doesn't "see" the bad value
rpmbuild could detect the problem, but doesn't -> bug 1251453
repoclosure cannot detect the problem, because it's not copied into the
createrepo_c detects the problem (as part of converting RPM metadata into
repo metadata), but hides the invalid input data instead of rejecting it.