3 ms·

They should have burned the midnight oil and made sure the same problem wasn't prevalent in other parts of the code. I understand that's the feeling here, but

by trotsky 15y ago

They should have burned the midnight oil and made sure the same problem wasn't prevalent in other parts of the code. I understand that's the feeling here, but it's unrealistic. I've reported dozens of bugs to shops that ranged in size from 1 to borg. You simply never see a whole set of bugs fixed and pushed live over a weekend. Not even close. Exactly what company have you seen set this standard for professional? The smallest amount of time between notification and public disclosure I've seen get called responsible disclosure is a month. Many, many, many enterprises take six months or longer to push fixes (which is far too long but that's another whole discussion)

einhverfr 15y ago
I agree to a point. However, if such a problem was reported to LedgerSMB here is how we handle it: 1) Scope out the problem. What's affected? Are other related open source projects affected? How bad is it? This itself can take a bit of time. We do not rush this because we don't want a full disclosure when it happens to bring other problems into the fore. 2) Within a few days we let the reporter know what we have found and give them a chance to offer feedback. 3) Then we get everyone on the core team together and talk solutions. Once we implement it, we test and release a patch. Two weeks after the patch is released, we release a full disclosure along with a hat tip to the one who discovered it. The whole process takes time. But the fact is that it's generally better to get a full fix out in two weeks than a partial fix out tomorrow. So no, don't burn the midnight oil. More speed, less haste. And this whole thing really doesn't look good for Github.
- technoweenie 15y ago
  We didn't have the luxury of time. We were going back and forth with him over the weekend, and he pushed the commit 2 days after the original report. I admit, I was having some issues understanding his vague reports and went down a different rabbit hole early Sunday morning. I definitely wanted to do a more careful audit and investigation, but my hands were tied.

by trotsky 15y ago

einhverfr 15y ago

I agree to a point. However, if such a problem was reported to LedgerSMB here is how we handle it: 1) Scope out the problem. What's affected? Are other related open source projects affected? How bad is it? This itself can take a bit of time. We do not rush this because we don't want a full disclosure when it happens to bring other problems into the fore. 2) Within a few days we let the reporter know what we have found and give them a chance to offer feedback. 3) Then we get everyone on the core team together and talk solutions. Once we implement it, we test and release a patch. Two weeks after the patch is released, we release a full disclosure along with a hat tip to the one who discovered it. The whole process takes time. But the fact is that it's generally better to get a full fix out in two weeks than a partial fix out tomorrow. So no, don't burn the midnight oil. More speed, less haste. And this whole thing really doesn't look good for Github.

technoweenie 15y ago
We didn't have the luxury of time. We were going back and forth with him over the weekend, and he pushed the commit 2 days after the original report. I admit, I was having some issues understanding his vague reports and went down a different rabbit hole early Sunday morning. I definitely wanted to do a more careful audit and investigation, but my hands were tied.