Security updates, need to recompile?

  1. From my understanding somewhat critical security updates are released for Python every few months. Does this mean if a software company or even me who have written some simpler programs using Python need to recompile every few months using the latest Python version available to keep the application secure?

  2. Is it a security concern to have an old Python-version installed on your computer by itself in any way or the code that is produced by or run with it?

  3. It seems like C++ for example releases updates regularly every three years, and most major software companies lag a version or two behind the latest release to ensure they don’t encounter any possible bugs or flaws that might have been introduced. How come they only release updates every three years as opposed to Python which is updated every three months? Wouldn’t this make C++ very unsecure since it takes multiple years before flaws in the language are fixed?

  1. From my understanding somewhat critical security updates are
    released for Python every few months. Does this mean if a software
    company or even me who have written some simpler programs using
    Python need to recompile every few months using the latest Python
    version available to keep the application secure?

Python is an interpreted language which typically gets “just in
time” compiled at invocation. That compiled version does get written
to disk and serves as a cache, but is invalidated and replaced if
your interpreter is updated. If you have any long-running Python
processes and you upgrade your interpreter, you should restart those
processes so they get recompiled with whatever fixes you installed.
There is typically no separate “compilation” step needed by the user
of a Python-based application, it all happens automatically when you
start it up. Here I assume you’re referring to CPython though, as
there are rather a few different Python interpreters and the
situation there differs a bit between them.

  1. Is it a security concern to have an old Python-version
    installed on your computer by itself in any way or the code that
    is produced by or run with it?

If a tree falls in the forest and nobody’s standing under it, does
anyone get hurt? Generally having “vulnerable” software installed on
your system but never invoked poses no threat. If, however, you’ve
granted that software some special permissions and someone who has
limited access to it uses that to gain more control over your
system, then sure that could be a problem. The devil is in the
details, as usual.

  1. It seems like C++ for example releases updates regularly every
    three years, and most major software companies lag a version or
    two behind the latest release to ensure they don’t encounter any
    possible bugs or flaws that might have been introduced. How come
    they only release updates every three years as opposed to Python
    which is updated every three months? Wouldn’t this make C++ very
    unsecure since it takes multiple years before flaws in the
    language are fixed?

Again, it seems like you’re confusing the language with the
compiler. Just like there’s no single Python interpreter, there’s no
single C++ compiler. Python and C++ are languages, not specific
pieces of software. Yes the languages themselves do get updates from
time to time, but generally not to address specific bugs or security
vulnerabilities. New versions of those languages are created in
order to be able to differentiate new feature-sets from old ones, to
mark certain features as deprecated, to introduce improved
behaviors, and so on.

Python interpreters and C++ compilers get updates far, far more
frequently than just when the language itself is updated. It’s
updates to the interpreters and compilers (and standard libraries,
and such) where security issues are generally fixed. Take the GNU
C/C++ compiler GCC for example… its averaged 5 releases a year
over the past three years:

https://gcc.gnu.org/releases.html

The GNU C standard library, glibc, has similarly had multiple
releases a year in recent history. CPython, unlike many compilers,
includes its standard library in the interpreter releases
(“batteries included”) so it logically follows that the combination
would merit even more frequent releases, roughly 20 just in the past
year alone:

Thank you for your detailed answer! I think I might have gotten a better understanding - but I’m probably still a bit lost I’m sure.

I wrote a couple of shorter files using the Python-language, automating some stuff and tested it with the “CPython interpreter”, which is the one downloaded from Download Python | Python.org right? Does this mean CPython 3.10 = Python 3.10 - if so, is the interpreter what defines how the language should be written to comply with the latest standards to it?

Once my code worked without any errors and did the things I wanted it to, I used “pip” to install “pyinstaller” which is a compiler if I understand it correctly since it created an executable file? This also allowed me to run it on another computer that did not have any Python interpreter installed. So if I compiled with pyinstaller v3 (I don’t remember which version but lets say 3 for the sake of simplicity), would this executable be considered an unsecure file to run if there have been security updates in the new pyinstaller v4? The CPython-version installed at the time when the compilation ran with pyinstaller should have no correlation to it? If it should be recompiled, I assume it would be the same case for C++ applications then? So that software companies who have compiled code using GCC v10 needs to recompile it using the latest GCC v11 and send out an update for their application?

Sorry for the many and maybe confusing questions! :slight_smile:

[…]

I wrote a couple of shorter files using the Python-language,
automating some stuff and tested it with the “CPython
interpreter”, which is the one downloaded from
Download Python | Python.org right? Does this mean CPython
3.10 = Python 3.10 - if so, is the interpreter what defines how
the language should be written to comply with the latest standards
to it?

Pretty much, yes. CPython 3.10.0 is currently the reference
implementation of an interpreter and standard library for version
3.10 of the Python programming language. There are however other
implementations like PyPy, Jython, IronPython… they have varying
levels of feature parity with CPython and usually tend to lag behind
the current language version. But just because the language version
is lower, that doesn’t mean it’s “insecure” or “buggy,” it’s just an
earlier standard, and helps identify things like differences in
syntax or when new features came into use.

Once my code worked without any errors and did the things I wanted
it to, I used “pip” to install “pyinstaller” which is a compiler
if I understand it correctly since it created an executable file?
This also allowed me to run it on another computer that did not
have any Python interpreter installed. So if I compiled with
pyinstaller v3 (I don’t remember which version but lets say 3 for
the sake of simplicity), would this executable be considered an
unsecure file to run if there have been security updates in the
new pyinstaller v4? The CPython-version installed at the time when
the compilation ran with pyinstaller should have no correlation to
it?

I’m not familiar with pyinstaller, but its description implies that
it does bundle your currently installed Python interpreter and
standard library, plus lots of other software from your system
needed to run the application, into an aggregate for redistribution.
As a result, yes technically any vulnerabilities or other bugs
present in those various components are in that case going to be
present in the aggregate you’re distributing, so you should probably
rebuild and distribute a new aggregate any time those components are
updated unless you take the time to check the release notes for them
and confirm that’s unnecessary.

The risks associated with consuming software bundled in such a
fashion would far outweigh the benefits for me, but perhaps for many
it’s not a serious concern (or maybe they simply haven’t thought
about the implications).

If it should be recompiled, I assume it would be the same case
for C++ applications then? So that software companies who have
compiled code using GCC v10 needs to recompile it using the latest
GCC v11 and send out an update for their application?
[…]

More like if it was compiled with GCC 10.3.0 and the GCC maintainers
announced that there was a bug affecting that version which resulted
in security vulnerabilities in compiled bytecode, then you might
want to recompile and distribute a new version of your application
with GCC 10.3.1 which has that fix (disclaimer: I don’t know there’s
any such bug in GCC 10.3.0, there almost certainly isn’t, this is
purely a made-up example).

In reality, it’s fairly rare for there to be a bug in a compiler or
interpreter which results in widespread vulnerabilities in
applications built or run with it. That does occasionally happen,
but usually its impact will be limited to use of certain features or
constructs, and so you’ll want to pay close attention to advisories
to determine if you really do need to rebuild something (though if
in doubt, better safe than sorry). More often you’ll be rebuilding
because some third party library you’re relying on has a
vulnerability and you’re concerned it might be exposed through your
application.

Also not every release of software, whether it’s a compiler,
interpreter, shared library, or whatever, necessarily includes fixes
for security vulnerabilities. Often they’re just fixes for garden
variety bugs, and quite often for bugs which you’re unlikely to
encounter in day to day use. Some may not even “fix” anything in the
traditional sense, and might simply add new features (or even new
bugs!). It’s perfectly fine not to update things, as long as you
take care to confirm that skipping some particular update is safe
for your situation. But if you don’t (or can’t) perform that
evaluation, then just updating and rebuilding things frequently is
probably your safest alternative.