1,012 karma · joined September 15, 2021
(Indeed, cosmo libc does exactly that, so it's definitely possible.)
Strictly speaking, that's false, my hobby project chawan[1] supports capsicum :)
Anyway, IME capsicum vs pledge doesn't make much of a difference because seccomp already forces you into a specific sandbox architecture; after implementing that, adjusting the result to support the rest takes (relatively) little effort. So I think the difference in adoption is more because nobody has volunteered to do the work for capsicum (and keep it up to date etc.)
[1]: https://chawan.net
No, the "single while loop" is just harder to implement than a naive recursion, because recursion is a natural way to implement tree traversal. With a while loop, you need an explicit stack, which is more complex.
(A stackless traversal seems unrealistic here, as getting the succeeding node would be too expensive. Not that I've tried...)
> I look at code from the heirloom project and, despite its warts, I think we've lost something in the past 45 years or so.
I've just tried and heirloom rm segfaults on the same test too. Which is no wonder, seeing how that code also recurses.
(It's mentioned somewhere else in the thread, but this is exactly the reason why GNU had to specify "no hard limits" as a policy. Unix used to be full of such bugs.)
function rm(node) {
for (const child of ls(node))
rm(child);
unlink(node);
}
(I guess by now you have a solid retirement plan; maybe if the field had been burnt to the ground while you were younger, you'd have had a different opinion.)
Now there is a plagiarism machine built on top of decades of this work that seemingly solves 3 and promises to solve 2 (badly, but usually this matters little), the programmers that (indirectly) helped build it are told they're fools for doing so, and threatened by losing their status if they don't adapt to the "entrepreneurial way" (well, the full promise is "you'll lose it anyway, but if you cooperate in stuffing sama's pockets then maybe you get to keep it a bit longer").
So what really surprises me is not that people are upset but that so few are.
So why is Cloudflare saying the author got blocked because of WebGL?
> > Such things are blocked in WebKit, and have been for years. Meaning it's tracking so awful that even Apple would block it, and as far as I can tell it's not the kind of privacy protection you can easily disable in it.
> This is also false. Webgl fingerprinting works just fine on Safari. They might try to mitigate it by adding some noise, but that's not so different than what firefox does, and is certainly not "blocked".
While I don't have an iDevice to try, the assumption that they are special cased is fair... because they are: https://blog.cloudflare.com/eliminating-captchas-on-iphones-...
(Yes, this is basically WEI in a shinier package.)
CORS has no relation to this issue. Cross-origin means there are at least two origins, but in this case there is only one (where you're trying to navigate).
> But if request is originating from inside the network (as it would from a terminal emulator)
Why would the terminal make requests? Obviously it will dispatch the link to another program specialized in making requests to a protocol, like... a browser?
> Granted, on its own, this should be safe. But attacks are usually composed from multiple bugs and/or weaknesses in design. Hence why security folk keep talking about “defence in depth”
Every feature can be part of an exploit chain, but the "clicking a URL will always lead to the text it is under" ship has sailed 30+ years ago. If your system cannot safely handle this operation then you're in deep trouble, and I don't see how crippling every program in existence is the right solution to that.
> I actually voiced some concerns with this original hyperlink proposal several years back. In fact lots of developers and security researchers did.
Based on what you've written: you and other self-claimed "security researchers" started spamming this spec with concern trolling about hypothetical (non-existent) "security issues", then the author finally got tired and locked down comments, which were obviously intended for people interested in the feature, not those trying to sabotage it.
> Just one persons mission to dictate how everyone else’s terminal, and security model, should operate.
Nowhere does the proposal say that your terminal has to implement this. Indeed, if you have a working ANSI parser the escape sequence is ignored automatically (as the spec also explains).
Have you considered that the person trying to dictate how others' terminals should operate might be you?
Also, this is not limited to HREF, it's defined in URL[0] so you can also put newlines in new URL("...") etc.
An important nuance you seem to be missing is that SUSv3 is equivalent to "IEEE Std 1003.1-2001" (that is, POSIX 2001).
In practice, I've had to work around more POSIX compatibility issues in macOS than in all other actively developed (Free) Unix-likes, combined.
(To differentiate between the case where it's actually two vowels, you have to put an apostrophe inbetween; their example is 小唄 -> ko'uta.)
(You can set a custom w3mimgdisplay command, but it has to speak the same protocol as w3mimgdisplay. If you're feeling adventurous, you can try modifying https://github.com/uobikiemukot/sdump/tree/master/yaimg-sixe....)
Unifont is also dual-licensed under GPLv2/SIL OFL.
This already exists:
*, ::before, ::after { all: unset }I also don't understand why they never specced the (much simpler) `text-align: -moz-left/-moz-right/-moz-center' which already had precedent in HTML with `<div align=left/right/center>'. It's the saddest part of the "center a div" saga, all the W3C had to do to fix it is to assign a standard keyword to a feature that everybody already implemented, but to this day it still hasn't happened.[2]
[1]: https://pcwalton.github.io/_posts/2014-02-25-revamped-parall...
[2]: After many long decades, they did finally specify block-level `justify-items'. Two problems: a) it's backwards-incompatible with text-align, b) it still doesn't work in Gecko.
Except for automations that happen to create new repositories.
Markdown is a superset of HTML, so your assertion cannot be true. But even an HTML-less subset is very hard to parse efficiently (or, at all) because of the various grammatical ambiguities. And then there's the various competing definitions...
You can do this with seccomp if you're libc. A new syscall is of no consequence for the seccomp filter unless libc starts using it, in which case libc can just add it to the filter. (Of course the filter has to be an allow-list.)
> And 2) OpenBSD limits syscalls to be done from libc, and libc & kernel are released together. Other libs need to go through libc.
That avoids one failure mode, but I think you assign too much importance to it. If your dependency uses a raw syscall (and let's be honest this isn't that common), you'll see your program SIGSYS and add it manually.
If you have so many constantly changing dependencies that you can't tell/test which ones use raw syscalls and when, you have no hope of successfully using pledge either.
> But I don't think that we need to throw out the baby with that bathwater.
We agree here, just not on which baby :)
> And it's not just about libfoo doing raw syscalls. `unveil()` allows blocking off the filesystem.
You're right, seccomp is unsuitable for implementing unveil because it can't inspect contents of pointers. I believe Cosmopolitan uses Landlock for it.
> Though another problem is that it doesn't help child processes with a statically compiled newer libc
If you're trying to pledge a program written by somebody else, expect problems on OBSD too because pledge was not designed for that. (It can work in many cases, but that's kind of incidental.)
If it's your own program, fine, but that means you're compiling your binaries with different libcs and then wat.
> So yeah, because they mandate syscalls from libc, ironically OpenBSD should have been able to make pledge/unveil a libc feature using a seccomp-like API, or hell, implemented entirely in user space. But Linux, which has that API, kinda can't.
My take is "it can, with caveats that don't matter in 99% the cases pledge is useful in." (Entirely in user space no, with seccomp yes.)
Well but isn't that a more general problem with pledge? I can link to libfoo, drop rpath privileges, and it'll work fine until libfoo starts lazily loading /etc/fooconf (etc.)
A nice thing about pledge is that it's modularized well enough so such problems don't occur very often, but I'd argue it's not less common of an issue than "libfoo started doing raw syscalls." The solution is also the same: a) ask libfoo not to do it, or b) isolate libfoo in an auxiliary process, or c) switch to libbar.
> And at the very least you'll also be linking to libseccomp. :-)
libseccomp proponents won't tell you this, but you can in fact use seccomp without libseccomp, as does Cosmopolitan libc. All libseccomp does is abstract away CPU architecture differences, which a libc already has to do by itself anyway.
(In my project, I got annoyed enough by the kernel header dependency that I just replaced libseccomp with a shell script: https://codeberg.org/bptato/chawan/src/commit/cad5664fc0aa10... although this might have gotten me a place reserved in hell.)
(Then at some point it stops truncating and scrolls off the screen.)
It's barely usable by itself but I don't think it's an inherent problem of seccomp-bpf, rather the lack of libc support. Surely the task of "determine which syscalls are used for feature X" belongs in the software that decides which syscalls to use for feature X.
In fact, Cosmopolitan libc implements pledge on Linux on top of seccomp-bpf: https://justine.lol/pledge/