Description of problem: It's possible that packages reach a dangerous state and are orphaned due to unavailable/unresponsive maintainers or security issues. The administrator is not always aware of such problems. This is a RFE for a dnf plugin, which will help in such cases by identifying those dangerous packages and warning the user about them. A very rough description is available in https://sparkslinux.wordpress.com/2015/03/26/for-discussion-orphaned-package-in-fedora/ "The idea" part. I'd like to hear your opinion about this, especially with regards to implementation details like file format or possible problems you anticipate.
Stephan, can you please answer if oyu are willing to work on this (and reuse the Michal's research) or not? Otherwise I am giving it a low prio with little no to change of having it done.
Sorry! I can't tell you right now if I'll be able to implement this. It depends on whether or not I can get this approved as a "personal goal", but I would estimate that this is at least a quarter year away. I could ask around if somebody else from the Fedora Security Team can do this earlier. Creating a basic prototype checking the NVR of a single package using operators like <, >, <=, >=, == shouldn't be too hard. But I assume that there are corner cases that will likely need to operate on more than one package at a time with logic operators like AND and OR. Especially with libraries and other dependencies things will then become complicated quite quickly. I'm not sure if we should figure all of this out beforehand, or if we should use the simplest working thing and extend it as we go.
Nice to have...
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
I believe that the request is blocked by absence of database or metadata that would contain information about problematic packages. In several cases the requested plugin could be replaced by updateinfo command. If the package has a security issue then updateinfo metadata could mention that. I am really sorry but I don't think that the feature is deliverable. PS: delivering information about broken packages in RPM would be not practical, because data installed could get outdated very easily - install operation uses metadata, but information about problems would be available after install.