what’s the difference between the issue not being reported and the issue not being fixed because it’s not seen as a priority
Triaging and investigation take time. Plus having a bunch of open security issues even if they’re not critical destroys public confidence in the software
Sure, but if it wasn’t triaged why consider it “medium impact”? I feel when tight on resources, it’s best to default to “low priority” for all issues whose effect (ie. to the end-user, or to the software depending on it) isn’t clearly scoped and explained by the reporter. If the reporters (or those affected) have not done the job to make it easy to quickly see why it’s important to have this fixed then it’s probably not so important for them to have it fixed. Some projects even have bots that automatically close issues whenever there has not been activity for a certain time (though I’d prefer labeling it / categorizing as “low engagement” or something so it can be filtered out when swamped, instead of simply closing it).
About “public confidence”, I feel that this would rather be “misplaced confidence” if it’s based on a number that is “massaged” to hide issues. Also this is an open source project we are talking about, there isn’t an investment fund behind it or a need for people to have absolute loyalty or blind trust. The code is objectively there, the trust should never be blind. If there wasn’t a long list of reports I’d be more suspicious of a project as popular, frequently updated & ubiquitous as ffmpeg. Specially if they are (allegedly) not triaged. Anyone who decides to choose ffmpeg based on the number of issues open without actually investigating from their end how relevant that number actually is… well… they can go look for a different software.
Triaging and investigation take time. Plus having a bunch of open security issues even if they’re not critical destroys public confidence in the software
Sure, but if it wasn’t triaged why consider it “medium impact”? I feel when tight on resources, it’s best to default to “low priority” for all issues whose effect (ie. to the end-user, or to the software depending on it) isn’t clearly scoped and explained by the reporter. If the reporters (or those affected) have not done the job to make it easy to quickly see why it’s important to have this fixed then it’s probably not so important for them to have it fixed. Some projects even have bots that automatically close issues whenever there has not been activity for a certain time (though I’d prefer labeling it / categorizing as “low engagement” or something so it can be filtered out when swamped, instead of simply closing it).
About “public confidence”, I feel that this would rather be “misplaced confidence” if it’s based on a number that is “massaged” to hide issues. Also this is an open source project we are talking about, there isn’t an investment fund behind it or a need for people to have absolute loyalty or blind trust. The code is objectively there, the trust should never be blind. If there wasn’t a long list of reports I’d be more suspicious of a project as popular, frequently updated & ubiquitous as ffmpeg. Specially if they are (allegedly) not triaged. Anyone who decides to choose ffmpeg based on the number of issues open without actually investigating from their end how relevant that number actually is… well… they can go look for a different software.