5 ms·

AlmaLinux discovers working with Red Hat isn't easy

26 points by CrankyBear 3y ago

kjs3 3y ago
I don't want to make RH the good guy in any of this, but I'm not sure why this is surprising. In my corporate, regulated environment (and most other places I've worked) the dev teams have virtually all said "we aren't going to commit to fix medium and low vulns on any particular schedule unless there's an overriding business reason to do so (fixes a customer visible bug, regulators start demanding it, we get hacked because of it, etc)". Usually, this is couched in terms of 'resource constraints' or similar. I'm sure similar issues confront RH, and they are applying similar reasoning, right or wrong.
lockhouse 3y ago
I think a lot of users will realize that the support timeline was the killer feature and not the bug for bug compatibility. Unpopular opinion, but if you're running the kind of software that relies on RHEL bug for bug compatibility, you should probably just pay for RHEL.
janosdebugs 3y ago
I used to work on a non-RHEL Red Hat product. Every bug needed a whole lot of work after the code was written. A QE person would need to test it, often needing dev assistance to understand what even needed testing. A docs person would need to determine what docs needed to be written, again with dev assistance, and for security stuff a ProdSec person would also be involved. It also took at least 10 minutes to discuss a bug like this in bug triage meeting, involving at least 10 people. Some bugs needed a lot more discussion than that. Red Hat's process incredibly expensive and decisions are primarily made based on how it affects the customer. Iperf3 is a relatively obscure tool from a general RHEL user perspective. While the vulnerability may be serious from the perspective of iperf3, a Red Hat customer won't be running it on the public internet for long periods of time. Most iperf3 usage I've seen was in dedicated test environments. Practically, this won't be exploitable, and if so, iperf3 will crash, nothing more will happen according to the bug. Is it great? No, it isn't. But an often-overlooked part of open source is how much work it takes to merge a PR. I've had cases on hobby projects when it took way more work to merge it than to write it.

26 points by CrankyBear 3y ago

kjs3 3y ago

I don't want to make RH the good guy in any of this, but I'm not sure why this is surprising. In my corporate, regulated environment (and most other places I've worked) the dev teams have virtually all said "we aren't going to commit to fix medium and low vulns on any particular schedule unless there's an overriding business reason to do so (fixes a customer visible bug, regulators start demanding it, we get hacked because of it, etc)". Usually, this is couched in terms of 'resource constraints' or similar. I'm sure similar issues confront RH, and they are applying similar reasoning, right or wrong.

lockhouse 3y ago

I think a lot of users will realize that the support timeline was the killer feature and not the bug for bug compatibility. Unpopular opinion, but if you're running the kind of software that relies on RHEL bug for bug compatibility, you should probably just pay for RHEL.

janosdebugs 3y ago

I used to work on a non-RHEL Red Hat product. Every bug needed a whole lot of work after the code was written. A QE person would need to test it, often needing dev assistance to understand what even needed testing. A docs person would need to determine what docs needed to be written, again with dev assistance, and for security stuff a ProdSec person would also be involved. It also took at least 10 minutes to discuss a bug like this in bug triage meeting, involving at least 10 people. Some bugs needed a lot more discussion than that. Red Hat's process incredibly expensive and decisions are primarily made based on how it affects the customer. Iperf3 is a relatively obscure tool from a general RHEL user perspective. While the vulnerability may be serious from the perspective of iperf3, a Red Hat customer won't be running it on the public internet for long periods of time. Most iperf3 usage I've seen was in dedicated test environments. Practically, this won't be exploitable, and if so, iperf3 will crash, nothing more will happen according to the bug. Is it great? No, it isn't. But an often-overlooked part of open source is how much work it takes to merge a PR. I've had cases on hobby projects when it took way more work to merge it than to write it.