Closed estebancrw closed 9 years ago
ikeydoherty
commented
9 years ago This is true. :) I'd rather not see abandoned patches but I can understand this can happen.. When we analyse the SRPMs we rely on the patches being present in the src.rpm - but we won't know if you've applied them :) For a .spec it could be done. Could you email me a link/example/ref so I can get working on it and ensure its then validated?
Thanks :)
estebancrw
commented
9 years ago Sure thing, will do in a minute :)
ikeydoherty
commented
9 years ago Many thanks :) Figured we can use the same field we use for srpm checking here, build a table while scanning the .spec to map Patch: %patch. I'll likely make it a flag to the tool because this could potentially be more expensive.
ikeydoherty
commented
9 years ago Going for default behaviour, because it's sane. :) Please test and let me know it works correctly for you
estebancrw
commented
9 years ago Pulled the changes, and then tried with the same package. Now when using the tool it says that all patches are broken, and that the CVE patch is not being applied on a spec file that actually applies the CVE patch.
The error message it outputs per patch is: 'directory/package.spec is broken - applying "patch[number] -p1" which isn't declared'
ikeydoherty
commented
9 years ago When you verify this, please close it. Want to make sure I've not broken anything there :)
estebancrw
commented
9 years ago The tool now correctly outputs when a CVE patch has or hasn't been added in the spec file. I am closing this issue. :)
ikeydoherty
commented
9 years ago Awesome - thanks :D (Btw love the idea, makes more sense. Wondering if I should rip the code out to detect abandoned patches in trees =))
If a CVE patch is in the same folder as the spec file, even when the spec file is not actually patching it, the tool still says that the CVE has been patched.
That is, the spec file does not have: ... Patch: .patch
...
%prep
%patch -p1