So, the two scripting names have a distinct place depending on the application.
That said, which one is considered more secure? And how is "security" for these defined (# of CVE's, handling of crypto or memory, other, etc)?

Ruby, Python, PHP, Perl, blah blah blah, these are simply "scripted programming languages." None of them, if properly configured, are either more or less "secure." Security is a process.

3 members found this post helpful.

Expanding on the process of security, it is generally defined as an ongoing process with the joint goal of providing confidentiality, integrity, and availability in a particular context and with a particular pool of threats in mind.

There is, however, a lot of snake oil out there and plenty of fraudsters willing and, unfortunately very able, to sell it as an after-market add-on or a box to tick on a form.

What is your reason for asking?

1 members found this post helpful.

Both are "considered" equally secure.

PHP actually might be an exception because there used to be a lot of beginner tutorials that encouraged unsafe coding.

Yes, it might be an exception there as it can be observed that PHP is still quite bad in and of itself even after all these years.

"PyTorch dependency poisoned with malicious code"... https://www.theregister.com/2023/01/...ndency_attack/

From the article:

The dependency confusion attack included uploading a copy of torchtriton – a legitimate dependency – that was laced with malware to PyPI, an online repository of packages for Python developers. The compromised torchtriton package came with the same name as the one PyTorch maintainers ship on the PyTorch nightly package index.

"Since the PyPI index takes precedence, this malicious package was being installed instead of the version from our official repository," they wrote. "This design enables somebody to register a package by the same name as one that exists in a third party index, and pip will install their version by default. This malicious package has the same name torchtriton but added in code that uploads sensitive data from the machine."

The sensitive data includes nameservers, hostnames, the current username and working directory name. In addition, it accessed a range of files, including /etc/hosts, /etc/passwd/, the first 1,000 files in $HOME/*, $HOME/.gitconfig, and $HOME/.ssh/.

PyPI and other open source code repositories have become a target in supply chain attacks. A malicious package on PyPI was found last month masquerading as a legitimate SDK from SentinelOne and Phylum in November identified a campaign distributing the W4SP malware via PyPI packages.

In which way does this discredit any language in particular? Will we quote a dozen articles on a few more programming issues in a hundred more languages?

One of the inevitable vulnerabilities of the "open source" software distribution process is, indeed, that someone could post a malicious software update to a public repository. The current system is based on trust that no one is a "bad actor," and I really don't perceive any practical alternative to that assumption due to the sheer number of updates which occur every day. Fortunately, the system that is now in place also allows the malice to be very quickly identified and reversed.

Also: typically, repositories which allow modification require one to use [git] pull requests, which at least in principle allows the proposed update to be reviewed. But the exigencies of "daily update volume" don't always allow this to occur. (Assuming also that the "reviewer" was technically qualified to spot it, and that (s)he was "looking for trouble.")

Hindsight is always 20/20. You always "know" that the vase could have fallen and hit the floor and smashed when the cat knocks it off and it actually does.

However, all of this is not specific to any programming language nor software tool.

In fact, there is an international "white hat" consortium that is dedicated to the cataloging and immediate public distribution of all "software vulnerabilities" that are found, as well as their solutions. There is no "security by obscurity." Exactly the opposite.

Why "discredit"?

It's a security issue concerning the use of open source code repositories. And since this thread is about Python and security, thought it would be kinda relevant...

But of course you're right. Securing and trusting repositories is an issue for everyone.

I remember google play store was infected too. It is not open source and strictly checked and still was successfully infected.
From this point of view any repo can be dangerous and it is completely independent from the original question.

On the other hand any tool can be vulnerable (and those vulnerabilities should be reported/fixed). You may try to compare perl/php/python/java/whatever, but you will never know what will be detected tomorrow... And the security does not rely on the tool itself [only], but the code executed.
As it was mentioned in post #2 already.

OFF-TOPIC but I am off... affected.
The only time that one of *my* tools had been reported on the Web as being vulnerable to something, I had fixed the (dumb) programming-error in the hours that followed a notification by mail.

Up to this day, meaning for years, I have not succeeded in getting the report removed fro the page of that friendly “vulnerability-testing-service”.

... Not off-topic. I had started programming in Ruby, the risk was really obvious and the fix too easy. Handling security risks, their detection and remedy require a permanent effort. It is too easy to just state the obvious, then wait for useful comments. Chances are, there will not be any, as entertaining as it may get.

1 members found this post helpful.

It's a simple fact that, in everything we do as computer programmers, we must rely on "mountains of code that we did not write." Not only must we rely on the internal implementation of a compiler or interpreter, but we use public packages of contributed software which in turn rely on still more.

A "very simple web site" that I recently deployed using Python/Django wound up using eighty contributed packages ... most of them being prerequisites and corequisites of the dozen-or-so that I had explicitly selected. But, hey, I'm not going to personally undertake to write "a forum system" from scratch, nor a "user accounts & permissions structure," nor "map displays" nor "WYSIWYG editing," nor anything else. "Do not do a thing already done."

Periodically, updates are sent out for all of these. I dutifully incorporate the patches and then re-test and re-deploy the site. All is well.

And stop evolution NOW !!.
I'd say: Know what you are doing and keep doubting your capacities to conclude. From this point on, your prospects are good.

Both Ruby and Python are highly secure languages, although the areas in which they are secure may differ. In terms of CVEs (Common Vulnerabilities and Exposures), Ruby has less than Python due to its smaller community size. However, when it comes to memory and cryptography, Python is considered more secure due to its built-in support for strong encryption and secure memory management. When it comes to other security considerations such as authentication, both languages offer robust support.