# John Helmert III <ajak@gentoo.org> (2022-11-27)
# Unmaintained upstream, several unresolved public vulnerabilities,
# Removal in 30 days. Bug #882773.
www-servers/boa
Shouldn't this process work a lot better?
If you wanted to encourage me to become a Gentoo developer and (among
other things) improve the lastriting process then you missed the mark,
in fact your behavior consistently remains one strong reason for me
to *not* become a Gentoo developer.
Shouldn't this process work a lot better?
Processes tend to work better when people are contributing towards
making the processes work better rather than complaining from their
comfy armchairs that they tend to confuse with thrones.
Michał Górny wrote:
Shouldn't this process work a lot better?
Processes tend to work better when people are contributing towards
making the processes work better rather than complaining from their
comfy armchairs that they tend to confuse with thrones.
LOL!
Are you honestly arguing that the Gentoo lastriting process relies on
third party contributions to work or improve? That would amount to
declaring Gentoo (developers) incapable of self-improvement, something
that would be absolutely unacceptable to say about any one or any group
of people.
If you feel that Gentoo is unsustainable like that then please think
about how you should react to it.
Instead of writing a passive aggressive response to my demonstration
of this process failure I wish that you would have drawn on your
knowledge of the process and the learnings in my mail to 1. educate
us on what gaps you see, if any, that caused this particular error,
and maybe even 2. suggest some improvements.
Expecting and/or demanding that from me because I dared describe a
symptom and question the process is neither reasonable nor fair nor
useful. Shooting the messenger reveals that you can't deal with the
message, but that's a you problem, it's not okay to project that onto
the messenger or anyone else.
If you wanted to encourage me to become a Gentoo developer and (among
other things) improve the lastriting process then you missed the mark,
in fact your behavior consistently remains one strong reason for me
to *not* become a Gentoo developer.
Kind regards
//Peter
John Helmert III wrote:
So much yapping on the mailing lists, and no response in the bug which triggered the last rites...
Apologies if I responed in the wrong forum. I thought on list would
be good, why are those mails on the list if not?
So, Peter, do you use Boa?
Not right now, but I have before and I might again.
If you do, what niche does it fill that isn't filled by anything else?
That's a strange question. Why should I agree with or even
reconfigure because of something that is in fact an error?
I ask you to revert the lastrite not because it would break a use
case of mine but because the CVEs do not apply to boa itself but to
some unknown appliance that uses boa to serve unknown buggy CGI scripts.
There are multiple CVEs for it, is it really on us to discriminate
between which CVEs are valid and which are not?
Yes.
You are obviously /not/ responsible for what bogus CVEs people may
report, but we're all responsible for the commits we create.
I assume that everyone wants to improve the overall state with each
commit - that we want to make things more correct since that's what
enables reliability, hence yes: it really is on every one of us to
verify our inputs before taking action on them.
We can't possibly hope to do that accurately in all cases.
Some times it will be easy, other times less easy.
In this case the CVEs could be dismissed by searching the source code
for the file names in the CVEs. Or by having experience with what the
package provides, in particular that it doesn't include any CGI scripts.
Maybe the accurate bigger picture is that no (current) Gentoo developer
knows enough about the package and thus can't be expected to action
such bogus CVEs correctly without a couple of minutes of investigation,
which would be too long, then I guess maintainer-needed is the most honest?
The mere existance of CVEs can not be reason enough for any change,
that would mean resignation to fear instead of encouraging rational
behavior as required to actually improve technology. It would also
create incentive for permanent denial-of-service attacks by way of
bogus CVEs manipulating people into incorrect lastrites and other
changes. I don't want that to become common.
My question about the lastriting process was not an attack but a
genuine inquiry. The answer I receive so far is something like
"it can't work better because we react indiscriminately to CVEs",
that's an honest answer (thank you!) but not great quality. Does
everyone mostly agree with that policy?
Thanks
//Peter
So much yapping on the mailing lists, and no response in the bug which triggered the last rites...
So, Peter, do you use Boa?
If you do, what niche does it fill that isn't filled by anything else?
There are multiple CVEs for it, is it really on us to discriminate
between which CVEs are valid and which are not?
We can't possibly hope to do that accurately in all cases.
..There are multiple CVEs for it, is it really on us to discriminate between which CVEs are valid and which are not?
Yes.
..We can't possibly hope to do that accurately in all cases.
Some times it will be easy, other times less easy.
Maybe the accurate bigger picture is that no (current) Gentoo developer knows enough about the package and thus can't be expected to action
such bogus CVEs correctly without a couple of minutes of investigation, which would be too long, then I guess maintainer-needed is the most honest?
No, when a package is believed to be vulnerable, it is not responsible
for us to just leave it as maintainer-needed, that's not an accurate reflection of the situation.
If you think the CVEs are invalid, maybe talk to upstream? Or MITRE?
Or anybody that isn't only a CVE downstream?
I also note that very few distributions package Boa:
https://repology.org/project/boa/versions
This is a good way to measure how many people care about the package
(and thus, its security health).
If the commercial distributions don't carry a package, nobody cares for
it, and thus security issues are unlikely to be tracked and handled well.
The mere existance of CVEs can not be reason enough for any change,
that would mean resignation to fear instead of encouraging rational behavior as required to actually improve technology.
That's not a real concern. We're not going to last rite something like
nginx simply because there's a CVE against it. In the case of Boa,
which doesn't seem to have been touched in approaching 20 years, the
impact of last rites is minimal.
The answer I receive so far is something like
"it can't work better because we react indiscriminately to CVEs",
that's an honest answer (thank you!) but not great quality. Does
everyone mostly agree with that policy?
It generally can't work better with MITRE being useless in many
cases. Yes, the CVEs seem garbage, but I can't say that
authoritatively, so I don't.
John Helmert III wrote:
There are multiple CVEs for it, is it really on us to discriminate between which CVEs are valid and which are not?
..Yes.
We can't possibly hope to do that accurately in all cases.
..Some times it will be easy, other times less easy.
Maybe the accurate bigger picture is that no (current) Gentoo developer knows enough about the package and thus can't be expected to action
such bogus CVEs correctly without a couple of minutes of investigation, which would be too long, then I guess maintainer-needed is the most honest?
No, when a package is believed to be vulnerable, it is not responsible
for us to just leave it as maintainer-needed, that's not an accurate reflection of the situation.
Do you continue to believe that boa has vulnerabilites involving files
and functionality (as mentioned by the maintainer mgorny in #882773#c1)
which do not exist in the package?
I wanted my mail to change that belief. If I've failed so far can you
tell me how I can accomplish it, ie. what it would take for you to
please revert the lastrite commit?
If you think the CVEs are invalid, maybe talk to upstream? Or MITRE?
The CVEs are obviously invalid and yes someone could contribute time
to clean up NVD but I honestly don't think that either upstream or
myself can reasonably be made responsible for invalid CVEs submitted
by third parties.
Or anybody that isn't only a CVE downstream?
I expect every downstream of everything to apply themselves in order to improve quality of what they consume, not reduce it. To be clear: It's
also not your job to improve NVD but at least don't lastrite in Gentoo because of invalid CVEs.
I also note that very few distributions package Boa:
https://repology.org/project/boa/versions
This is a good way to measure how many people care about the package
(and thus, its security health).
I disagree, that's only a good way to measure how many distributions care.
Each distribution has its own dynamic (but actually distributions also
tend to herd behavior) and especially commercial distributions are more
often than not bound by law to be driven only by profit, with *everything* else secondary. This includes software quality and/or "security health".
If the commercial distributions don't carry a package, nobody cares for
it, and thus security issues are unlikely to be tracked and handled well.
This seems based on an assumption that only commercial software has
high value? I could not disagree more with that.
But if we play out the argument then CVEs for packages not in many distributions would more likely be invalid than others. While true
in this case I don't find it convincing as a general conclusion.
These things can all be true at once:
1. a package is secure
2. the package is not popular
3. a CVE for the package is invalid but not (yet) rejected
4. another CVE for the package is valid (low severity; still secure)
Only 1. says something about "security health" (whatever that means).
I think it's both irresponsible and wrong to indiscriminately give
authority to CVEs. People are wrong on the internet all the time,
some even intentionally, it's not correct to blindly believe CVEs
any more than tweets.
The mere existance of CVEs can not be reason enough for any change,
that would mean resignation to fear instead of encouraging rational behavior as required to actually improve technology.
That's not a real concern. We're not going to last rite something like nginx simply because there's a CVE against it. In the case of Boa,
which doesn't seem to have been touched in approaching 20 years, the
impact of last rites is minimal.
All packages are equal but some are more equal than others? ;)
Again: Impact shouldn't matter, correctness should.
The answer I receive so far is something like
"it can't work better because we react indiscriminately to CVEs",
that's an honest answer (thank you!) but not great quality. Does
everyone mostly agree with that policy?
It generally can't work better with MITRE being useless in many
cases. Yes, the CVEs seem garbage, but I can't say that
authoritatively, so I don't.
What would convince you?
Thanks a lot
//Peter
John Helmert III wrote:
There are multiple CVEs for it, is it really on us to discriminate between which CVEs are valid and which are not?
..Yes.
We can't possibly hope to do that accurately in all cases.
..Some times it will be easy, other times less easy.
Maybe the accurate bigger picture is that no (current) Gentoo developer knows enough about the package and thus can't be expected to action
such bogus CVEs correctly without a couple of minutes of investigation, which would be too long, then I guess maintainer-needed is the most honest?
No, when a package is believed to be vulnerable, it is not responsible
for us to just leave it as maintainer-needed, that's not an accurate reflection of the situation.
Do you continue to believe that boa has vulnerabilites involving files
and functionality (as mentioned by the maintainer mgorny in #882773#c1)
which do not exist in the package?
I wanted my mail to change that belief. If I've failed so far can you
tell me how I can accomplish it, ie. what it would take for you to
please revert the lastrite commit?
If you think the CVEs are invalid, maybe talk to upstream? Or MITRE?
The CVEs are obviously invalid and yes someone could contribute time
to clean up NVD but I honestly don't think that either upstream or
myself can reasonably be made responsible for invalid CVEs submitted
by third parties.
Or anybody that isn't only a CVE downstream?
I expect every downstream of everything to apply themselves in order to improve quality of what they consume, not reduce it. To be clear: It's
also not your job to improve NVD but at least don't lastrite in Gentoo because of invalid CVEs.
I also note that very few distributions package Boa:
https://repology.org/project/boa/versions
This is a good way to measure how many people care about the package
(and thus, its security health).
I disagree, that's only a good way to measure how many distributions care.
Each distribution has its own dynamic (but actually distributions also
tend to herd behavior) and especially commercial distributions are more
often than not bound by law to be driven only by profit, with *everything* else secondary. This includes software quality and/or "security health".
If the commercial distributions don't carry a package, nobody cares for
it, and thus security issues are unlikely to be tracked and handled well.
This seems based on an assumption that only commercial software has
high value? I could not disagree more with that.
But if we play out the argument then CVEs for packages not in many distributions would more likely be invalid than others. While true
in this case I don't find it convincing as a general conclusion.
These things can all be true at once:
1. a package is secure
2. the package is not popular
3. a CVE for the package is invalid but not (yet) rejected
4. another CVE for the package is valid (low severity; still secure)
Only 1. says something about "security health" (whatever that means).
I think it's both irresponsible and wrong to indiscriminately give
authority to CVEs. People are wrong on the internet all the time,
some even intentionally, it's not correct to blindly believe CVEs
any more than tweets.
The mere existance of CVEs can not be reason enough for any change,
that would mean resignation to fear instead of encouraging rational behavior as required to actually improve technology.
That's not a real concern. We're not going to last rite something like nginx simply because there's a CVE against it. In the case of Boa,
which doesn't seem to have been touched in approaching 20 years, the
impact of last rites is minimal.
All packages are equal but some are more equal than others? ;)
Again: Impact shouldn't matter, correctness should.
The answer I receive so far is something like
"it can't work better because we react indiscriminately to CVEs",
that's an honest answer (thank you!) but not great quality. Does
everyone mostly agree with that policy?
It generally can't work better with MITRE being useless in many
cases. Yes, the CVEs seem garbage, but I can't say that
authoritatively, so I don't.
What would convince you?
Thanks a lot
//Peter
Currently mgorny is the listed maintainer of boa. What if instead of a
bunch of CVEs he just decided he had better things to do with his
time.
He last-rites the package, giving a 90d deadline for the package to
find a new owner.
No one cares to maintain boa, so no one steps up, and the package is
removed after 90d.
I think the current state is that no one with commit access to
::gentoo cares, so it will be removed unless someone changes their
mind.
Do you continue to believe that boa has vulnerabilites involving files
and functionality (as mentioned by the maintainer mgorny in #882773#c1) which do not exist in the package?
Just like it isn't your responsibility to "cleanup NVD", it's not my responsibility to authoritatively verify every CVE that Gentoo
Security acts upon.
Even if I did make such a judgement, I will *not* risk my being
wrong and exposing Gentoo users to vulnerabilities unecessarily,
even when prompted to by users on mailing lists.
The CVEs are obviously invalid and yes someone could contribute time
to clean up NVD but I honestly don't think that either upstream or
myself can reasonably be made responsible for invalid CVEs submitted
by third parties.
Again, we're not making judgements about "obviously invalid".
The time you've spent arguing with us on gentoo-dev could've been
easily spent asking upstream about the issue.
I disagree, that's only a good way to measure how many distributions care.
Which is *precisely* the point I'm making. If distributions with many
times the resources of Gentoo don't care to package it, that's a bad indicator of how well the package is taken care of.
Each distribution has its own dynamic (but actually distributions also
tend to herd behavior)
Again: Impact shouldn't matter, correctness should.
And again, I'm generally not going to be validating every CVE ever for correctness.
It generally can't work better with MITRE being useless in many
cases. Yes, the CVEs seem garbage, but I can't say that
authoritatively, so I don't.
What would convince you?
Anything from upstream, or a withdrawal of the CVEs, or a notice from
the CVE reproters that they're invalid. But I really don't understand
why anybody cares about this leaf package that nobody actually seems
to use, including you.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 399 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 101:45:12 |
| Calls: | 8,363 |
| Calls today: | 2 |
| Files: | 13,165 |
| Messages: | 5,898,006 |