Another reason not to use python?

The chance that one single library is bad is quite low. However once a solution drags in loads of cruft, this chance raises considerably.
And the more layers of cruft you have, the harder it is to understand what is actually needed and what is either optional or just plain pointless. Lots of lazy programmers drag in the kitchen sink just to be sure. It's less work that figuring out what is exactly needed, and using that and no more. The C/C++ linker punishes such behavior severely, and thus it's far less common in those languages.

The harder your dependency tree is to understand, the less likely it is someone will spend the time needed to identify any potential problems in it, and therefore the easier it is to sneak in nefarious code.
 
Can't the same thing happen using perl5 or ruby ?
Yes, but at least:

I. Perl has PerlMonks.
II. Perl has Merlyn.
III. Perl was in the FreeBSD base and is in the OpenBSD base.
IV. Perl didn't give us py:2->3 doomsday.
V. Perl by its nature, is a redditor-unfriendly construct. That's always a plus.
VI. Perl had Obfuscated Perl Contest.

P.S. Perl 7.0 is coming and is going to be a modern Perl 5.32 gem. I have no need to use Python; zero, none whatsoever!
 
Crivens : Sorry, but I'd like to challenge you for some concrete examples here.
They were using javascript for analyzing software and thought of medical uses. But with npm, you never know what you get from one start to the next. So, no validation.
 
Can't the same thing happen using perl5 or ruby ?
I almost forgot the most important things: if you stick to the CPAN, then you can count on the "CPAN testers reports for all the modules on CPAN" at cpantesters.org. There's no guarantee, but that's something!
 
mark_j said:
code designed to exploit your system

That's the point, it's about the intention of the programmer. That example joy = '\x72\x6f\x74\x31\x33' clearly shows the programmer wants to use rot13 and is trying to hide that.
 
This seems especially true with junk like javascript
Hear, hear!.
With python (and any other scripting language that was discussed above) you may have at least some sort of control. Trying to browse the web with JavaScript disabled is /practically/ almost impossible. Not to mention what all trace junk in brings with it.

I didn't like python for many years. Most of the scripts I did are perl ones. But when I came into the CTF (capture the flag) game and started doing pwnables (hacker games) I noticed the perl is just taking my focus away from the problem at hand. Many times python just made things easier with the already available libraries. Depending on the exploit I still use assembler and C (and I love writting exploits in those languages) but I saw the beauty of the python too. Especially when I use the library I would not be able to write myself (SMT solvers, Z3, angr...).

Now with the 3.x python I have the same hate as before. So maybe I start to like it again in 10-15 years? :)

But as with any other software one pulls from the internet -- beware of the risks.
 
Many times python just made things easier with the already available libraries.
Python has relatively few inbuilt libraries. Unlike Java it is not a "batteries included" platform. You need to source them from the PIP repo. This in itself isn't really a problem. C and C++ are similar.
Depending on the exploit I still use assembler and C (and I love writting exploits in those languages) but I saw the beauty of the python too. Especially when I use the library I would not be able to write myself (SMT solvers, Z3, angr...).
This is where Python becomes a pain. For example, in C, I can grab a library and it is *one* dependency. In python that similar library would drag in recursively 20+ dependencies.

Certainly, use a library. It is incorrect to assume that using a library is wrong. However Python is an example of a "dependency language" where there are more dependencies than actual solution. It does a poor job of minimizing dependencies and lifespan and code correctness suffers.

Ultimately many language fall for this trap and thus never quite managed to surpass C (or even C++). Rust is going to be an unfortunate example of this. I think Java (and thus CSharp.NET) are one of the few examples of non-C languages that have not fallen for this trap. Possibly contributing to Java's comptitiveness with C on (slightly superficial) leader-boards such as TIOBE.
 
kpedersen I didn't say otherwise. Python (as many other scripting languages out there) brings dependency hell with it. One has to pay attention (pip, cpan) what's being installed.

I only shared my view on the python. It helped me speed up many tasks I had at hand and didn't stir my focus away from the actual problem. I never run pip/cpan on a host. Always only in a task-dedicated VM. But then I do store and run malware there too. I did also write few python scripts for gdb to ease my debugging - priceless.

But then I start swearing anytime I open python3 (and still I tend to open python2 when things are not going the way I want to).
 
Yeah, when dependencies begin to recurse, that's when it becomes impossible to verify things completely, and THAT's when malicious elements strike. But man, CTF and pwnables... that stuff is actually over my head. It's interesting to be on the sidelines, observe, take some notes for my own use, be an informed consumer of such 'entertainment' - but joining in on such games would be a bit too much for me. I'd have to do a truckload of practice, and rethink my approach to security from ground up just to show up at the playground. A real-life comparison would be surfing - waves with a 3-4 foot face are OK for me, but stuff beyond that takes more skill than I currently have.
 
astyle: You just have to start. Everybody started somewhere. Some people are better than the others, as always. When I first started (pwnable.kr) and was introduced to GOT (in "toddler's bottle" section) I was blown away. Going passed that level was a huge step for me.
Once I was stuck on a level for 7 months. I was going crazy. But persistence was a key. So just start somewhere, use whatever tools you need, break stuff and most importantly have fun.
And of course don't forget there are some crazy good people out there. Jaw dropping, crazy good.
 
With security/safety critical software I would first check if the thing is statically linked. That is not possible in these scripting languages. I would hate to break things like login when some genius updates libc.so with the result of some underhand C contest...
 
Yes, but at least:

I. Perl has PerlMonks.
II. Perl has Merlyn.
III. Perl was in the FreeBSD base and is in the OpenBSD base.
IV. Perl didn't give us py:2->3 doomsday.
V. Perl by its nature, is a redditor-unfriendly construct. That's always a plus.
VI. Perl had Obfuscated Perl Contest.

P.S. Perl 7.0 is coming and is going to be a modern Perl 5.32 gem. I have no need to use Python; zero, none whatsoever!
So theoretically someone with enough time and money could change seamonkey from python2...python3 and maybe obtain its re-inclusion into the ports tree?
 
So theoretically someone with enough time and money could change seamonkey from python2...python3 and maybe obtain its re-inclusion into the ports tree?
Good luck with that... we're still trying to do that with KDE. I don't think that money has a place in that conversation, though (unless it's for housing the devs and renting server bandwidth).
 
There was another forum about software packaging which might be related to this discussion.

Apparently, snaps are easy to use (on Linux) but complicated to implement however it might stimulate thinking about something simpler.
 
There was another forum about software packaging which might be related to this discussion.

Apparently, snaps are easy to use (on Linux) but complicated to implement however it might stimulate thinking about something simpler.
PC-BSD (a.k.a. TrueOS, and defunct since 2020) actually tried that with PBI packages....
 
As I said before (I don't remember where) that the only reasonable one that could be "adapted" in a similar way is appimage, because it's basically an image with the deps inside that you run like ./name_of_the_image (pretty clean in my opinion, without directory hell, without fuzz, readable). Flatpak and snap have their own issues (bad ones), I'm happy that FreeBSD doesn't have this kind of contraptions (some linux distributions even makes you required to use, because the developers are lazy to port more applications and they just re-roll ubuntu/debian/arch to another new contraption that will be abandoned in some months/years).
 
Let's try staying on the topic... This thread is about reasons not to use Python/Perl/Rust (Due to the fact that modules for those languages have a propensity to recursively pull in deps from repos, and that is a security risk on several fronts).

One issue that I see with repos is that they all seem to reinvent the wheel. Python has NumPy, Perl has a few Math libs/modules that implement very similar functionality, and the same thing can be probably said for Rust, as well. All 3 languages do provide OpenBLAS API. But if you don't have a repo, just a few project-specific libs that get compiled and installed (like devel/llvm, you have to implement the missing functionality from ground up, rather than pull in something premade from a repo.
 
I think Java (and thus CSharp.NET) are one of the few examples of non-C languages that have not fallen for this trap.
While it's possible to write clean and taut core Java, very few people do, unfortunately. The Java landscape is dominated by monstrosities like Spring, Maven, and Gradle. We wrote a "lightweight" alternative to Spring at work 'cause the latter was such a pig it was actually causing noticeable problems on modern hardware. Even our alternative drags in hundreds of crapware packages. One of the worst I've had the misfortune of looking into is the Hibernate Validator framework. Hundreds of classes most of which are facades, factoryFactories, abstractStrategies, and adapterAdapters. It makes me sad.

I once sent a partner some sample code with the following instructions for compiling it and running it:
Code:
javac SampleCode.java
java -cp . SampleCode
Senior Java Engineer was completely lost. I had to call him and hand-hold him through the process.
 
Senior Java Engineer was completely lost. I had to call him and hand-hold him through the process.
ROFLMAO, seriously??? How did he even get the job if he doesn't know the basic ropes of Java??? 🤣

Worst part is, people in such jobs would not even consider the possibility that somebody lower on the totem pole just might actually be able to follow simple instructions. A Senior Java Engineer would call in an expensive outside consultant instead, with the reasoning that "If I cannot figure that out, it's not reasonable to expect anyone at my shop to be able to do that... I better call outside help, even if it costs a truckload of money".
 
Jose said:
Hundreds of classes ...

Some people make a living of maintaining software like that. They will never run out of work, I suppose. Don't ask why they're using those classes, just because it's available for free mostly. And don't even think about asking for documentation, the last version was generated 5 years ago.
 
very few people do
Yeah that is a good point. With Java you have almost the opposite problem. Rather than hundreds of little ratty dependencies the Java developers favor these *big* systems that are just massive inflexible monstrosities that provide more red tape than anything else (possibly why IBM is still so interested in Java ;))

Senior Java Engineer was completely lost.
Ugh, where I used to work 99% of the developers didn't quite understand what a compiler was and couldn't even make a hello world compile without Microsoft Visual Studio and that stupid "play" button. It often puzzles me how someone with so called passion or skills in a trade can be so oblivious.
 
My biggest complaint about Java is not just the size and complexity of stuff like Maven, Gradle, and the rest. A lot of it is actually installable as separate packages, so you can actually set up a repo for them. My complaint actually revolves around the 'Why' of these things. Most of the time, it's some kind of pile-of-crap verification (against initial programmer stupidity) and performance metrics. Sure, it's nice to be able to have an API that works with huge databases like Oracle or NoSQL or with huge zettabyte-sized disks - but come on, no need to get that frustratingly complicated. And then you wonder why Senior Java Engineers are so lost and confused.
 
kpedersen said:
where I used to work 99% of the developers didn't quite understand what a compiler was

You probably coded with an editor and used the command line to compile, link and run. And yes, I am that old too. With modern IDE's however there is no need for all that. No wonder people who grew up with IDE's don't know the difference between javac and java. Many have no idea of what is going on underneath that IDE.
 
You probably coded with an editor and used the command line to compile, link and run. And yes, I am that old too. With modern IDE's however there is no need for all that. No wonder people who grew up with IDE's don't know the difference between javac and java. Many have no idea of what is going on underneath that IDE.
I know about both, and I still get lost in Visual Studio. When I had to use it for a class in college, I had to ask for some coaching on how to use it - the compile/make button was not the most obvious thing. In Android Studio (which wants Gradle, BTW), you can just push a button and have it spit out an APK that you can straight install on your phone. But VS - just setting up for coding a simple helloworld took a long time for me. Setting up to code the exact same thing in command line - 15 minutes of typing, and I have a runnable a.out!
 
Back
Top