If you are in high risk computing (or any number of fields) and screw up that bad, you better be able to handle being mocked. You should also sift through the mocking and learn something.
This is a pretty toxic part of our industry. Everyone, in every position or role, should be able to accept constructive criticism of their work. Likewise, everyone should give constructive criticism. If your role involves "high risk" $x, you should hold yourself to exceptionally high standards, but that doesn't include the expectation that folks should fling non-constructive mockery at your work.
To your second point, learning from other peoples less-than-constructive criticism does not require going out of your way to help those people in the future.
People get mocked for failure. You cannot do anything of any decent impact without getting mocked. Toxic or not that is how it is. You can try to shield everyone or you can deal with it. Heck, this board allows "mocking" in a nice, neat mechanical fashion via down voting. If saying something sucks isn't acceptable then down voting isn't either.
The high risk isn't just $. The time people had to spend fixing the last problem was painful. You can bet people will want to vent.
> To your second point, learning from other peoples less-than-constructive criticism does not require going out of your way to help those people in the future.
Its not going out of your way, its being responsible. Not informing people of danger because they were mean to you is just bad karma on your part. I might not like someone, but I will tell that same someone about any danger. Any other behavior diminishes you as a person.
So does gleeful toxic shittery like mocking people, which you (apparently) support.
It's worth noting this sort of attitude doesn't cut it in actual high risk professions, like flying planes. The worst air disaster in history was caused in large part by one pilot belittling another, and the industry has moved away from such modes of operation.
I do not support the mocking of anyone except politicians (because if you cannot mock your leaders then the canary just died). I can understand how it happens and have slipped myself.
I also do not support the withholding of information from a group in danger like you (apparently) do. Sometimes you suck it up and prioritize safety above vengeance.
On July 28, 2010
an Airbus A321 belonging to the Pakistani airline Airblue crashed on
its approach to Islamabad airport, killing all 152 people on board.
The weather at Islamabad was poor with deteriorating visibility; a
PIA flight had only managed to get down on its third attempt, and
a flight from China had turned back. But Captain Pervez Chaudhry,
with 35 years and more than 25,000 hours in the cockpit, was cleared
for landing. He ended up flying straight into a hill – having ignored
21 ground proximity ‘pull up’ warnings related to the rising terrain
he was approaching. The official report painted a damning picture
of the captain. The CVR showed that he had belittled his co-pilot
– a former Pakistani air force F16 pilot and squadron leader, but a
man with only a year’s civilian flying behind him – by lecturing him
and firing questions at him during the initial climb, and using ‘harsh
words and a snobbish tone towards him’ during the rest of the flight.
As a result, by the time disaster approached, the first officer had gone
into his shell, and ‘remained a passive bystander in the cockpit, failing
to supplement and compliment or to correct the errors of his captain
assertively due to the captain’s behaviour in the flight.’ The result of
Chaudhry’s arrogance and hubris was horrific.
As with the example you gave, though, a key reason for the crash was that "The flight engineer's and the first officer's apparent hesitation to challenge Veldhuyzen van Zanten further", leading to over 500 fatalities.
OpenSSL cannot share with OpenBSD team because the OpenBSD team would not think twice about committing those fixes, making those issues public.
[A founding value of OpenBSD is about making anonymous access to their code repository: they develop the same tree that we see. Believe it or not, this was a radical stance for its time.
This is contrary to NetBSD's policy at the time of the fork: their code was only published at time of release, making contributions very difficult for outsiders, and withholding security fixes. Theo suspected people with commit access developed attacks based on these changes prior to next release.]
I can't recall any time where OpenSSH security fixes were withheld. Although OpenBSD developers do not take the time to evaluate whether a bug may always be exploitable, they do not hesitate to announce the possibility. http://www.openbsd.org/errata.html
This is contrary to the approach by Linus on the linux kernel, where security issues "are just normal bugs", placing the responsibility of downstream vendors (and attackers) to evaluate whether they are also a security issue, https://lkml.org/lkml/2008/7/15/648
I do not remember Theo ever telling me in the 1990s that he believed NetBSD team members were using their access to develop attacks. His opinion of the NetBSD team was far too low to give them that much credit. Theo was much more likely to believe that the concepts behind attacks were invented in the OpenBSD tree, and if he had a problem with how NetBSD managed its tree, it was that they wouldn't track OpenBSD fixes.
I don't know what Theo's saying these days. It's been over a decade since I talked to him. But I talked to him a lot in the earlier days of the project, during the original audit, during which time I wrote the OpenBSD advisories, sometimes at the Ship & Anchor in Calgary with him. I would remember this accusation. I never heard it.
Not really. I had commit privileges (a year earlier I had them briefly on FreeBSD, because of the crt0.c bug) but I used them I think twice, once to do something to ping(8) and once to add RADIUS support to tcpdump. I did however write many of the OpenBSD security advisories, and participated in the audit. In 1997, when I moved to Calgary for a few months to work for Secure Networks, Theo was the first person I met there.
To this day I still don't know how to use icb, which if you're an OpenBSD person tells you how much a part of that team I was.
I'm not smart or anything. I'm just (I assume) older than you are. And I got a very early start. That FreeBSD thing happened the year after I graduated high school. I skipped college and went right into dev.
OpenBSD developers fix a lot of bugs in the course of development, the far reaching security consequences of seemingly innocuous pieces of code are often difficult to evaluate, instead fixes go in and the tree swept for further occurrences. Hardly radical, I'd even say normal.
That's not true. We will withhold disclosure for a reasonable amount of time. 3 days is certainly reasonable.
For locally "sourced" errata, we do handle disclosure a little differently. A fix gets committed. Then a patch gets made. Then an email gets sent. That's about it. What we don't have is a secret cvs branch where we bundle up six or more vulns for disclosure all at once while our premium platinum access partners yank our chain.
22 comments
[ 4.6 ms ] story [ 45.4 ms ] thread"The OpenSSL group do not tell the LibreSSL group about vulnerabilities that they are fixing in upcoming releases."
https://marc.info/?l=openbsd-misc&m=142654095813320&w=2
To your second point, learning from other peoples less-than-constructive criticism does not require going out of your way to help those people in the future.
The high risk isn't just $. The time people had to spend fixing the last problem was painful. You can bet people will want to vent.
> To your second point, learning from other peoples less-than-constructive criticism does not require going out of your way to help those people in the future.
Its not going out of your way, its being responsible. Not informing people of danger because they were mean to you is just bad karma on your part. I might not like someone, but I will tell that same someone about any danger. Any other behavior diminishes you as a person.
So does gleeful toxic shittery like mocking people, which you (apparently) support.
It's worth noting this sort of attitude doesn't cut it in actual high risk professions, like flying planes. The worst air disaster in history was caused in large part by one pilot belittling another, and the industry has moved away from such modes of operation.
I also do not support the withholding of information from a group in danger like you (apparently) do. Sometimes you suck it up and prioritize safety above vengeance.
As with the example you gave, though, a key reason for the crash was that "The flight engineer's and the first officer's apparent hesitation to challenge Veldhuyzen van Zanten further", leading to over 500 fatalities.
[ edit: submitted as https://news.ycombinator.com/item?id=9215915 ]
[A founding value of OpenBSD is about making anonymous access to their code repository: they develop the same tree that we see. Believe it or not, this was a radical stance for its time.
This is contrary to NetBSD's policy at the time of the fork: their code was only published at time of release, making contributions very difficult for outsiders, and withholding security fixes. Theo suspected people with commit access developed attacks based on these changes prior to next release.]
I can't recall any time where OpenSSH security fixes were withheld. Although OpenBSD developers do not take the time to evaluate whether a bug may always be exploitable, they do not hesitate to announce the possibility. http://www.openbsd.org/errata.html
This is contrary to the approach by Linus on the linux kernel, where security issues "are just normal bugs", placing the responsibility of downstream vendors (and attackers) to evaluate whether they are also a security issue, https://lkml.org/lkml/2008/7/15/648
I don't know what Theo's saying these days. It's been over a decade since I talked to him. But I talked to him a lot in the earlier days of the project, during the original audit, during which time I wrote the OpenBSD advisories, sometimes at the Ship & Anchor in Calgary with him. I would remember this accusation. I never heard it.
I guess I need to search through your past comments, and a quick Google indicates I missed this.
Every time you comment here you make me feel so lazy. Haha.
To this day I still don't know how to use icb, which if you're an OpenBSD person tells you how much a part of that team I was.
I'm not smart or anything. I'm just (I assume) older than you are. And I got a very early start. That FreeBSD thing happened the year after I graduated high school. I skipped college and went right into dev.
Really? That is not the read I get off the Mailing list. I would like to see the e-mail where they say that.
OpenBSD developers fix a lot of bugs in the course of development, the far reaching security consequences of seemingly innocuous pieces of code are often difficult to evaluate, instead fixes go in and the tree swept for further occurrences. Hardly radical, I'd even say normal.
For locally "sourced" errata, we do handle disclosure a little differently. A fix gets committed. Then a patch gets made. Then an email gets sent. That's about it. What we don't have is a secret cvs branch where we bundle up six or more vulns for disclosure all at once while our premium platinum access partners yank our chain.