Unknown parent

gotosocial - Link to source

pistolero

@eriner @graf

> various runtime restrictions that you have to test. Sometimes it works, sometimes acls and policy flag/prevent weird shell interactions that are commonly "malicious", such as /dev/tcp interaction

It's not even a real /dev; gawk (almost certainly present) has a different, incompatible /inet/{tcp,udp}/$shit and is almost guaranteed to be present and probably overlooked if zsh is.

> my experience is that python is far more rare than bash or perl.

bash maybe because I don't know of anyone that *doesn't* ship bash, but Debuntu requires Python nowadays, I believe CentOS/RHEL require it.

Unknown parent

mastodon - Link to source

Matt Hamilton

@p @graf > /bin/sh

it isn't always about what's present, but various runtime restrictions that you have to test. Sometimes it works, sometimes acls and policy flag/prevent weird shell interactions that are commonly "malicious", such as /dev/tcp interaction. Though, zsh's (if present) tcp module often isn't ;)

Unless the app is written in python and using it for runtime, my experience is that python is far more rare than bash or perl.

Unknown parent

@eriner @graf

> I never said "compiled languages are always fast", I said all interpreted languages are slow.

It's still wrong.

> I use zsh

"The only shell worse than bash, until fish got popular."

> when you want a reverse shell you have to use what's there, and bash usually is

They have an entire /bin/sh.

> IIRC most distro distributions of nginx include perl as a runtime dependency.

Half of them nowadays mandate Python. Almost any box is going to have Python.

Unknown parent

@p @graf I never said "compiled languages are always fast", I said all interpreted languages are slow.

> bash is terrible

I mean, I use zsh, but when you want a reverse shell you have to use what's there, and bash usually is. Sometimes for one reason or another it can't be done with bash, but most systems that have bash also have perl. IIRC most distro distributions of nginx include perl as a runtime dependency.

in reply to Matt Hamilton

@eriner @graf

> lets be real, all interpreted languages are dog shit slow.

Haskell's compiled, but find a Haskell program that is faster than the equivalent awk.

Not the case, no. Ruby isn't even that slow, but Rails does retarded shit like blowing out the method dispatch cache multiple times per *request*, it's all factoryfactories. I *just* said "things written in the same language that do not use Rails". I do not think you know how goddamn retarded Rails is. Ruby's a great language if you're not an idiot; unfortunately, it got popular with idiots, and I watched this happen, having used it before Rails existed. (Luckily, most of the idiots left for JS, but a handful of total dipshits have stuck around.)

> bash & /dev/tcp

bash is terrible and their "/dev/tcp" bullshit is terrible and netcat is not hard.

Unknown parent

@graf @p I've never contributed to Mastodon (or Pleroma/whatever) because the languages they use disinterest me, and the only Go fedi project is run by crazies.

I've used Go (and zsh) almost exclusively for half a decade and I've grown into quite a happy rut.

I wasn't bothered by the lack of generics, but even that's taken care of (though I think it's a tad ugly).

in reply to Matt Hamilton

@eriner @graf

> the only Go fedi project is run by crazies

There are at least four, you've just only apparently paid attention to the glowie one. (They are not crazy, they are just glowies.) Honk is in Go. Here: fedilist.com/source-code

> zsh

<img class=" title=":vomit:"/>

> I wasn't bothered by the lack of generics, but even that's taken care of (though I think it's a tad ugly).

What they did looks a lot like how they did it in Limbo.

Unknown parent

gotosocial - Link to source

pistolero

@eriner @graf

> most of the stuff I see in corporate environments uses containers

Ah, okay, right. Yes. Nah, you're right.

> have the monkey dance about "reproducible builds" and

Yeah, shit like that, all of this engineering effort that amounts to "Who can we fire?" and doesn't stop CVE-2024-3094 (the libxz hole).

> "centralized dependency management"

Well, this part would help with "us-east-1 is down because something retarded happened again" but then they shove it into AWS anyway.

in reply to pistolero

@p @graf most of the stuff I see in corporate environments uses containers, and their ops teams almost always push them toward a unified slim image(s) eventually because the people staring at the AWS/GCP/Azure receipts are hounding them to save money on the k8s cluster project that just quadrupled their monthly expenditures, and they can pass the buck to the internal security dpt and have the monkey dance about "reproducible builds" and "centralized dependency management" or something.
Unknown parent

gotosocial - Link to source

pistolero

@phnt @eriner @graf This shit I do not get; Python is a pain in the ass, it's not as convenient for scripting as the shell or Perl or Ruby, and it's not stable. A shell script or a C program from the 80s will often still work now, Ruby code that I wrote for 1.6 still works in 3.x; even *JavaScript* manages backwards-compatibility. Good luck getting a Python program from last year to build cleanly without guessing which Ubuntu version that guy was running and then building in a chroot.
in reply to pistolero

@p @eriner @graf I don't know how Python can make so many breaking changes in every minor release bump, it's beyond my understanding. The reason why it is so prevalent in core systems utils now is that it was bundled with OSes by default at some point and then using Ruby for system utils became a "It's better, but you would need to download a whole new language instead of using the one in the OS already. So we'll use the worse option that comes with the OS." It's one of the reasons why I don't really use Ruby myself either; most things are either posix shell or Python.

Ruby also didn't and still doesn't have a good reputation when it comes to speed, but not like Python is any better with its arrays. Python sidestepped the issue by bolting more C libraries to it.

in reply to Phantasm

@phnt @eriner @graf

> "It's better, but you would need to download a whole new language instead of using the one in the OS already. So we'll use the worse option that comes with the OS."

Yeah, I can see picking Python over Perl 5; just *barely*, though.

> Ruby also didn't and still doesn't have a good reputation when it comes to speed, but not like Python is any better with its arrays.

Well, reputation rather than actual performance.

On the other hand, 99% of the times you use any scripting language and 90% of the time you use an application- or systems-programming language, if it's CPU-bound instead of I/O-bound, you've fucked up.

> Python sidestepped the issue by bolting more C libraries to it.

Yeah, and "This looks better when I'm typesetting my paper" cascades into an ecosystem.

in reply to Phantasm

@phnt @p @eriner @graf

> I don't know how Python can make so many breaking changes in every minor release bump, it's beyond my understanding

On that exact topic: there are unpatched CVEs in Python (edit: releases; they fixed in master or whatever) right now because they're concerned that fixing the CVEs would be a breaking change.

except the only explanation for wanting that behavior is to use the vulnerability

This entry was edited (yesterday, 3:42 PM)