5 ms·

I make software. If you discover a vulnerability, why would you put my tens of thousands of users at risk, instead of emailing me and have the vulnerability fix

I make software. If you discover a vulnerability, why would you put my tens of thousands of users at risk, instead of emailing me and have the vulnerability fixed in an hour before disclosing? I get that companies sit on vulnerabilities, but isn't fair warning... fair?

JonChesterfield 2y ago
An hour, sure. Frequently companies sit on it for months.
- stavros 2y ago
  Yes but responsible disclosure should be "you have a week (or whatever) from my first email, then I go public".
  - chii 2y ago
    what if the vulnerability cannot be easily fixed within the week, even if the company stops all work and focus completely on the problem? If the reason for responsible disclosure is to ensure that no members of the public is harmed as a result of said disclosure, should it not be a conversation between the security researcher and the company? The security researcher should have an approx. idea of how or what to do to fix, and give a reasonable amount of time for a fix. If the fix ought to have been easy, then a short time should suffice, and vice versa.
    - b112 2y ago
      You can always have a conversation if they provide justification.
    - stavros 2y ago
      If the vulnerability can't be fixed within the week, maybe the company should be SOL. This will incentivize companies to build their software better, as they'll know that any vulnerability that is hard to fix will mean consequences. Maybe the mitigation is for the company to take its service down while it works on the problem. Again, a good incentive to avoid that in the first place. Also an incentive to not waste any time after a report comes in, to see and act on it immediately, etc. At some point, we have to balance customer risk from disclosing immediately with companies sitting on vulnerabilities for months, vulnerabilities that may be actively exploited.
      - dijit 2y ago
        I hear what you're saying and I agree, but it's perhaps too black and white. Let's take one of the most disastrous bugs in recent history: meltdown. Speculative execution attacks inside the CPU. This required (in Paul Turners words): putting a warehouse of trampolines around an overly energetic 7-year old. This, understandably took a lot of time, both for microcode and OS vendors.. it took even longer to fix it in silicone. Not everyone is running SaaS that can deploy silently, or runs a patch cadence that can be triggered in minutes. I work in AAA games and I'm biased, we have to pass special certifications to release patches, if your publisher has good relations, waiting for CERT by itself (after you have a validated fix) is 2 weeks.
        precommunicator 2y ago
        > waiting for CERT by itself (after you have a validated fix) is 2 weeks If the industry practice would be few days to disclosure just maybe those practices might change or maybe there would be a (extra paid) option to skip the line for urgent stuff.
        holowoodman 2y ago
        Spectre/Meltdown is the perfect example of a vendor, Intel and AMD, deflecting blame onto the OS and software producers, successfully avoiding a recall, avoiding refunds for decreased performance and avoiding most of the blame. What actually should have happened there is a full recall of all affected hardware. Microcode fixes and payments for lost performance in the mean time, until the new hardware arrives. Meltdown was a desaster, but not only because the bugs themselves were bad. But also especially because we let Intel and AMD get away scott free.
        chii 2y ago
        There is no world in which a recall (and/or a refund) is ever possible. Until it is demonstrated that such flaws are a life and death fault, no regulation is possible for such flaws (unlike cars - which do have such recalls for faults that have life and death implications).
    - delusional 2y ago
      The security researcher should have an approx. idea of how or what to do to fix. How is that in any way the responsibility of independent randos on the internet? If you truly believe these issues should be fixed, the right answer would be to hold companies accountable for timely security patches, overseen and managed by a government department. I'm not sure thats a good idea, but expecting random security researchers to somehow hold massive billion dollar Enterprises accountable is silly.
    - throw0101d 2y ago
      > what if the vulnerability cannot be easily fixed within the week, even if the company stops all work and focus completely on the problem? A week is an example and not a definitive value dictated by law, statute, or regulation. When you report the vulnerability you give the developer a timeline of your plans, and if they can't make the deadline they can come back to you and request more time.
      - chii 2y ago
        this is what i presume happens today. You have a date for which disclosure will happen, and the company can request for more time. And this is exactly what the parent poster is against - because it is possible to continuously extend this date.
      - freeopinion 2y ago
        This back and forth is not possible if the researcher is anonymous. And it places all power in the hands of the developer. If the developer says, "I need a year" but the researcher doesn't give them a year, then the developer sues? Or files a criminal complaint? Why is all the risk on the researcher? So a gunshy researcher stays anonymous to keep their risk lower. They craft a disclosure with a crypto signature. They wait for the developer to post a public announcement about the disclosure that doesn't expose a ton of detail but does include the signature hash and general guidance about what to do until a fix is released. The researcher then posts their own anonymous public announcement with however much detail they choose. They might wait 24 hours or 7 days or 7 months. They might make multiple announcements with increasing levels of detail. Each announcement includes the original hash. Anybody can now make an announcement at any time about the vulnerability. If an announcement is signed by the same key as the original and contains more detail than given by the developer, the public can argue back and forth about who is being more or less responsible. Now the researcher can negotiate with the developer anonymously and publicly. The researcher can claim a bounty if they ever feel safe enough to publicly prove they are the author of the original report. Developers who routinely demonstrate responsible disclosure can earn the trust of researchers. Individual researchers get to decide how much they trust and how patient they are willing to be. The public gets to critique after the fact whether they sympathize more with the developer or the researcher. Perhaps a jury can decide which was liable for the level of disclosure they each pursued.
    - NegativeK 2y ago
      For any timeline the company can't hit, whether it's a week or 90 days, they should come up with compensating controls, detections, etc that users can implement. Managing vulnerable software isn't a new science. > The security researcher should have an approx. idea of how or what to do to fix Any expectation put on the security researcher beyond "maybe don't cause unnecessary shit storms with zero days" needs to be met with an offer of a fat contract.
- b112 2y ago
  Many types of vulnerabilities cannot be resolved in one hour. Some require complex thought to resolved. One hour is absurd for another reason, what timezone are you in? And they? What country, and therefore, is it a holiday? You may say "but vulnerability", and yes. 100% no heel dragging. But all companies are not staffed with 100k devs, and a few days, a week is a balance between letting every script kiddie know, and the potenital that it may be exploited in the wild currently. If one is going to counter unreasonable stupidity, use reasonable sensibility. One hour is the same as no warning.
technion 2y ago
The problem with a fair warning is that once I email you such a warning, I'll never be able to anonymously publish it no matter how much you ignore the report. Then the fair thing becomes I never go public I'm confident you'll call lawyers.
- frainfreeze 2y ago
  Can't you just send it from anon email?
- SahAssar 2y ago
  So can't you disclose it anonymously? I'm pretty sure most people who are savvy enough to find zero-days know how to get an email address anonymously.
  - technion 2y ago
    All ill say is: try it in practice. You'll quick find it dismissed as "not professional" and people will quickly claim its "irresponsible" for that reason.
    - layer8 2y ago
      Why would you care, if you publish it anonymously?
ang_cire 2y ago
> why would you put my tens of thousands of users at risk, instead of emailing me and have the vulnerability fixed in an hour before disclosing You've got it backwards. The vuln exists, so the users are already at risk; you don't know who else knows about the vuln, besides the people who reported it. Disclosing as soon as known means your customers can decide for themselves what action they want to take. Maybe they wait for you, maybe they kill the service temporarily, maybe they kill it permanently. That's their choice to make. Denying your customers information until you've had time to fix the vuln, is really just about taking away their agency in order to protect your company's bottom line, by not letting them know they're at risk until you can say, "but we fixed it already, so you don't need to stop using us to secure yourself, just update!"
- fastball 2y ago
  Increasing the chance of a bad actor actually doing something with a vulnerability seems bad, actually. You're effectively shifting responsibility to consumers, who are probably not going to see a CVE for one of the dozens of softwares they use every day.
  - ang_cire 2y ago
    > You're effectively shifting responsibility to consumers, who are probably not going to see a CVE for one of the dozens of softwares they use every day. Which is again, a problem created by the companies themselves. The way this should work is that the researcher discloses to the company, and the company reaches out to and informs their customers immediately. Then they fix it. But instead companies refuse to tell their customers when they're at risk, and make it out to be the researchers that are endangering people, when those researchers don't wait on an arbitrary, open-ended future date. > Increasing the chance of a bad actor actually doing something with a vulnerability seems bad, actually. Unless you know who knows what already, this is unprovable supposition (it could already be being exploited in the wild), and the arguments about whether POC code is good or bad is well tread, and covers this question. You are just making the argument that obscurity is security, and it's not.
    - 2y ago
neilv 2y ago
I think one point being made is that (in this example) you would've been much less careless about shipping the vulnerability, if you knew you'd be held accountable for it. With current practice, you can be as sloppy and reckless as you want, and when you create vulnerabilities because of that, you somehow almost push the "responsibility" onto the person who discovers it, and you aren't discouraged from recklessness. Personally, I think we need to keep the good part of responsible disclosure, but also phase in real penalties for the parties responsible for creating vulnerabilities that are exploited. (A separate matter is the responsibility of parties that exploit the vulnerabilities. Some of those may warrant stronger criminal-judicial or military responses than they appear to receive.) Ideal is a societal culture of responsibility, but in the US in some ways we've been conditioning people to be antisocial for decades, including by elevating some of the most greedy and arrogant to role models.
- haswell 2y ago
  > you would've been much less careless about shipping the vulnerability, if you knew you'd be held accountable for it I have a problem with this framing. Sure, some vulnerabilities are the result of recklessness, and there’s clearly a problem to be solved when it comes to companies shipping obviously shoddy code. But many vulnerabilities happen despite great care being taken to ship quality code. It is unfortunately the nature of the beast. A sufficiently complex system will result in vulnerabilities even a careful person could not have predicted. To me, the issue is that software now runs the world, despite these inherent limitations of human developers and the process of software development. It’s deployed in ever more critical situations, despite the industry not having well defined and enforceable standards like you’d find in some engineering disciplines. What you’re describing is a scenario that would force developers to just stop making software, on top of putting significantly more people at risk. I still believe the industry has a problem that needs to be solved, and it needs a broad culture shift in the dev community, but disagree that shining a bright light on every hole such that it causes massive harm to “make devs accountable” is a good or even reasonable solution.
  - neilv 2y ago
    I think that culture shift will have to come from the top in business -- the CEO and the board. At this point, the software development field is about operating within the system decided by those others, with the goal of personally getting money. After you've made the CEO and board accountable, I think dev culture will adapt almost immediately. Beware of attempts to push engineering licensing or certifications, etc. as a solution here. Based on everything we've seen in the field in recent decades, that will just be used at the corporate level as a compliance letter-but-not-spirit tool to evade responsibility (as well as a moat to upstart competitors), and a vendor market opportunity for incompetent leeches. First you make CEO and board accountable, and then let the dev culture change, and then, once you have a culture of people taking responsibility, then you'll have the foundation to add in licensing (designed in good faith) as an extra check on that, if that looks worthwhile.
rakoo 2y ago
According to the post above, if you earned enough reputation then you might be given that one-hour window for fixing before disclosing. The issue isn't so much about whether or not there should be a "private" window but how long it lasts, especially when the editor is a multi-billion company
- haswell 2y ago
  Let’s not forget the end users in this scenario, who will not be able to react to this as quickly as a billion dollar company regardless of how well they notify their customers.
  - rakoo 2y ago
    Absolutely, which is yet another reason why this abstraction from the conditions of creation of anything tech-related is something that should be eliminated
efdee 2y ago
Strange wording. You are the one that put tens of thousands of your users at risk. Not the one who discovers the problem.
- stavros 2y ago
  If you forget your shop's door open after hours, and someone starts shouting "HEY GUYS! THIS DOOR IS OPEN! LOOK!", I have a hard time putting 100% of the blame on you.
  - pixl97 2y ago
    If I point out the bridge is cracking and you get angry about it, I'm blaming the idiots that engineered a crap bridge and didn't maintain it. Maybe it's time we get professional standards if this is how we are going to behave?
    - haswell 2y ago
      This seems like a fallacious analogy to me. Why is a cracked bridge dangerous? Because anyone traveling over it or under it is at risk of being hurt if the bridge collapses. Warning people that it is cracking does not increase the likelihood of a collapse. Why is a software vulnerability dangerous? Because anyone who knows about it and has nefarious intent can now use it as a weapon against those who are using the vulnerable software, and the world is full of malicious actors actively seeking new avenues to carry out attacks. And there are quite a few people who would exploit the knowledge of an unlocked door if given the chance. There’s a very clear difference in the implications between these scenarios.
      - pixl97 2y ago
        A cracked bridge is always dangerous. A vulnerable piece of software is always dangerous. There are large numbers of state funded exploit groups and otherwise blackhat organizations that find and store these vulnerabilities waiting for the right opportunity, say economic warfare. Much like building safe bridges from the start we need the same ideology in software. The 'we can always patch it later' is eventually going to screw us over hard.
cenamus 2y ago
You already put your tens of thousands of users at risk. The people putting bugs in the software, not the ones discovering them.
- stavros 2y ago
  Please enlighten me on how you've managed to never write any bugs.
  - pixl97 2y ago
    Well, not sure DJB posts here, but he has kept it to a minimum. And this is mostly BS too. People don't write bug free software, they write features. Other industries had to license professional engineers to keep this kind of crap from being a regular issue.
    - holowoodman 2y ago
      "Licensed professional engineers" are a software-development myth. If all our software was as simple as a bridge, then we could have that. A bridge is 5 sheets of plans, 10 pages of founding checks, 30 pages of calculations, 100 pages of material specs. You can read all those in a day. Check the calculations in a week. Next bridge will be almost the same. Now tell me about any software where the spec is that short and simple. /bin/cat? /bin/true? Certainly not the GNU versions of those. Software is different because we don't build 1000 almost-identical bridges with low complexity. We always build something new and bespoke, with extremely high complexity compared to any kind of building or infrastructure. Reproduction is automatic, so there will never be routine. Totally different kind of job, where a licensed professional will not help at all.
      - pixl97 2y ago
        I hate to be dismissive, but tired old meme is tired. With what I do I work with a lot of larger companies and get to see the crap they push out with no architectural design and no initial security posture. I see apps with thousands of packages, including things like typosquats. I see the quality of the security teams which are contractors following checklists with no idea what they mean. Saying that actual professions would make no difference sounds insane to me. Again, to me, it sounds like every other industry in saying 'self regulation is fine, we're special, we'll manage ourselves".
holowoodman 2y ago
Fair warning through "responsible" disclosure was abused again and again and again. Why should I trust company no 1000 after 999 have mislead bug reporters, the public, their customers and the rest of the world about their own "just an hour"?
fucker42069 2y ago
[flagged]
beeflet 2y ago
Because there is an information disparity I could profit from instead of doing free work for you. Even if that disparity is just "posting the vuln to my blog" to get e-famous.
v3ss0n 2y ago
You made the software, you have your paid customers, you are responsible for security of your customers. If you have an RCE that's your problem and you gotta fix it.

JonChesterfield 2y ago

An hour, sure. Frequently companies sit on it for months.

stavros 2y ago
Yes but responsible disclosure should be "you have a week (or whatever) from my first email, then I go public".
- chii 2y ago
  what if the vulnerability cannot be easily fixed within the week, even if the company stops all work and focus completely on the problem? If the reason for responsible disclosure is to ensure that no members of the public is harmed as a result of said disclosure, should it not be a conversation between the security researcher and the company? The security researcher should have an approx. idea of how or what to do to fix, and give a reasonable amount of time for a fix. If the fix ought to have been easy, then a short time should suffice, and vice versa.
  - b112 2y ago
    You can always have a conversation if they provide justification.
  - stavros 2y ago
    If the vulnerability can't be fixed within the week, maybe the company should be SOL. This will incentivize companies to build their software better, as they'll know that any vulnerability that is hard to fix will mean consequences. Maybe the mitigation is for the company to take its service down while it works on the problem. Again, a good incentive to avoid that in the first place. Also an incentive to not waste any time after a report comes in, to see and act on it immediately, etc. At some point, we have to balance customer risk from disclosing immediately with companies sitting on vulnerabilities for months, vulnerabilities that may be actively exploited.
    - dijit 2y ago
      I hear what you're saying and I agree, but it's perhaps too black and white. Let's take one of the most disastrous bugs in recent history: meltdown. Speculative execution attacks inside the CPU. This required (in Paul Turners words): putting a warehouse of trampolines around an overly energetic 7-year old. This, understandably took a lot of time, both for microcode and OS vendors.. it took even longer to fix it in silicone. Not everyone is running SaaS that can deploy silently, or runs a patch cadence that can be triggered in minutes. I work in AAA games and I'm biased, we have to pass special certifications to release patches, if your publisher has good relations, waiting for CERT by itself (after you have a validated fix) is 2 weeks.
      - precommunicator 2y ago
        > waiting for CERT by itself (after you have a validated fix) is 2 weeks If the industry practice would be few days to disclosure just maybe those practices might change or maybe there would be a (extra paid) option to skip the line for urgent stuff.
      - holowoodman 2y ago
        Spectre/Meltdown is the perfect example of a vendor, Intel and AMD, deflecting blame onto the OS and software producers, successfully avoiding a recall, avoiding refunds for decreased performance and avoiding most of the blame. What actually should have happened there is a full recall of all affected hardware. Microcode fixes and payments for lost performance in the mean time, until the new hardware arrives. Meltdown was a desaster, but not only because the bugs themselves were bad. But also especially because we let Intel and AMD get away scott free.
        chii 2y ago
        There is no world in which a recall (and/or a refund) is ever possible. Until it is demonstrated that such flaws are a life and death fault, no regulation is possible for such flaws (unlike cars - which do have such recalls for faults that have life and death implications).
  - delusional 2y ago
    The security researcher should have an approx. idea of how or what to do to fix. How is that in any way the responsibility of independent randos on the internet? If you truly believe these issues should be fixed, the right answer would be to hold companies accountable for timely security patches, overseen and managed by a government department. I'm not sure thats a good idea, but expecting random security researchers to somehow hold massive billion dollar Enterprises accountable is silly.
  - throw0101d 2y ago
    > what if the vulnerability cannot be easily fixed within the week, even if the company stops all work and focus completely on the problem? A week is an example and not a definitive value dictated by law, statute, or regulation. When you report the vulnerability you give the developer a timeline of your plans, and if they can't make the deadline they can come back to you and request more time.
    - chii 2y ago
      this is what i presume happens today. You have a date for which disclosure will happen, and the company can request for more time. And this is exactly what the parent poster is against - because it is possible to continuously extend this date.
    - freeopinion 2y ago
      This back and forth is not possible if the researcher is anonymous. And it places all power in the hands of the developer. If the developer says, "I need a year" but the researcher doesn't give them a year, then the developer sues? Or files a criminal complaint? Why is all the risk on the researcher? So a gunshy researcher stays anonymous to keep their risk lower. They craft a disclosure with a crypto signature. They wait for the developer to post a public announcement about the disclosure that doesn't expose a ton of detail but does include the signature hash and general guidance about what to do until a fix is released. The researcher then posts their own anonymous public announcement with however much detail they choose. They might wait 24 hours or 7 days or 7 months. They might make multiple announcements with increasing levels of detail. Each announcement includes the original hash. Anybody can now make an announcement at any time about the vulnerability. If an announcement is signed by the same key as the original and contains more detail than given by the developer, the public can argue back and forth about who is being more or less responsible. Now the researcher can negotiate with the developer anonymously and publicly. The researcher can claim a bounty if they ever feel safe enough to publicly prove they are the author of the original report. Developers who routinely demonstrate responsible disclosure can earn the trust of researchers. Individual researchers get to decide how much they trust and how patient they are willing to be. The public gets to critique after the fact whether they sympathize more with the developer or the researcher. Perhaps a jury can decide which was liable for the level of disclosure they each pursued.
  - NegativeK 2y ago
    For any timeline the company can't hit, whether it's a week or 90 days, they should come up with compensating controls, detections, etc that users can implement. Managing vulnerable software isn't a new science. > The security researcher should have an approx. idea of how or what to do to fix Any expectation put on the security researcher beyond "maybe don't cause unnecessary shit storms with zero days" needs to be met with an offer of a fat contract.
b112 2y ago
Many types of vulnerabilities cannot be resolved in one hour. Some require complex thought to resolved. One hour is absurd for another reason, what timezone are you in? And they? What country, and therefore, is it a holiday? You may say "but vulnerability", and yes. 100% no heel dragging. But all companies are not staffed with 100k devs, and a few days, a week is a balance between letting every script kiddie know, and the potenital that it may be exploited in the wild currently. If one is going to counter unreasonable stupidity, use reasonable sensibility. One hour is the same as no warning.

technion 2y ago

The problem with a fair warning is that once I email you such a warning, I'll never be able to anonymously publish it no matter how much you ignore the report. Then the fair thing becomes I never go public I'm confident you'll call lawyers.

frainfreeze 2y ago
Can't you just send it from anon email?
SahAssar 2y ago
So can't you disclose it anonymously? I'm pretty sure most people who are savvy enough to find zero-days know how to get an email address anonymously.
- technion 2y ago
  All ill say is: try it in practice. You'll quick find it dismissed as "not professional" and people will quickly claim its "irresponsible" for that reason.
  - layer8 2y ago
    Why would you care, if you publish it anonymously?

ang_cire 2y ago

> why would you put my tens of thousands of users at risk, instead of emailing me and have the vulnerability fixed in an hour before disclosing You've got it backwards. The vuln exists, so the users are already at risk; you don't know who else knows about the vuln, besides the people who reported it. Disclosing as soon as known means your customers can decide for themselves what action they want to take. Maybe they wait for you, maybe they kill the service temporarily, maybe they kill it permanently. That's their choice to make. Denying your customers information until you've had time to fix the vuln, is really just about taking away their agency in order to protect your company's bottom line, by not letting them know they're at risk until you can say, "but we fixed it already, so you don't need to stop using us to secure yourself, just update!"

fastball 2y ago
Increasing the chance of a bad actor actually doing something with a vulnerability seems bad, actually. You're effectively shifting responsibility to consumers, who are probably not going to see a CVE for one of the dozens of softwares they use every day.
- ang_cire 2y ago
  > You're effectively shifting responsibility to consumers, who are probably not going to see a CVE for one of the dozens of softwares they use every day. Which is again, a problem created by the companies themselves. The way this should work is that the researcher discloses to the company, and the company reaches out to and informs their customers immediately. Then they fix it. But instead companies refuse to tell their customers when they're at risk, and make it out to be the researchers that are endangering people, when those researchers don't wait on an arbitrary, open-ended future date. > Increasing the chance of a bad actor actually doing something with a vulnerability seems bad, actually. Unless you know who knows what already, this is unprovable supposition (it could already be being exploited in the wild), and the arguments about whether POC code is good or bad is well tread, and covers this question. You are just making the argument that obscurity is security, and it's not.
  - 2y ago

neilv 2y ago

I think one point being made is that (in this example) you would've been much less careless about shipping the vulnerability, if you knew you'd be held accountable for it. With current practice, you can be as sloppy and reckless as you want, and when you create vulnerabilities because of that, you somehow almost push the "responsibility" onto the person who discovers it, and you aren't discouraged from recklessness. Personally, I think we need to keep the good part of responsible disclosure, but also phase in real penalties for the parties responsible for creating vulnerabilities that are exploited. (A separate matter is the responsibility of parties that exploit the vulnerabilities. Some of those may warrant stronger criminal-judicial or military responses than they appear to receive.) Ideal is a societal culture of responsibility, but in the US in some ways we've been conditioning people to be antisocial for decades, including by elevating some of the most greedy and arrogant to role models.

haswell 2y ago
> you would've been much less careless about shipping the vulnerability, if you knew you'd be held accountable for it I have a problem with this framing. Sure, some vulnerabilities are the result of recklessness, and there’s clearly a problem to be solved when it comes to companies shipping obviously shoddy code. But many vulnerabilities happen despite great care being taken to ship quality code. It is unfortunately the nature of the beast. A sufficiently complex system will result in vulnerabilities even a careful person could not have predicted. To me, the issue is that software now runs the world, despite these inherent limitations of human developers and the process of software development. It’s deployed in ever more critical situations, despite the industry not having well defined and enforceable standards like you’d find in some engineering disciplines. What you’re describing is a scenario that would force developers to just stop making software, on top of putting significantly more people at risk. I still believe the industry has a problem that needs to be solved, and it needs a broad culture shift in the dev community, but disagree that shining a bright light on every hole such that it causes massive harm to “make devs accountable” is a good or even reasonable solution.
- neilv 2y ago
  I think that culture shift will have to come from the top in business -- the CEO and the board. At this point, the software development field is about operating within the system decided by those others, with the goal of personally getting money. After you've made the CEO and board accountable, I think dev culture will adapt almost immediately. Beware of attempts to push engineering licensing or certifications, etc. as a solution here. Based on everything we've seen in the field in recent decades, that will just be used at the corporate level as a compliance letter-but-not-spirit tool to evade responsibility (as well as a moat to upstart competitors), and a vendor market opportunity for incompetent leeches. First you make CEO and board accountable, and then let the dev culture change, and then, once you have a culture of people taking responsibility, then you'll have the foundation to add in licensing (designed in good faith) as an extra check on that, if that looks worthwhile.

rakoo 2y ago

According to the post above, if you earned enough reputation then you might be given that one-hour window for fixing before disclosing. The issue isn't so much about whether or not there should be a "private" window but how long it lasts, especially when the editor is a multi-billion company

haswell 2y ago
Let’s not forget the end users in this scenario, who will not be able to react to this as quickly as a billion dollar company regardless of how well they notify their customers.
- rakoo 2y ago
  Absolutely, which is yet another reason why this abstraction from the conditions of creation of anything tech-related is something that should be eliminated

efdee 2y ago

Strange wording. You are the one that put tens of thousands of your users at risk. Not the one who discovers the problem.

stavros 2y ago
If you forget your shop's door open after hours, and someone starts shouting "HEY GUYS! THIS DOOR IS OPEN! LOOK!", I have a hard time putting 100% of the blame on you.
- pixl97 2y ago
  If I point out the bridge is cracking and you get angry about it, I'm blaming the idiots that engineered a crap bridge and didn't maintain it. Maybe it's time we get professional standards if this is how we are going to behave?
  - haswell 2y ago
    This seems like a fallacious analogy to me. Why is a cracked bridge dangerous? Because anyone traveling over it or under it is at risk of being hurt if the bridge collapses. Warning people that it is cracking does not increase the likelihood of a collapse. Why is a software vulnerability dangerous? Because anyone who knows about it and has nefarious intent can now use it as a weapon against those who are using the vulnerable software, and the world is full of malicious actors actively seeking new avenues to carry out attacks. And there are quite a few people who would exploit the knowledge of an unlocked door if given the chance. There’s a very clear difference in the implications between these scenarios.
    - pixl97 2y ago
      A cracked bridge is always dangerous. A vulnerable piece of software is always dangerous. There are large numbers of state funded exploit groups and otherwise blackhat organizations that find and store these vulnerabilities waiting for the right opportunity, say economic warfare. Much like building safe bridges from the start we need the same ideology in software. The 'we can always patch it later' is eventually going to screw us over hard.

cenamus 2y ago

You already put your tens of thousands of users at risk. The people putting bugs in the software, not the ones discovering them.

stavros 2y ago
Please enlighten me on how you've managed to never write any bugs.
- pixl97 2y ago
  Well, not sure DJB posts here, but he has kept it to a minimum. And this is mostly BS too. People don't write bug free software, they write features. Other industries had to license professional engineers to keep this kind of crap from being a regular issue.
  - holowoodman 2y ago
    "Licensed professional engineers" are a software-development myth. If all our software was as simple as a bridge, then we could have that. A bridge is 5 sheets of plans, 10 pages of founding checks, 30 pages of calculations, 100 pages of material specs. You can read all those in a day. Check the calculations in a week. Next bridge will be almost the same. Now tell me about any software where the spec is that short and simple. /bin/cat? /bin/true? Certainly not the GNU versions of those. Software is different because we don't build 1000 almost-identical bridges with low complexity. We always build something new and bespoke, with extremely high complexity compared to any kind of building or infrastructure. Reproduction is automatic, so there will never be routine. Totally different kind of job, where a licensed professional will not help at all.
    - pixl97 2y ago
      I hate to be dismissive, but tired old meme is tired. With what I do I work with a lot of larger companies and get to see the crap they push out with no architectural design and no initial security posture. I see apps with thousands of packages, including things like typosquats. I see the quality of the security teams which are contractors following checklists with no idea what they mean. Saying that actual professions would make no difference sounds insane to me. Again, to me, it sounds like every other industry in saying 'self regulation is fine, we're special, we'll manage ourselves".

holowoodman 2y ago

Fair warning through "responsible" disclosure was abused again and again and again. Why should I trust company no 1000 after 999 have mislead bug reporters, the public, their customers and the rest of the world about their own "just an hour"?

fucker42069 2y ago

[flagged]

beeflet 2y ago

Because there is an information disparity I could profit from instead of doing free work for you. Even if that disparity is just "posting the vuln to my blog" to get e-famous.

v3ss0n 2y ago

You made the software, you have your paid customers, you are responsible for security of your customers. If you have an RCE that's your problem and you gotta fix it.