RFE: Running createrepo_c on individual update packages
Michael Schwendt
mschwendt at fedoraproject.org
Thu Oct 22 15:16:03 UTC 2015
On Thu, 22 Oct 2015 08:46:13 -0600, Tim Flink wrote:
> > How much effort would it be to not only run "rpmlint" on individual
> > 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 [1] would end up being a better use of time - I'd
> 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.
>
> Tim
>
> [1] https://github.com/default-to-open/rpmgrill
Haven't heard about that before.
rpmlint cannot detect the problem. So far it doesn't "see" the bad value
at all.
rpmbuild could detect the problem, but doesn't -> bug 1251453
repoclosure cannot detect the problem, because it's not copied into the
repo metadat.
createrepo_c detects the problem (as part of converting RPM metadata into
repo metadata), but hides the invalid input data instead of rejecting it.
More information about the qa-devel
mailing list