Diseased Open Source Software Community - it's about ethics in Code of Conducts

  • 🐕 I am attempting to get the site runnning as fast as possible. If you are experiencing slow page load times, please report it.
Learn all of these and realize that they're used in a few obscure proprietary industrial applications and nowhere else ...and also that they offer few - if any - benefits over contemporary languages
Hey, as far as I'm concerned, everyone in CS/CE should at least dabble in functional programming and contracts. APL bit can be pure wankery, but then again, from the point of learning shit, it's pretty interesting imho. Aside from that, programming language is ultimately just a tool. Real CompSci Niggas use pen, paper and coffee machine and leave the trivial stage of implementation to slaves undergrads.
 
The dependency of Poettering's latest dumbfuckery on polkit reminded me of something.

Here's a fascinating list of articles demonstrating how Ada implementations wouldn't fall victim to the same programming flaws as some well-known C language programs have:
https://annexi-strayline.com/blog/ (archive)

The series starts with the "goto fail" flaw, but the next two in the series concern exactly polkit:
https://annexi-strayline.com/blog/posts/2/ (archive)
https://annexi-strayline.com/blog/posts/3/ (archive)

Now, to be brief, here's part of the description of that flaw:
It was a long, convoluted trace, but we have finally arrived at ground zero. Our large guint32 uid is passed into polkit_unix_user_new, which expects a signed value that is almost always going to be the same bit-width. A classic integer overflow situation ensues, and we enter into the function with a negative uid. Don't worry, the hopelessly over-engineered bolt-on object-oriented C wonder library glib has us covered (see part 2 for more on this dumpster fire of a library).
After running the constructor, the initial call to g_object_new then sets tries to set uid property to the given value, will then get limited if needed. Of course, our magic user gets "limited" to 0, and thus the "PolkitIdentity" returned will cause Polkit_Identity_Is_Root to evaluate to true.
So, users with certain user IDs got to play root.

Oh well, I'm sure Poettering can be trusted to write better software from here on out. Then again, the approach the xz malware took may not be necessary after this gets deployed widely. It'll just get easier to poke even more holes in this Swiss cheese.
 
Get ready for more SystemD dumbfuckery
It's at least better than alternatives such as sudo since it doesn't rely on the brain damaged hack known as the suid bit to work.
But if you take a step back you will realize that having users be able to impersonate other users is a bad idea too. If a user has permission to do something they should just be able to do it without impersonating someone else. The whole existence of the root user itself doesn't even make sense from modern design principals.
 
It's at least better than alternatives such as sudo since it doesn't rely on the brain damaged hack known as the suid bit to work.
But if you take a step back you will realize that having users be able to impersonate other users is a bad idea too. If a user has permission to do something they should just be able to do it without impersonating someone else. The whole existence of the root user itself doesn't even make sense from modern design principals.
But it works. Simplicity is a virtue when it comes to security, which a lot of people seem to forget. (See also: SELinux, Windows UAC, Windows ACLs, Windows SIDs, Windows tokens, Windows Active Directory...)
 
@UERISIMILITUDO dindu nuffin, he a good boy whose gettin his system together, yal'l Unix weenies just hate him because you ain't him.

Lennart Poettering said:
But enough about all that security blabla. The tool is also a lot more fun to use than sudo. For example, by default it will tint your terminal background in a reddish tone while you are operating with elevated privileges.
Leaving aside how he bitches about muh complex SUID binaries only to introduce an overcomplicated polkit clusterfuck in its stead, what the hell is this? The absolute last thing I want from security-critical wrappers is to randomly insert funny escape sequences into my output. God, this is the sequel to Systemd Reimplements Chown And Forgets About .. that nobody asked for.
 
The absolute last thing I want from security-critical wrappers is to randomly insert funny escape sequences into my output. God, this is the sequel to Systemd Reimplements Chown And Forgets About .. that nobody asked for.
If only shells had some way to automatically mark your prompt when you had a root shell. Maybe a different symbol or something. And then a way to change that if you want different colors or something. Nah, let's bloat nusudo with more stupid features.
 
If only shells had some way to automatically mark your prompt when you had a root shell. Maybe a different symbol or something. And then a way to change that if you want different colors or something. Nah, let's bloat nusudo with more stupid features.
Oh noes, how difficult that was.
2024-05-01_10-38.png
And now you can all dox me since you know my username is "pi" and I have a computer called "hapi"
Was for HomeAssistant, which I didn't actually use but haven't bothered to rename the pi.
 
sudo only exists for security against human error / laziness, right?

Any time you wanted to use sudo, you could just do su to switch to root, run your commands, and then switch back out.

Other than that, the only thing that sudo could possibly do that su couldn't is allow you to track who was logged in as root, supposing that you have your logs being sent off to an external log server somewhere that the user doesn't have access to, unless there's some other scenario I'm not thinking of.

Assuming you already have polkit installed, this seems all around better, doesn't it? Systemd/Polkit is already an attack surface, and it's not really any larger if you add sudo to it since it already has that capability. This just eliminates an extra attack surface while also adding more control to the sudo replacement.

If you're not using systemd already then then the whole thing is moot. Just keep using sudo or doas or whatever. If you're running something embedded, you're likely not using systemd anyway, and if you're running in a container or something you probably don't need sudo in the first place.
 
Tangentially FOSS related: An oopsie woopsie at jsDelivr caused a shit load of websites to break for 5 hours in shithole countries yesterday. https://www.jsdelivr.com/blog/jsdelivr-may-outage-postmortem/

tl;dr
* They use a DNS LB to send some traffic to Fastly, some to Cloudflare with a preference to Cloudflare for shithole countries (Africa, Asia, and certain countries in Europe and Latin America)
* Cloudflare is not used for DNS hosting but is used for proxying so they had DNS-based TLS cert verification
* After Cloudflare changed from using DigiCert to Google Trust Services, their DNS-based verification method broke so it fell back to HTTP with no warning
* The HTTP method failed as the bot performing verification was served Fastly instead of Cloudflare
* Cloudflare automatically fell back to an expired certificate with no warning
* The DNS LB failed to react to the expired cert and kept sending users to Cloudflare

The author seems like a cuck as he's basically decided it's all his fault and it's perfectly fine for Cloudflare to completely fuck up your site with no notification since it's provided to him for free as part of their sponsorship.

Personally I place the blame at JavaScript developers who are incapable of uploading a file to a web server and instead insist on piggybacking CDNs.
 
Back