-
Notifications
You must be signed in to change notification settings - Fork 78
CVE not patched in spec file but patch in the same folder outputs patched #6
Comments
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 :) |
Sure thing, will do in a minute :) |
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. |
This resolves issue #6 - but would require further testing Signed-off-by: Ikey Doherty <[email protected]>
Going for default behaviour, because it's sane. :) Please test and let me know it works correctly for you |
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: |
Signed-off-by: Ikey Doherty <[email protected]>
When you verify this, please close it. Want to make sure I've not broken anything there :) |
The tool now correctly outputs when a CVE patch has or hasn't been added in the spec file. I am closing this issue. :) |
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
The text was updated successfully, but these errors were encountered: