Less external dependencies

Except when it's a license violation or in something that ends up having a security vulnerability.

>Except when it's a license violation or in something that ends up having a security vulnerability.

What's more secure isn't so simple. If you vendor something with a vulnerability then it wont be patched. But vendoring may also mean you took the 2% of the library you need and not the 98% which reduces the surface area for vulnerabilities. And it can cut the other way - you may update a package that was previously good and is now vulnerable (regressions, supply chain attacks).

There is a balance that must be struck, and I think LLM's strike a better balance than people do. Dependencies are a convenience with a cost and LLM's can trivially copy or re-implement things that we cant.

> But vendoring may also mean you took the 2% of the library you need and not the 98% which reduces the surface area for vulnerabilities

If you aren't using a library function you're not vulnerable to exploits in that code: unused but imported code is inert (possible usable as a gadget if you're vulnerable elsewhere, but at that point you're screwed anyways) and most compilers/runtimes completely eliminate it.

> you may update a package that was previously good and is now vulnerable (regressions, supply chain attacks)

There are better mitigations to this than not using a library.

You still completely ignore the license violations.

You might be exposing it to attackers without intending to use it.

>You still completely ignore the license violations.

The ones that you are imagining to happen? Its not a problem because you could simply observe proper licensing.

>If you aren't using a library function you're not vulnerable to exploits in that code

Not true, just because you arent calling a function doesnt mean it cant run. Read up on Log4Shell.

In my experience so far Claude has been meticulous about avoiding license violations.

Great for static assets, potentially not-so-great for "load bearing" ;^) code

Yes it does depend on the dependency, and a static asset is on one end of the extreme.

Every time I try to get a npm based project running (or one of my forks of one), half the packages don't exist anymore or I need to spend hours fixing breaking changes.

It's usually more straightforward to just rebuild it from scratch — not to mention infinitely more satisfying — and that was true before AI!

Language ecosystems tend to exist on a continuum. I love TypeScript but dread the dependency management because it's so often bit-rotted.

On the other hand, I routinely build Java/JVM projects with dependencies that haven't been updated in a decade that compile without issues.

Somewhere in the middle are most languages, I think.

One positive result is that you get a lot more variation in vulnerabilities. That probably sounds negative, but it isn't.

As an example, a black hat doesn't get 70% of web sites from one shared bug in PHP. They need to target specific sites, and the exploit isn't likely to work in very many other places.

I don't get it, in this scenario, would people also vibe code the PHP?

Yeah I guess, if they liked PHP. Could make a new version of ColdFusion if that's your thing too.

Genetic monocultures like bananas are at risk from a single species of fungus.

I've been playing around with LLM red teaming different server stacks with known or intentionally vulns in there and seeing how much damage they can do.

The one situation where they really can't get anywhere profitable is a unikernel webapp. With no source and no shell they find the vuln but the worst they can do with it is possibly poison or exfiltrate data as a one off, or crash the server. Often they can't even figure that out. Can't even leave themselves a reliable way back in.

Of course the traditional problem with unikernels is that you have to port EVERYTHING you need yourself. But the cheapness of this is exactly what we're talking about so.

Looks like security through obscurity's back on the menu.

These last few months, I have been building a capability-based language and runtime for fun based on the "port EVERYTHING" idea.

The language is restricted to permissions granted on startup and can only access the system via the runtime, which only supports a particular subset of linux syscalls. So, outside of the stdlib, whichever feature you need, you simply use an LLM to port an existing python/rust/JS/TS/Java library to the language and use it.

As the runtime has its own scheduler and GC, I have actually been wondering about the feasibility of skipping the linux kernel and making the runtime itself the "os." Given that so much modern hosting is actually done on virtual hardware, the drivers could be hosted within the runtime as well.

That's exciting! I'm interested to hear about the language design. I vibecoded a unikernel web server a few weeks ago, and I've been trying to extend it into a full capability-secure microkernel called KokalOS.

The language borrows syntax from Python (and a wee bit from Haskell) and is essentially syntactic sugar over facilities provided by the runtime:

- statically typed from end to end

- closed and open/extensible types

- closed types are immutable, open ones have two variants: immutable and mutable

- arrays have two variants: immutable and mutable

- no OOP/classes. inheritance is nominal and mainly exists to provide access to class membership (is X a Y?)

- functions operating on data

- UFCS exists to provide nice features like "apple".substr(...)

- first class functions and closures

- monomorphized generics

- tailcalls

- operator overloading

- modules and namespaces to control access

- erlang/beam style first class processes. So you `spawn` a function and communicate between processes using send/recv instead of async/await

Processes are completely isolated at the runtime level. Each has its own stack, heap, mailbox and GC.

The bytecode carries all type information. The VM will compile using AOT-on-load.

My own runtime-becomes-a-os idea is still just an idea. I haven't really pursued it with seriousness. Will probably do that once the language and runtime stabilize.

It sounds like you already have a pretty complete OS; you just don't have it running on bare metal (or on a hypervisor) yet.

I will publish the code when done to a GH repo over here: https://github.com/orgs/bhashika-org-in

I started in March and have gone through nearly 300 spec revisions for the runtime and language. Thanks to LLMs, I think I will have something useful to share in 2027.

My problem is that I have ten things in the pipeline at any given moment and I switch between them as time permits. So things get delayed a bit.

> KokalOS

A bare bones microkernel?

What do you mean?

I was trying to guess the meaning of the name.

Oh, Kokalos was the king in Sicily who gave Daidalos refuge after he and Ikaros fled from Minos.

Obscurity in the sense that the bad guy doesn't have your code doesn't hurt, but I think the real win could be that they need to specifically target your system to find your vulnerabilities. That could be a lot of compute and time to dedicate to a single target. So that kind of obscurity changes the economics of it for them.

What sorts of vulns are they finding in unikernels? Logic bugs, that sort of thing, or are there areas where they could get that tiny scope to do anything at all?

The advantage there shouldn't be obscurity, so much as very limited attack surface in the whole exposed stack.

Obscurity as a tool in security has never left. It shouldn't be a tool you depend on by itself. Update your ssh server when there are patches available. Use strong keys or ssh certificates. Disallow old, broken key exchange methods. Having an allow list in your firewall ACLs helps. Maybe only allow ssh from your internal network and make users outside your network be on the VPN. Maybe even have dedicated bounce boxes between user networks and the production systems.

But putting ssh for those bounce boxes on a nonstandard port that doesn't even show up to a remote system within the network until they've port-knocked on another two or four ports in the proper order on top of all that does not hurt security. Using a separate internal DNS zone that nobody outside your network has access to resolve doesn't hurt. Having your firewall drop packets from invalid sources instead of rejecting them doesn't hurt.

I think a better comparison for the parent is probably left-pad.

That sounds like a very reasonable thing to do, yes. If you ask Opus 5.5 to write you a dynamically typed interpreted language that can query a local SQL database, implicitly parse HTML form submissions, and be embedded in HTML templates interpreted by an Apache module, you'll probably have a usable alternative to PHP in 37 minutes. And if you ask it to do it in Rust with no unsafe, it won't have any memory error vulnerabilities.

You could have a new web server and database too. Maybe a new one every other day so you aren't a stationary target.

I suspect that a more effective mitigation would be to have an LLM read all your HTTP requests and the actions the web server proposes to take in response and give a Jev-like approve/disapprove decision.

All good, but I suspect we're thinking about different aspects. If I understand correctly, you're pointing out that nobody is tied to legacy software any more - they can spend 37 minutes to re-implement from scratch in a safe(r) language.

My point is that everyone doing their own thing their own way means an attacker doesn't get the next thousand sites for free after finding a vulnerability in one site.

Having an LLM as sentry is a fun idea too.

Right, I agree.

I assume that was sarcastic but I think it would actually work fairly well? At least if the ends could justify paying for that many tokens.

No, I sincerely try to avoid sarcasm, and I try to remember to down vote it when I see it. It's tough to get tone across in a text forum though, so I understand the confusion.

I didn't think it was sarcastic, but it's far enough outside the Overton window that I could see why someone would.

A few years ago, after ChatGPT but before agentic, I was asking AI for help with some projects. It kept recommending really good, well designed APIs, and gave me code snippets for them.

One small issue: they didn't exist! It had just hallucinated them!

Which was a real shame, since they were much nicer than the actual stuff I ended up finding.

I just realized, thinking about this now, that these days (and perhaps even back then), I could just say "ok now take this code and build the missing library so it actually works!"

Heh I remember that well. It got me super excited quite a few times until I tried to find the actual library :-D

Exactly. In almost all of those cases, the hallucinated functions absolutely should have been present in the API, and any reasonable developer would have expected them to be.

That was, in retrospect, an important bellwether.

Even before LLMs I found building custom software to be easier than using mature libraries for almost every task. I don't think this is a new problem.

Maybe take a step back and consider that your tastes or circumstances are rare.

Perhaps. I just never found it useful to spend a day learning the failure modes and edge cases of a general-purpose library I could hack into my use case with enough wrapper code handling the impedence mismatch when I could spend a day building exactly what we need, with the added benefit of owning the code when requirements inevitably change. Like, I'll use numpy at least half the time for numeric code; I'm not a masochist; but most libraries just don't pull their weight.

Did anyone else have to maintain this code?

Of course.

at least we have claude now I guess

Meaning?

When worldwideweb.app was first being developed an the RFCs and so forth for web servers and protocols were being discussed, one of the sticking point was what to call a URL --- the initial suggestion was "Universal Resource Locator", but the argument was made that users and writers were not librarians and that the distributed nature would preclude a given web page having a universally agreed-upon location and name, so instead the present "Uniform Resource Locator" was adopted.

What if there was a code sharing site where it was unambiguous what a given snippet of code would be named and where it would be stored, so that a user could just browse it and find a list of implementations for a given problem?

This of course runs up against one what John Ousterhout notes is one of the most difficult problems in computer science --- naming things --- in his book:

https://www.goodreads.com/en/book/show/39996759-a-philosophy...

I've tried to do it on a small-scale with my own work, storing bits of (la).tex code in a single file, but on reviewing it, I'll often find that I have written a given solution a second time and given the macro a slightly different name....

The thing is, solutions related to computing techniques, are few and can be found in algorithm textbooks. Some are then put into standard libraries.

Almost everything else is domain specific where you have to understand the domain first before understanding the code. And modeling a domain is all about tradeoffs between accuracy, performance, specific vs generic,…

Instead of collecting such solutions, a better approach is to master basic data structures, and then improve your modeling capabilities. After that, it’s mostly learning domain as they come (dsp, physic modeling, operating system concepts, relational database, graph theory, 3D geometry, accounting,…)

I am currently (re)reading Niklaus Wirth's book on data structures, and trying to work through the new Knuth fascicle on Constraint Satisfaction --- the idea here was that one could have a repository which one could search through to see/compare existing solutions as an alternative to using an existing library.

We've all been there. What happens is that you end up hiring someone to fix the unmaintainable mess a few years later when the pile of shit collapses.

(LLMs accelerate this and "a few years" can easily turn into "a few months".)

The real looking for libs often turns to be going down with potential security risks. In such cases is much preferable to not reuse unsigned and unclaimed code.

I find this concern rather misguided. Telling the LLM to integrate a "mature library" is often cheaper and faster than rebuilding (a fraction of) their features from scratch. If you really cannot be bothered with searching yourself, these days you can even tell the agent to scan pip/npm/whatever registry for you and give you options.