Absolutely. I wrote such a script as a proof-of-concept and was yelled at because it was considered a 'security risk' for me to use company tools to write code (as a not-hired-for-programming employee) even though I already had access to literally all the company's data and their security practices were such that exfiltrating their data without being caught would have been trivial even if I never placed any code on their systems. The place was extremely dysfunctional and there were significant trust issues that were completely irrational and inconsistent. So a script that did this job was largely out of the question.
It's not about deliberately hurting a company; if it's possible to make such a script, it will be made. Period.
The question is: do you want the script publicly available, or in the hands of your adversaries without anyone knowing? There's a third alternative: fix the problem.
There are a hundred reasons to use this script and your responses merely lack imagination:
* Ancient script written by people at the company no longer here that may encode a bunch of assumptions and lots of dead code
* Personal script that is not to the level of full production
* Run untrusted script in a constrained environment to see at what stage it does something ugly - this will bypass obfuscation based on adding lots of dead code
That's like 3 things I already thought of while writing this comment. In like the 90 s it took me to compose this. These ostentatiously dramatic comments of yours aren't that interesting. Hopefully coming generations of engineers will look at your comments and be like "I wish I wasn't like that".
Sure - I'll be happy to show you the scores of scripts I have written to do every tasks like switch pipewire audio sinks, wrapper to youtube-dl, generate/copy rsa token, convert/combine images to pdf etc that were written in the sliver of time afforded to me after I'm done family and kids. Those scripts in no way represent the code I get paid to write in my job but if you find that to be an an issue, then you have found the flaw in your method.
Oh, absolutely. Where something can be scripted, script it. Why? Because scripting is a process development. You write something, validate it and then remove the human error element.
For things that you can't script, you write abstracted processes that force the executor to write down the things that could cause Bad Things to happen, and use that writing down stage to verify that it's not going to cause a Bad Thing. That forces people to pause and consider what they're doing, which is 80% of the effort towards preventing these issues.
eg: Forcing YP to write down which database they were scorching would've triggered an 'oh fuck' moment. Having a process that dodged naming databases as 'db1' and 'db2' would've prevented it. etc. etc. etc.
You just reminded me -- I once wrote a script that decoded and then eval'd a hidden command encoded within the whitespace of the script file itself. My goal was to create an entirely benign looking script that would hold up to visual scrutiny, but still be possibly malicious - in the final variant, it downloaded an additional remote script. Not that I ever used it for anything, but it did temper my natural trust in cursory inspection of benign-seeming open source code.
Is it particularly worse than downloading and blindly running the code in separate steps? I don't think the majority of users have ever extensively audited the software they run, so it's not exactly a new trend. If you are capable of evaluating this script, you already know how to do it.
The company I work for basically relies on use scripts to make any of our internal tools usable. Its kind of insane and makes on-boarding new employees somewhat difficult when they aren't even looking at the same UI as tenured people.
Honestly it sounds like it wasn't a tool that is needed often, if it was you or someone else would have already written it. Or you don't regularly day-to-day program enough in javascript / python to do this quickly. There isn't anything wrong with that, as you mentioned, you have entry level security engineers that typically handle those tasks. Creating a tool goes fast when you know exactly what you want it to do and don't have to explain to another person all the requirements and pitfalls to avoid based on experience you might have in writing quick scripts. I don't know if this really changes anything.
eh it's fine. sure, technically speaking you're giving your machine over to whoever wrote that script. they could do anything! but actually, the script is usually useful and safe. Like this one.
Yes, that would be a good idea. But if you ever run scripts you didn’t write, there’s the potential people didn’t do this, and you have the potential for hard to discover bugs. The language should be designed such that bugs are difficult to encounter, this is an instance where it wasn’t.
Yes. Not because you're doing anything wrong yourself, but because the cost to the user of allowing third party scripts is too high to tolerate nowadays.
Initially it was a combination of just for the fun of it (it's a small script, as OP described). Secondarily there was the feeling of "everyone is going to go work at [major competitor]" and I was curious whether I could collect the data to show it. (I never ended up looking into this, but maybe HR did.)
As a dumb script it was not designed to be especially flexible. One thing I remember needing to fix was that by its nature it was archiving old data and preserving it, which meant that it was accidentally deadnaming trans people. My recollection is this was a small code fix, but an interesting lesson in social consequences of oblivious software.
hahahah. A friend of mine has a problem with a contractor at his workplace that tries to PR in shell scripts written with Copilot. My friend spends an hour to explain why a script generated in 5 minutes is horrifically awful and will likely take down the company. He's legitimately angry about it.
reply