> These are asciinema recordings of real terminal sessions, rendered as text rather than video. Playback caps idle pauses at two seconds and changes nothing else.
Thanks? This sounds like it's the LLM's response to the prompter, not something you should display on the page itself...
I think this is a slightly different problem. The absence of an optional field, if that's a legal state, is meaningful every time you use the type, so you encode it on the field: `phone: ValidPhoneNumber | null`. When it's not null you're still guaranteed a valid phone number. When it is null, that's a legal state you have to handle and which is domain logic, not validation you forgot to do.
The combinatorial explosion you're picturing only shows up if you make a separate type per combination of present fields, but you don't need to. An independent optional field stays one `T | null`. You only reach for distinct types when fields are correlated and present together because they represent a state, and then it's a discriminated union on a status field, which is N states, not 2^N.
This campaign is still ongoing. I just got an email that one of my old packages (which hasn't worked for years and was orphaned for a while) was adopted and immediately a malicious commit was pushed. They seem to be using bun instead of npm now, so any npm-based workaround likely isn't effective.
That would've been a cool PoC to work on as well, but seems a fair bit more complicated than the BadUSB-style attack I ended up doing. Would've had to do a lot more RE to figure out how to interact with the whole microphone subsystem, I think.
> A probe packet contains the MAC address as well as the list of all the past Wi-fi networks that your device has tried to join before, which can reveal a lot about you!
Generally, most modern devices send broadcast/wildcard probes precisely to avoid leaking the PNL. From what I know, directed probes are only sent for hidden APs.
From personal experience, there have been a few papercuts (mostly trying to figure out why runners aren't picking up jobs), but it isn't too hard to debug and the CI format is simple. When it works, it works well enough. It uses a similar workflow as GitHub actions. Some, but not all, actions are even interchangeable or at least portable from GitHub without much fuss.
I wish my city only had a single case like that. Unfortunately, in Tallinn, it is extremely common that a bike path is suddenly routed onto the curb, and that's when you're lucky. For some paths, the path just... ends, and you suddenly find yourself right in the middle of car traffic. Unfortunately, the city leadership is anti-bike and pro-car, and it shows in the infrastructure.
Paths where pedestrians and bikers (and other light transportation vehicles) are mixed are overwhelmingly common.
According to the linked homepage, the memory usage seems decent (few hundred megs for most use cases when working with a 3.3G logfile). There's a screenshot with various tasks and what the peak memory usage is.
At some point you need to keep quite a large context in memory to have both decent performance and useful features (that aren't unbearably slow to use). lnav seems to land at a reasonable middle ground.
Good question! I wasn't too concerned about this, because the only way you could even interact with the OS where the server was running was via HTTP requests, which are fairly limited in nature. The OS or kernel itself wasn't directly exposed per se.
Am I missing something here? Colonial merchant ledgers and 18th-century accounting practices have been extensively digitized and discussed in academic literature. The model has almost certainly seen examples where these calculations are broken down or explained. It could be interpolating from similar training examples rather than "reasoning."
> yep. no auth. just an email parameter. and what did it return?
> full names. emails. phone numbers. flight receipts. all just by passing an email address in a URL.
> i reported it through their security bounty program, made a bug fix pr (because apparently that's how you get things done around here), and maybe made the slight mistake of sharing the vulnerable endpoint in that group chat - which less than 10 people saw, for what that's worth.
The author then proceeds:
> their security bounty program states minimum payouts for this kind of thing start around $150. but exposing passport numbers (which are classed as government documents) should bump it up significantly. apparently "responsible disclosure" means "don't tell anyone, even in a private chat" so they docked the entire payout.
I'm not sure why they're being seemingly sarcastic about responsible disclosure. Yes, responsible disclosure absolutely means that you disclose this to the vendor before disclosing it to anyone else. As someone who works as a penetration tester and security researcher (both at work and in my free time), in my opinion, there should be no confusion about what responsible disclosure is. You disclosing the vulnerability in public before the vendor has had the chance to fix or apparently even triage it is not "responsible disclosure" or a "slight mistake".
I pentest network devices (amongst other things) for a living, and the way these usually work is that they have dnsmasq running in the background and to accept user config values, templating is used to generate dnsmasq-specific configuration files which are then fed into dnsmasq. I cannot overstate how common this method is.
Some devices do this more securely than others. If you're able to inject newlines, it's highly likely that you can already achieve command execution by injecting directives. I wrote a bit about this technique here: https://blog.nns.ee/2025/07/24/dnsmasq-injection-trick/ (sorry for the self-plug). I think it's up to the device vendor to do this securely and not a concern for dnsmasq.
However, in this case, I feel like the concern is elsewhere and not the sole responsibility of the device vendors. Even if the vendor does templating securely, the vulnerable config options could still trigger the bug in dnsmasq itself and give some advantage to the attacker. Assuming the vulnerabilities themselves are legit, I'm finding it difficult to classify these issues as "bogus".