Sean Middleditch2d ago

GDB pretty printing w/ Python is really powerful, but also it's ridiculously high friction compared to Microsoft's .natvis.

Completely aside from any syntactic whatever, you can't (safely) load any ol' Python script in a project's repo, but you can safely load up associated .natvis files, which makes Microsoft's solution vastly superior for library users.

And there's really no reason that GDB and LLDB can't just implement .natvis support out of the box. (Yes, I know there are Python libraries that add a subset of .natvis support to GDB, but that doesn't solve the "out of the box" part at all.) Or hell, if they really hate Microsoft (who doesn't?) then implement their own declarative debug visualizer format.

(This post brought to you by me using Clang 22 for _Defer via mingw and now having to write *****ing Python to make my pure C project comfortably debuggable.)

Show threadBjörkus "No time_t to Die" Dorkus2d ago
@seanmiddleditch I've noticed that a lot of people sort of forgot the power in "I just have a data file I can carry around that can be safely loaded because its restriction is the point" and just keep doing things like "What if I gave someone access to an unrestricted python / Lua / JavaScript / {etc.} interpreter as part of my program?".
Show threadBjörkus "No time_t to Die" Dorkus2d ago
@seanmiddleditch The worst part is they don't even try to lock things down. Like, oh, yeah, sure, here's my Lua interpreter with direct access to the whole file system. And I can access the FFI so I can touch every single system call if I really try. Awesome. Thanks. This won't come back to fuck us all over!
Show threadSean Middleditch

@thephd Haha, yeah, I'll be honest I've struggled with that in the past (and will again in the future).

On the one hand, yeah I don't really need to give people another way to load up untrusted logic that has that kind of access.

On the other hand, in most of the cases where scripts are manually installed, whatever is installing the scripts could just as easily install or run an executable (or instruct the hapless user to do so), so restricting the scripting itself for those apps is security theatre.

As much as I want to throw shade at MS for teaching people to open random .exe files to install software, the *nix people are just as fucked with the prevalence of "unpack this tarball and then run its build script" or "pipe this curl output to /bin/sh" or what not.

Mar 25 at 3:06amWeb
Show threadSean Middleditch2d ago
@thephd btw the hapless user is me. I've download a ton of random shit I've bought off itch.io or whatever and happily clicked through Windows' "untrusted application" dialog because I need my indie dungeon crawler fix, with my security strategy mostly being "would anyone named RetroByteGal95 with a furry avatar and 7 published retro games really have any ill intention towards me or mine? I think not."
Show threadBjörkus "No time_t to Die" Dorkus2d ago
@seanmiddleditch truly, there is no security posture more foolproof!
Show threadXarn2d ago
@seanmiddleditch @thephd As an exercise, I've tried sandboxing all stuff like this for few months. It wasn't nearly as bad as I expected it to be (thanks to Windows having pretty good integration with HyperV nowadays), but especially for things where I would want persistent progress like games, it definitely introduced a lot of friction.