111–120 of 350 posts
Dave here, founder of ToDesktop. I've shared a write-up: https://www.todesktop.com/blog/posts/security-incident-at-to... This vulnerability was genuinely embarrassing, and I'm sorry we let it happen. After thorough internal and third-party audits, we've fundamentally restructured our security practices to ensure this scenario can't recur. Full details are covered in the linked write-up. Special thanks to Eva for resp…
Earlier quoted context omitted.
You don't have any confidence beyond what lockfiles give you (which is to say the npm postinstall scripts could be very impure, non-hermetic, and output random strings). But if you require users to vendor all their dependencies, fully isolate all network traffic during build, be perfectly pure and reproducible and hermetic, presumably use nix/bazel/etc... well, you won't have any users. If you want a perfectly secure…
Most banks and larger enterprises do exactly this. Devs don't get to go out and pick random libraries with out a code review and then it's placed on a local repository. There are just far too many insecure and 'typo' malware to pull off the internet raw.
Dave here, founder of ToDesktop. I've shared a write-up: https://www.todesktop.com/blog/posts/security-incident-at-to... This vulnerability was genuinely embarrassing, and I'm sorry we let it happen. After thorough internal and third-party audits, we've fundamentally restructured our security practices to ensure this scenario can't recur. Full details are covered in the linked write-up. Special thanks to Eva for resp…
Were the logs independent of firebase? (Could someone exploiting this vulnerability have cleaned up after themselves in the logs?)
Earlier quoted context omitted.
This is the wrong response, because that means that the learning would be lost. The security community didn't want that to happen when one of the CA's got a vulnerability, we do not want it to happen to other companies. We want companies to succeed and get better, being shameful doesn't help towards that. Learning the right lessons does, and resigning means that you are learning the wrong ones.
I don't think the lesson is lost. The opposite. If you get a slap on the wrist, do you learn? No, you play it down. However if a dev who gets caught doing a bad is forced to resign. Then all the rest of the devs doing the same thing will shape up.
Except Dave didn't play it down. He's literally taking responsibility for a situation that could have resulted in significantly worse consequences.
Instead of saying, "nothing bad happened, let's move on," he, and by extension his company, have worked to remedy the issue, do a write up on it, disclose of the issue and its impact to users, and publicly apologize and hold themselves accountable. That right there is textbook engineering ethics 101 being followed.
As an Electron maintainer, I'll re-iterate a warning I've told many people before: Your auto-updater and the underlying code-signing and notarization mechanisms are sacred . The recovery mechanisms for the entire system are extremely painful and often require embarrassing emails to customers. A compromised code-sign certificate is close to the top of my personal nightmares. Dave and toDesktop have build a product tha…
It won't have licenses or anything, so if somebody wants to distribute it outside my website they will be able to do it.
If I just want to point to a exe file link in S3 without auto updates, should just compile and upload be enough?
Earlier quoted context omitted.
This is the wrong response, because that means that the learning would be lost. The security community didn't want that to happen when one of the CA's got a vulnerability, we do not want it to happen to other companies. We want companies to succeed and get better, being shameful doesn't help towards that. Learning the right lessons does, and resigning means that you are learning the wrong ones.
I don't think the lesson is lost. The opposite. If you get a slap on the wrist, do you learn? No, you play it down. However if a dev who gets caught doing a bad is forced to resign. Then all the rest of the devs doing the same thing will shape up.
Earlier quoted context omitted.
I don't think the lesson is lost. The opposite. If you get a slap on the wrist, do you learn? No, you play it down. However if a dev who gets caught doing a bad is forced to resign. Then all the rest of the devs doing the same thing will shape up.
I suggest reading one or two of Sydney Dekker’s books, which are a pretty comprehensive takedown of this idea. If an organization punishes mistakes, mistakes get hidden, covered up, and no less frequent.
Earlier quoted context omitted.
I suggest reading one or two of Sydney Dekker’s books, which are a pretty comprehensive takedown of this idea. If an organization punishes mistakes, mistakes get hidden, covered up, and no less frequent.
Is it Dekker? https://www.goodreads.com/book/show/578243.Field_Guide_to_Hu...
As an Electron maintainer, I'll re-iterate a warning I've told many people before: Your auto-updater and the underlying code-signing and notarization mechanisms are sacred . The recovery mechanisms for the entire system are extremely painful and often require embarrassing emails to customers. A compromised code-sign certificate is close to the top of my personal nightmares. Dave and toDesktop have build a product tha…
Question. I've noticed a lot of websites import from other sites, instead of local. I almost never see a hash in there. Is this as dangerous as it looks, why don't people just use a hash?
Earlier quoted context omitted.
Question. I've noticed a lot of websites import from other sites, instead of local. I almost never see a hash in there. Is this as dangerous as it looks, why don't people just use a hash?
1. Yes 2. Because that requires you to know how to find the hash and add it. Truthfully the burden should be on the third party that's serving the script (where did you copy that HTML in the first place?) but they aren't incentivizes to have other sites use a hash.