Is a port based on interpreted languages lazy programming?

K

kjpetrie

My reason for wondering this is that once again a Python vulnerability has appeared and once again (I presume) various port developers will be struggling (or being urged to struggle) with checking their applications against the required upgrade before that upgrade can be released, resulting in a long wait before servers get upgraded to cover the vulnerability. In the meantime, presumably, some machines remain at risk.

I realise porters are not necessarily the developers of the software they package, but it does raise the question of whether dependency on a language version is really good programming practice and whether we should encourage compiled alternatives wherever possible.

What do others think?
 
kjpetrie said:
but it does raise the question of whether dependency on a language version is really good programming practice and whether we should encourage compiled alternatives wherever possible.
Click to expand...
Why would this be any different from a vulnerability in a library that gets used in a C/C++ application? The application still needs to be checked if it can handle the new version of that library and may need to be recompiled as a result of that change.
 
  • Like
Reactions: mer
When it comes to vulnerabilities. Language does not matter.
When it comes to build tools, going from python2 to python3 has shown to be problematic.
 
Good point, Sir D! In theory there shouldn't be any difference, unless it's just that C's been around a lot longer, although languages like Python are really calling compiled code in the background, so just add another layer of potential bugs. I'm aware problems with Python, in particular, seem to occur rather often and take many weeks to check through before the new version can be deployed, leaving systems potentially vulnerable. At least, that's what happened last time a few months ago. Maybe it's too new and has been adopted too widely too quickly.

PHP is another one where upgrades happen frequently, but they come through more quickly, probably because PHP isn't normally used for general programming so it is users' local scripts rather than ports which depend on it.

Short of using a Flatpak-like structure, which would bring massive problems of its own, I suppose we're stuck with the problem, but I do wish there weren't so many things which depend on Python because it seems to have frequent critical bugs and has so many dependants it takes too long to maintain the port. (Too long for my liking, that is.) I only use it for one thing, which is to maintain my LetsEncrypt certificate, but for that I have about a dozen Python-based ports installed! I don't know exactly what security/py-certbot does, but it could probably be done quite easily by a simple program written in another language if I did.
 
Using flatpack is not a good idea iMHO. It only enables bad installations to survive a lot longer without even being detected. That is absolutely not what you want, or is if? Updating a library should update the functionality it provides in the applications. If it does not, the app developers need to look for other libraries, or raise some heat on the library developers for breaking their stuff.
 
Crivens said:
Using flatpack is not a good idea iMHO. It only enables bad installations to survive a lot longer without even being detected.
Click to expand...
It's similar to various applications and products we use at $DAYJOB. Many of those have all sorts of libraries and external scripts, even executables (perl, java, python, etc), embedded in the application itself. That log4j debacle proved how prolific it is and how horrendous it is to fix it.
 
You have a bit of a point. But not because of the interpreter. Because of the type system.

If you have a security vulnerability in a library with no compile-time type checking it is more difficult to quickly verify that the updated library actually leaves all the other parts of the ecosystem working. In a language with compile-time type checking a big chunk of the "testing" has happened by the time that the thing successfully compiles.

Obviously the maintainers of ports and packages profit from this, resulting in earlier updates to the ecosystem integration.
 
I've been writing some stuff in Go recently, modules are imported at whatever version they were when I started using them.
I have some CI (GitHub in this case) building my code and publishing compiled versions to not only Github for people to download, but to my own homebrew tap and to Arch Linux's AUR automatically.
Two of the "nice" features I've recently enabled on GitHub is Dependabot and CodeQL, both have limited support of languages but Go is supported. Dependabot runs periodically to check what your project depends on and notifies you of updates, while CodeQL scans your code for vulnerabilities.
I have already had two notifications that dependencies I use are outdated, which has allowed me to test the updates and publish code to potential users automatically.

I have no specific tie to GitHub, much of what I've done has been part of some additional learning for myself. But I'm trying to make a couple of points:
  1. Code scanning (variety of tools available) can help to find issues, be that outdated/vulnerable dependencies, or potentially some vulnerabilities in the code you wrote. I don't think this should be relied on 100%, just as an additional tool.
  2. Because of the disconnected/manual approach we have for most Ports (I think many Python, PHP, Perl library/module ports are automatically managed, and probably others too?), we make it more difficult for external projects to manage their own ports (i.e. it's not simply a step in their existing automations), thus relying on the good will of individuals to maintain, update, and test the Ports where things can fall through the cracks.
    I know that for the Ports I maintain the time between an update from the project and me getting time to update the Port is usually a day or so but has been up to almost three weeks if I've been travelling with work or busy with family.

kjpetrie said:
I only use it for one thing, which is to maintain my LetsEncrypt certificate, but for that I have about a dozen Python-based ports installed! I don't know exactly what security/py-certbot does, but it could probably be done quite easily by a simple program written in another language if I did.
Click to expand...
security/acme.sh is written in shell, I use it to manage multiple Let's Encrypt certificates on my machines.
 
This piqued my interest, so here's my 2 cents:

There's Lazy Evaluation and specific case of it, Lazy Initialization. Python and C/C++ offer those features.

When it comes to porting software to FreeBSD, you gotta consider flexibility vs security, true. There are snippets of Python code that can be run with any version of Python - but python27 has been EOL-ed, so it's actually good practice to specify dependencies to reflect that, and require python to be 3.7 or higher (newer). As cracauer@ pointed out in post #7, there are security benefits, too.

When it comes to compiled stuff, the dependency hell bites even worse.
 
I don't think the problem with Python is that it's interpreted, I think the problem with Python is the steering committee is more worried about keeping up with the cool kids than anything else.

You now have to deal with breakage introduced in dot-versions of Python. Stuff that worked on 3.8 won't work on 3.10. Given the advanced stage of featuritis in that project, I would not be surprised if critical vulnerabilities become as common as they are in say, Openssl.

I avoid Python and Python projects now for that reason. Maybe updating code to work with the latest and greatest gives you great bullet points for your corporate status report, but it's frankly a pain for my amateur projects. I don't enjoy that kind of treadmill.
 
Well, I wasn't recommending Flatpak. Just reflecting on C library-dependency. The libraries bundled with applications caused a lot of segfaults and even kernel crashes back in the 90s when it was common practice with third-party applications in Windows.

The problem with Python may well be lack of maturity or stability reducing backward compatibility. An upgrade to glibc might break applications but usually doesn't, so the number needing recompilation is usually small.

Thanks for the tip on security/acme.sh. I'll take a look at that as it'd be great to get rid of the python stuff.
 
You must log in or register to reply here.
Back
Top