-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Redhatrelease detector #229
Conversation
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Due to the detector registration and fact that their in a non-ordered map, it is random whether the osrelease or redhatrelease detector would hit. And likely resulted in alternately formatted namespace strings. This change causes the osrelease to not detect when data has centos-release or redhat-release, which is not _great_ because if the redhatrelease detector is not compiled in, then that would not be a fallback that the osrelease detector could rely on. :-\ Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Until quay#193 is merged, having vulnerabilities that are tagged both rhel and centos would duplicate in the database or use a change that requires a migration. But presently due to the fetcher logic, the rhel provided vulnerabilities are labelled for centos, and then the namespace does not match and therefore not tested against. So until such a day that a vulnerability could have both rhel and centos label, then hack this in. It'll accomplish the same during this interim. Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
bump |
LGTM. Is this causing enough of an issue that it should be backported into stable? |
Oh that is an idea. Let me check On Wed, Aug 31, 2016, 18:44 Jimmy Zelinskie notifications@github.com
|
@jzelinskie Any idea when the next release will occcur that would include this if it isn't backported? |
@brianwcook realistically on the order of months. We need to spend some time to making sure we get the multiple-namespace support in properly and make a few other breaking changes to clean things up. Doing so requires a large amount of thought around the future of project's architecture and our maintainers currently have a lot on their plates with other projects. Backporting should be a simple |
@jzelinskie in that case, then yes it would be great to have it backported to stable! |
Due to the detector registration and fact that their in a non-ordered
map, it is random whether the osrelease or redhatrelease detector would
hit. And likely resulted in alternately formatted namespace strings.
This change causes the osrelease to not detect when data has
centos-release or redhat-release, which is not great because if the
redhatrelease detector is not compiled in, then that would not be a
fallback that the osrelease detector could rely on. :-\
Until #193 is merged, having
vulnerabilities that are tagged both rhel and centos would duplicate in
the database or use a change that requires a migration.
But presently due to the fetcher logic, the rhel provided
vulnerabilities are labelled for centos, and then the namespace does not
match and therefore not tested against.
So until such a day that a vulnerability could have both rhel and centos
label, then hack this in. It'll accomplish the same during this interim.