141–150 of 350 posts
We have reviewed logs and inspected app bundles. No malicious usage was detected. There were no malicious builds or releases of applications from the ToDesktop platform.
Do they have to?
Isn't this notion making developers sloppy?
Earlier quoted context omitted.
There are plenty of worlds that take security more seriously and practice defense in depth. Your response could use a little less hubris and a more genuinely inquisitive tone. Looks like others have already chimed in here but to respond to your (what feels like sarcasm) questions: - You can have a submission process that accepts a package or downloads dependencies, and then passes it to another machine that is on an…
You have to meet your users where they are. Your users are not using nix and bazel, they're using npm and typescript. If your users are using bazel, it's easy to separate "download" from "build", but if you're meeting your users over here where cows aren't spherical, you can't take security that seriously. Security doesn't help if all your users leave.
"i wanted to get on the machine where the application gets built and the easiest way to do this would be a postinstall script in package.json, so i did that with a simple reverse shell payload" Just want to make sure I understand this. They made a hello world app and submitted it to todesktop with a post install script that opened a reverse shell on the todesktop build machine? Maybe I missed it but that shouldn't be…
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…
How about we don't build an auto-updater? Maybe some apps require an extremely tight coupling with a server, but we should try our best to release complete software to users that will work as close to forever as possible. Touching files on a user's system should be treated as a rare special occurrence. If a server is involved with the app, build a stable interface and think long and hard about every change. Meticulou…
That sounds like a good idea. Unless you’re the vendor, and instead of 1000 support requests for version N, you’re now facing 100 support requests for version N, 100 for N−1, 100 for N−2, …, and 100 for N−9.
Earlier quoted context omitted.
Firebase let's anyone get started in 30 seconds. Details like proper usage, security, etc. Those are often overlooked. Google isn't to blame if you ship a paid product without running a security audit. I use firebase essentially for hobbyist projects for me and my friends. If I had to guess these issues come about because developers are rushing to market. Not Google's fault ... What works for a prototype isn't produc…
> Google isn't to blame if you ship a paid product without running a security audit. Arguably, if you provide a service that makes it trivial to create security issues (that is to say, you have to go out of your way to use it correctly) then it's your fault. If making it secure means making it somewhat less convenient, it's 100% your fault for not making it less convenient.
Remove as much hurdles to increase adoption.