Shitpost so hard they cannot tell when you actually got brain disease, it's a really long-term bit.
Post
Remote status
Context
12Replies
43@graf @w0rm @p I professionally find security bugs for large American corporations who paid sixteen Indians to make Java apps to process electronic medical records.
I assure you there is nothing I havenโt seen before.
The recent mastodon issues have been pretty bad. An arbitrary user email+IP info disc was recent, and before that there was a pretty gnarly SSRF.
@graf @w0rm @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).
road_house_kung_fu.gif
spacekungfu.gif
> 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.
@p @w0rm @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.
> 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.
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.
> 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.
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.
> 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
> "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.
i_do_not_care_for_javascript-semicolon-insertion.jpg
@p @w0rm @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.