NOTE TO ALL PERSPECTIVE WHISTLE BLOWERS
EVEN THE ANNOYING ONES THAT HAVE A LONG
ESTABLISHED HISTORY OF BEING JERKS:
YOU CAN REACH EVAN VIA SIGNAL
281.901.0011.
OLIVE BRANCH, ETC.
> HN has a an automated simple proxy for flame-war detection. One characteristic of flame-wars is that people get into a to'n'fro over the issue, and the number of comments balloons. However, no one else is really interested, so they don't upvote the submisson, and the participants can only upvote a submission once, so the number of points doesn't increase.
> Result is that a simply proxy for a flame-war is the number of comments on a submission out-stripping the number of votes.
> A side-effect of that is that if there's a mildly interesting submission that lots of people comment on, but very few upvote, then the flame-war penalty will be triggered, and the submission will sink like a stone, never to be seen again.
> Scott and I get emailed every time that software trips so we can quickly look at which threads are being penalized and reverse the penalty when it isn't helpful. The only time we don't do that is when we're sleeping.
> We tend to call it the 'overheated discussion detector' these days, since it detects more than flamewars. However, that phrase is more awkward to say than 'flamewar detector'. If anyone can come up with a better name I'd love to hear it.
> Turning that software off is not an option, because HN would be overwhelmingly more dominated by flamewars if we did so. It's not primarily the individual threads that I fear, it's the systemic effects of having them be more dominant. HN exists most of all for the quieter, deeper, more out-of-the-way finds that would be the first to get excluded under such a regime. That would really be an existential risk to HN.
> Incidentally, that last point generalizes. When people complain that we don't do X, for some obvious X, it isn't because we don't value X (e.g. free speech or whatnot). It's because we're worried about systemic effects.
---
Quite simply said, the post and comments got overheated and looked like flame wars and so was pushed off the to have it cool down.
I know my fame and legendary repute may lead one to believe otherwise, but I hate drama. I probably hate drama more than anyone else on the planet. We should _just_ focus on the facts when I post. And on the facts, I know for certain that we're always on the same page and in agreement, so long as you're right. And you're normally right.
IMHO you are absolutely in the right here but yearly ban might do you good. This level of engagement with a single corporate site is not healthy for anybody. I know it's unjust (all life is), hurtful and evokes all negative emotions but sometimes you need to be hurting a bit to get out of local minimum in your life that sucks your time and resources by just being not terrible enough to leave.
Besides SO viewership drops like a stone since LLMs became a thing. Soon it'll be an open-air museum rather than a staple.
You can't be the best troll, if you never troll: I never troll, ever. But other than that. Luigi's acct wasn't renamed by a community mod, from Zoe and as quoted in the article
> I can confirm SE, Inc. were the ones to clear his name. A reason was not specified anywhere obvious. Mods have been given explicit instructions not to touch that profile. While this particular incident may be limited to SO, the implications of this affect the entire network
It's not clear why the request parser would have to be trusted. I assume you're just speaking about the call to execve running in context? That's not much of a request parser. At the point that you tell `run0` to launch a shell, you're not calling the actual commands to the shell the request parser, right?
I also think the notion of an untrusted client is kind of a hashed out thing. As said in the post itself, `run0` is an interface to `systemd-run`. `systemd-run` as a client may be more _involved_ but it doesn't seem like that has any relevance to whether or not it's more secure. It's a separate layer for the insecurity. While sudo is a single process, if it was two processes it wouldn't all have to run as root. That by necessity means something that was previously running as root isn't, which makes it more secure -- not less, right?
The actual elevator process is systemd itself which already runs as init on every machine you'll have `run0`. But by nature it's always the top of the process tree, it seems like it's _less_ complex to have systemd-init the immediate parent process. There are fewer thing that can leak into or be inherited by the spawned process.
> It's not clear why the request parser would have to be trusted [...] I assume you're just speaking about the call to execve running in context
No, I'm talking about the part which is going to parse the command line, arguments, environment, decide whether the user is allowed the elevation or not, decide which environment, file descriptors, etc. are to be passed through, etc. All of this must NOT be in the same context as the caller, as it can simply fake all these decisions. You need to handle this from a process running in another context (suid or not).
> While sudo is a single process, if it was two processes it wouldn't all have to run as root
Yes it would ? At least one of them would need to be suid for the actual execution. But the problem is that the process which was NOT suid would be running as the same user as the caller, so by the same reason as above -- you cannot trust what it does. The only thing the non-root process would be able to do is to massage the request a bit, then forward it (IPC!) to the root/suid process which you CAN trust. We are just moving the security border, and it is not clear what would be gained by it.
In this proposal, instead of a suid binary, you have a constantly running "sudod" process (or worse, pid 1), but otherwise is the same. Everything must be IPC'd to it.
> There are fewer thing that can leak into or be inherited by the spawned process.
To have this IPC complexity just because apparently we can't figure out how to do suid without inheriting anything is bonkers.
As a trade-off you now have a user-accessible IPC system with the _gazillion_ possible vulnerabilities it entails. At least before you needed root to talk to pid1..
> As a trade-off you now have a user-accessible IPC system with the _gazillion_ possible vulnerabilities it entails. At least before you needed root to talk to pid1..
Read the linked post again. This is all already available, and always has been, since forever.
I also don't understand your argument on simplicity. You make mention in multiple points about "await". You don't like it. We get it. In what way is it not simple? And how does it follow that Go is more simple (using the same definition).
I actually quite like it. C# has a peculiar async runtime that when misused tends to deadlock, and that's the entirety of my issue with it... and the fact that async/await is a half baked monad in most languages, but I say that with love (mostly) :)
