Why does my text-editor need to do "encryption at rest"? If I want data encrypted, I store it in an encrypted drive with a transparent en/decryption layer.
That is completely valid for personal threat models, I rely on LUKS/BitLocker for my daily driver too.
The specific gap this fills is 'Defense in Depth' + compliance. OS-level encryption (like FDE) is transparent once you log in. If you walk away from an unlocked machine, FDE does nothing.
App-level encryption, however, ensures the specific sensitive notes remain encrypted on disk even while the OS is running and the user is authenticated.
It's also portable as it allows the encrypted blob to be moved across untrusted transports (email, USB, cloud) without needing to set up an encrypted container/volume on the destination.
For FIPS/NIST workflows, relying solely on the OS often isn't enough for the auditor; having the application control the keys explicitly satisfies the 'data protection' control regardless of the underlying storage medium.
...then I might as well ask what happens when I walk away from the encrypting edior while a file is still open. User Error can happen with any encryption or security schema. Pointing out a trueism is not an argument.
> It's also portable
So is encrypting files using a specialized tool. I don't need my editor to do this. The entire point of my criticism, and indeed the entire point of this thread, is that software that should focus on a narrow task, tries to do way too much, leading to problems.
For what it's worth I understood the argument and think it is valid. It's one thing for the file you're working on to be vulnerable if you walk away leaving the editor open; it's another for all of your other files to be vulnerable too. It's O(1) vs. O(n). The difference is clearly not zero.
As funny as the "Bush hid the facts" bug may be, there is a world of difference between an embarassing mistake by a function that guesses the text encoding wrong, and a goddamn remote code execution with an 8.8 score
> and we have other battles we fight.
Except no, we don't. notepad.exe was DONE SOFTWARE. It was feature complete. It didn't have to change. This is not a battle that needed fighting, this was hitting a brick wall with ones fist for no good reason, and then complaining about the resulting pain.
They likely knew nobody would be drawn to WordPad by the additions, so they had to scavenge their rapidly diminishing list of actually useful software for sacrifices on the altar to their outrageous AI investments.
How long were they threatening to kill snipping tool despite it being a perfectly serviceable piece of kit so we could switch to some shitty alternative?
They did ultimately kill it though - and then they re-created it as a bloated UWP version that is an insane 449 MEGABYTES in size! The old win32 Snipping Tool used to be only a few kilobytes...
For a good built in "done" text editor, theres apples textedit. It's barely changed since NeXTSTEP and works flawlessly and is FOSS. As much as I hate apple there's a reason I have GNUstep installed on most of my *nix boxes
This definition in the first paragraph on Wikipedia matches my understanding of it as a security consultant:
> The ability to trigger arbitrary code execution over a network (especially via a wide-area network such as the Internet) is often referred to as remote code execution (RCE or RCX). --https://en.wikipedia.org/wiki/Arbitrary_code_execution
Issues in handling local files, whether they require user interaction or not, are just that
Doesn't take away from the absurdity that notepad isn't a notepad but does extensive file contents parsing
> Except no, we don't. notepad.exe was DONE SOFTWARE
While 8.8 score is embarrassing, by no measure notepad was done software. It couldn't load a large text file for one, its search was barely functional, had funky issues with encoding, etc.
Notepad++ is closer to what should be expected from an OS basic text editor
What counts as "large"? I'm pretty sure at some point in my life I'd opened the entirety of Moby Dick in Notepad. Unless you want to look for text in a binary file (which Notepad definitely isn't for) I doubt you'll run into that problem too often.
Also, I hope the irony of you citing Notepad++ [1] as what Notepad should aim to be isn't lost on you. My point being, these kinds of vulnerabilities shouldn't exist in a fucking text editor.
Remote into a machine that you're not allowed to copy data out of. You only have the utilities baked into Windows and whatever the validated CI/CD process put there. You need to open a log file that has ballooned to at least several hundred megabytes, maybe more.
Moby Dick is about 1MB of text. That's really not much compared to a lot of log files on pretty hot servers.
I do agree though, if we're going to be complaining about how a text editor could have security issues and pointing to Notepad++ as an example otherwise, its had its own share of notable vulnerabilities even before this update hijacking. CVE-2017-8803 had a code execution vulnerability on just opening a malicious file, this at least requires you to click the rendered link in a markdown file.
Oh right, generated files exist. Though logging systems usually have a rollover file size you can configure, should this happen to you in real life.
Honestly I'm okay with having to resort to power tools for these edge cases. Notepad is more for the average user who is less likely to run into 100 MB text files and more likely to run into a 2 kB text file someone shared on Discord.
> Notepad is more for the average user who is less likely to run into 100 MB text files and more likely to run into a 2 kB text file someone shared on Discord.
There's no reason it shouldn't handle both use cases.
> Though logging systems usually have a rollover file size you can configure, should this happen to you in real life
I get what you're saying. But if things were done right I probably wouldn't have to be remoting into this box to hunt for a log file that wasn't properly being shipped to some other centralized logging platform.
I know about the vulnerabilities in notepad++, however I was referring to the feature set.
Regarding large, I am referring to log files for example. I think the issue was lack of use of memory mapped files, which meant the entire file was loaded to RAM always, often giving the frozen window experience
Plus for many years Word was one of the main cash cows for MS, so they didn't want to make an editor that would take away from Word.
And you could see how adding new things adds vulnerabilities. In this case they added ability to see/render markdown and with markdown they render links, which in this case allowed executing remote code when user clicks on a link.
> Absolutely false. I have built tons of tools which are feature complete and continue to work to this day without intervention
And how many of these tools are mission critical to the point that they are installed on almost every Linux box in existence, probably invoked tens of billions of times per day, both by humans and software, and the entire world would be in deep goddamn trouble if there was a serious security flaw that doesn't get fixed immediately?
You’ve moved the goalposts so far away, they’ve left the breathable atmosphere. Look at your condition, it’s over 50 words. I didn’t say “all software can be done”, I just said that it’s not true that software is never done. It’s not a universal truth that applies to all software.
> I mean, git is just as "local-first" (a git repo is just a directory after all), and the standard git-toolchain includes a server, so...
It isn't though, Fossil integrates all the data around the code too in the "repository", so issues, wiki, documentation, notes and so on are all together, not like in git where most commonly you have those things on another platform, or you use something like `git notes` which has maybe 10% of the features of the respective Fossil feature.
Email isn't a wiki, bug tracking, documentation and all the other stuff Fossil offers as part of their core design. The point is for it to be in one place, and local-first.
> My answer to this is to often get the LLMs to do multiple rounds of code review
So I am supposed to trust the machine, that I know I cannot trust to write the initial code correctly, to somehow do the review correctly? Possibly multiple times? Without making NEW mistakes in the review process?
Sorry no sorry, but that sounds like trying to clean a dirty floor by rubbing more dirt over it.
It sounds to me like you may not have used a lot of these tools yet, because your response sounds like pushback around theoreticals.
Please try the tools (especially either Claude Code with Opus 4.5, or OpenAI Codex 5.2). Not at all saying they're perfect, but they are much better than you currently think they might be (judging by your statements).
AI code reviews are already quite good, and are only going to get better.
Why is the go-to always "you must not have used it" in lieu of the much more likely experience of having already seen and rejected first-hand the slop that it churns out? Synthetic benchmarks can rise all they want; Opus 4.5 is still completely useless at all but the most trivial F# code and, in more mainstream affairs, continues to choke even on basic ASP.NET Core configuration.
> It sounds to me like you may not have used a lot of these tools yet
And this is more and more becoming the default answer I get whenever I point out obvious flaws of LLM coding tools.
Did it occur to you that I know these flaws precisely because I work a lot with, and evaluate the performance of, LLM based coding tools? Also, we're almost 4y into the alleged "AI Boom" now. It's pretty safe to assume that almost everyone in a development capacity has spent at least some effort evaluating how these tools do. At this point, stating "you're using it wrong" is like assuming that people in 2010 didn't know which way to hold a smartphone.
Sorry no sorry, but when every criticism towards a tool elecits the response that people are not using it well, then maybe, just maybe, the flaw is not with all those people, but with the tool itself.
> Spending 4 years evaluating something that’s changing every month means almost nothing, sorry.
No need to be sorry. Because, if we accept that premise, you just countered your own argument.
If me evaluating these things for the past 4 years "means almost nothing" because they are changing sooo rapidly...then by the same logic, any experience with them also "means almost nothing". If the timeframe to get any experience with these models befor said experience becomes irelevant is as short as 90 days, then there is barely any difference between someone with experience and someone just starting out.
Meaning, under that premise, as long as I know how to code, I can evaluate these models, no matter how little I use them.
Luckily for me though, that's not the case anyway because...
> It’s about “if you last tried it more than 3 months ago,
...guessss what: I try these almost every week. It's part of my job to do so.
Implementation -> review cycles are very useful when iterating with CC. The point of the agent reviewer is not to take the place of your personal review, but to catch any low hanging fruit before you spend your valuable time reviewing.
> but to catch any low hanging fruit before you spend your valuable time reviewing.
And that would be great, if it wern't for the fact that I also have to review the reviewers review. So even for the "low hanging fruit", I need to double-check everything it does.
That is not my perspective. I don't review every review, instead use a review agent with fresh context to find as much as possible. After all automated reviews pass, I then review the final output diff. It saves a lot of back and forth, especially with a tight prompt for the review agent. Give the reviewer specific things to check and you won't see nearly as much garbage in your review.
Well, you can review its reasoning. And you can passively learn enough about, say, Rust to know if it's making a good point or not.
Or you will be challenged to define your own epistemic standard: what would it take for you to know if someone is making a good point or not?
For things you don't understand enough to review as comfortably, you can look for converging lines of conclusions across multiple reviews and then evaluate the diff between them.
I've used Claude Code a lot to help translate English to Spanish as a hobby. Not being a native Spanish speaker myself, there are cases where I don't know the nuances between two different options that otherwise seem equivalent.
Maybe I'll ask 2-3 Claude Code to compare the difference between two options in context and pitch me a recommendation, and I can drill down into their claims infinitely.
At no point do I need to go "ok I'll blindly trust this answer".
Humans do have capacity for deductive reasoning and understanding, at least. Which helps. LLMs do not. So would you trust somebody who can reason or somebody who can guess?
People work different than llms they fond things we don't and the reverse is also obviously true. As an example, a stavk ise after free was found in a large monolithic c++98 codebase at my megacorp. None of the static analyzers caught it, even after modernizing it and getting clang tidy modernize to pass, nothing found it. Asan would have found it if a unit test had covered that branch. As a human I found it but mostly because I knew there was a problem to find. An llm found and explained the bug succinctly. Having an llm be a reviewer for merge requests males a ton of sense.
LLMs have been marketed for years, with great meadia fanfare, as being almost magical, something that can do the job of software engineers. Every week, the hype is driven further.
This matters. When people get told everyday that XYZ is magic, some will believe so, and use it as if it is magic.
What's your point? Because people smoke cigarettes, people who buy unrelated things should be punished? Or because a store sells cigarettes, stores in general shouldn't be paid for what they sell? Or is the time and effort to find vulns valueless?
No, the implication that "THING" is the cause of something and therefore something needs to be done must withstand the scrutiny of "other THINGS" also causing that thing, and therefore the solution is attacking either only one cause or not the real root cause.
The fact that bad reports have to be triage doesn't change with AI. What changed is the volume, clearly. So the reasonable response is not to blame "AI" but to ask for help with the added volume.
If HN gets flooded by AI spam, is the right response shutting down HN? spam is spam whether AI does it or a dedicated and coordinated large numbers of humans do it. The problem doesn't change because of who is causing it in this case.
The change in volume was the tipping point between bug bounties being offered and devs being able to handle bad reports, and bug bounty nixed because devs no longer willing to handle the floos.
And the root cause for the change in volume is generative AI.
So yes, this is causally related.
> The problem doesn't change because of who is causing it in this case.
Wrong.
Because SCALE MATTERS. Scale is the difference between a few pebbles causing a minor inconvenience, and a landslide destroying a house.
So whatever makes the pebbles become a landslide, changed the problem. Completely.
How can you say "wrong." and then go on to say scale matters, that means scale is the problem, not who is reporting it, you contradicted yourself.
We're in agreement that it is a scale issue. When something needs to scale, you address the scale problem. Obviously the devs can't handle this volume, and I agree with that there too. Our disagreement is the response.
I guarantee that if they asked for volunteers they'll get at least 100 within a week. They can filter by previous bug triage experience and experience with C and the code base. My suggestion is to let people other than the devs triage bug reports, that will resolve the scale problem. curl devs never have to see a bug not triaged by a human they've vetted. There is also no requirement on their part to respond to a certain number of bug reports, so with or without help, they can let the stack pile up and it will still be better than nothing.
Scenario 2: US troops land and would now have to deal with some NATO soldiers.
Regardless of how many NATO soldiers we're talking about, the geopolitical stakes in S2 are orders of magnitude higher than in S1. And so is the political backlash, problems at home, reasons for other nations to respond, etc.
So yes, these few troops, being there, in an official capacity as a NATO deployment no less, matters. Alot.
