Hacker News new | past | comments | ask | show | jobs | submit login

> I deeply regret this mistake and will take steps to ensure it never happens again.

I always get a little... sigh-y when I read statements like these. What steps? I'm not even sure what I would do to ensure something like that wouldn't happen again. Build some automated tooling to run the software that exercises every single feature it has, and capture system calls to ensure that it never opens or writes to files? That sounds like a very difficult thing to do (to the point that I wouldn't even try, especially for a GUI app), but anything less doesn't feel like you can ensure it won't happen again.




Gazillions of dollars have been spent on fuzzing Chrome/Chromium, and they're still finding dozens of serious issues per year. Same with every other major product. The reality seems to be that we, as programmers, can't do any better than this. If that's the case, it's unfair to lay it all at the feet of this one guy.


Exactly. Anyone complaining should donate time or money.


I would even go so far as: if you see reactions like "this is shoddy work, the author should Just Do Better", you can generally surmise that the person making the comment has a poor understanding of fallibility and will make a lot of these mistakes themselves.


Given the brevity of the security report, I figure the author wanted to get the relevant details about the *incident* posted as fast as humanly possible. However, it does seem appropriate to acknowledge that just because they're being terse doesn't mean they don't understand how big of a mistake it was.

That being said, I would also strongly expect a more in-depth blog post following up, with details about just the sort of thing you're mentioning.


I understand the interest about this bug, but to my understanding this is an unpaid hobby project?

If that's true I don't feel entitled to expect anything here.


I think your parent comment used "expect" to mean "predict" rather than "demand"?


You can expect anything you want in software you use, and choose not do you software that fails to meet expectations.

A software author who takes pains to publish his work and who accepts financial donations, is likely interested in maintaining his reputation and improving his skill and quality.

Finally, security bugs are in a class of their own. Giving out free junk is OK. Giving out free secret poison is not.


> Finally, security bugs are in a class of their own. Giving out free junk is OK. Giving out free secret poison is not.

It is not if it was done maliciously. If the code you got for free contained some mistakes it's ultimately your responsibility - You didn't have to take that pill you got at the party.

Accepting donations could change this, but I would say it depends on how they are presented - "campaign donations" ala Joey Hess or "Hey thanks for the the party last night, here's $40 to cover some of the booze!"

Alternatively, I'm curious how you feel about companies offering you "free email, free search, free image hosting, free social media" etc, (actually, in exchange for all your behavioral data) ((actually, even if you never directly accept anything from us))?


Right, you get it in toto IMHO: this is the least worst thing they can say, and also the best thing they can say.

If they don't apologize, that'd be worse.

If they don't indicate they'll take steps to prevent this from happening in the future, that'd be worse.

If they had all the steps ready right now, I'd be confused because they should have A) fixed the bug B) deployed the fix C) communicated the bug exists and a fix was deployed. Blending that with D) postmortem would show an undisciplined approach.

If they claimed the ability to prevent all bugs ever, or at least, all unintentional file writes, I'd be confused because it's impossible to prove it never writes to a file.

A good start is to do what he did (delete the ssh logging altogether), and start investigating automated ways to validate if/when files are accessed. The cool thing about macOS dev is there's a ton of tooling that leaps and bounds beyond cross-ecosystem tooling. I wouldn't be very surprised if someone linked an obscure mid-1990s technical note that lets you set an NSArray of paths that are allowed access, or if Instruments had some built-in dtrace integration that could pull this off. Couple running that in CI, make sure you got test coverage, and you've done the best you can.

(n.b. a lot of it seems to hinge on "I deeply regret this mistake and will take steps to ensure it never happens again." being read as "I deeply regret this mistake. I will do things until I can, absolutely, 100%, foreever, guarantee it'll never ever happen again." For the young and impressionable: the blog post is great, there's ~0 you could do better here)


Better would say "After the immediate problem is patched, I will post more details about future plans for security, probably within X days. I welcome suggestions on the feature tracker."

Empty vague promises aren't really better than being quiet. They rely entirely on the reader's good faith, but if that good faith exists (which it likely does for this excellent product and excellent developer), then the promise adds no information.


such a bad take. as a software engineer thing like this happen all the time. no matter scale we will screw it.

what steps we can take is that it's now a lesson to make it more caution when we went into that path.


Another comment mentioned using a linter to prevent 'console.log' from being mergeable in a PR, and this is exactly the kind of approach I'd take. Preventing an invalid state from existing is a pretty useful principle.


Coming from medical device background: procedures. Documents that explicitly lay out the things you have checked, how you checked it, date of check, and your signature on it at the end.

When you learn or anticipate a new failure mode, thats a new step in the corresponding procedure. Sometimes you'll be able to automate this stuff, but when the impact is this deep, it will not kill you to add some manual workload to your release process.


> The code to write to log files in SSH integration has been deleted

Seems like a good first step.


Talk is cheap, send patches


Seriously? It’s free and open source, give the guy a break. He’s a human being.


He’s saying that statement is unnecessary over-commitment. Not that he’s not doing enough


Isn't that his/her point?


there's lots of things you can do with deploy scripts to help prevent bozo errors from devs. Just like the code looking for credentials uploaded to github, you can do whatever type of searches that you as a developer is prone to making. it's a cya type of thing.


Just a reminder that iTerm is FOSS: https://github.com/gnachman/iTerm2


whats the paid alternative?


Panic’s Prompt, I guess? I bought it because it’s now bundled with the iOS app, which I already used.

It’s fine. Not mindblowing, not bad at all. Just fine.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: