Out of date software in the latest Qubes?

General Discussion
1

To start things off, I read the docs and have tried to find my answer to this, but can’t seem to find a answer, (to this very simple question)

Basically, a lot of the software - even - the cryptsetup (that one uses when installing Qubes) is, massively out of date? And, this raised quite a bunch of uh, “alarm” clocks in my opinion, crypto is extremely-vital in any security centric app/OS; (and I do not mean, “Use the latest version” I am sure (I hope!) there is a reason for this, but I as said, cannot find it - I have searched, checked the Docs, FAQ’s, etc.

to demonstrate a proof of what I mean,
I installed Qubes (the latest-stable version) (verified it first, of course!) today, and - being a sort-of “advanced” user, I always check the parameters and versions of the majority of apps I install & will use.

When I came to the Qubes Crypt-Partitioning/step (in the installation) I noticed - the cryptsetup was massively out of date;
sample from my terminal:

[someuser@dom0 ~]$ cryptsetup --version
cryptsetup 1.7.5

while checking the gitlab page (and, various other pages) it seems 2.4.2 is the latest stable version;

Now, there is (hopefully) a explanation/reason for why this might be the case;
and therefore this might seem I have not at all read the docs,
But - I have; totally checked:

  • Docs
  • Faq
  • Forum
  • Github()

I have searched all of those, in issues/pages after words like “outdated software” or “dated” (and used abbreviations and tried many different things)

but it seems - weirdly enough - I cannot seem to find anyone that has asked this before ???
I can’t find it in any page either;

Is this just me or ?

I hope that I am totally wrong here, please -if that is the case, just explain/or post a link to a article that explains this;
I think, for compatibility reasons, this might be the case, and so on - not easy to implement , but this should then
at least, be stated somewhere

Note; this is not only with cryptsetup. It’s many other apps that is weirdly out of date

EDIT:
**Additional comments:

  • it’s probably very possible (and, perhaps also - easy?) to update the outdated-software - after the install - right? Well, yes - but wouldn’t it be better, to have - the latest qubes - with the latest (say - for the context of this example) the x-top-ranked (as most important) software also up to date? (When there is updates of course, ) and I know, as said above, this does NOT mean every new update,that fixes 1 small thing, I mean, “major” things, such as major releases, as in fixing vital bugs. **

It’s also good to mention, a OS can be secure, but cannot (ever) be a 100% secure. we can make it as close to it as possible, this, by following common guidelines, applying patches as well as the classic “keeping up to date”. (this, applies to every OS, and any App, and so on

thanks;

and sorry if this is a but hard to understand what I have written, please reply if something is unclear!

2
1 Like
3

thanks; I kind of understand (a little) why the case of outdated software, (from the link you provided) (for, simplified:“security issues” but it does not make any direct sense, since - updating is vital, (even if one program is not connected to the internet, I still - would want to at least, encrypt ,my system with the latest version of vital-software (I.e, crypto software, which - Is well, part of the big*things around Qubes, encryption(of course) verification, etc.

If there is e.g a bug in a old-major crypto software it’ - that wuld just be a nightmare;

I will repeat myself in a slightly different way (just to explain);
I know Qubes protects the user- if one qube is compromised, it cannot(or, the intention I guess is that it is not able to) affect other qubes, which is really good - but the more bugs, the more risk there is (of course) -

just for the context - I am not saying “Qubes! Please use the latest software” that - on it’s own would introduce bugs since, many things doesn’t support the new apps, compatibility issues, and implementation difficulties, I am just - confused why critical software would be outdated; qubes software (as, firefox, terminal, …) can be in some sense, “understanding” why it would be outdated, but things the whole os uses, e.g encryption - that is what confuses me the most.

Thanks, and I hope this is just confusion and - there hopefully is just a simple answer to this.

again, sorry - this is probably a trivial question, but I have not found even any article that asks the same question, which I also find weird.

1 Like
4

Dom0:

Dom0 is isolated from domUs. DomUs can access only a few interfaces, such as Xen, device backends (in the dom0 kernel and in other VMs, such as the NetVM), and Qubes tools (gui-daemon, qrexec-daemon, etc.). These components are security-critical, and we provide updates for all of them (when necessary), regardless of the support status of the base distribution. For this reason, we consider it safe to continue using a given base distribution in dom0 even after it has reached end-of-life (EOL).

If there would be a critical known issue in cryptsetup, the team would have pushed an update. Also with R4.1 which will be release shortly cyrptsetup will be > V2.0.

DomU:

The key is that the software you as a user are supposed to interact with runs inside qubes. These qubes are based on templates. The distribution and version of which you can choose. The default options are Debian (stable), Fedora and Whonix (based on Debian stable). All of them are up-to-date.

There are other distributions you can choose: Arch, Gentoo, Ubuntu, Kali, Parrot and more. There require a bit more knowledge and are not provided as default options, but can be build using the Qubes Builder.

5

From a virtualization security perspective, sure, the version of fedora in Dom0 matters less.

From a system administration perspective, using a more recent version of fedora in Dom0 would make some things better. E.g. for Qubes R4.0 lvm thin-provisioning-tools requires a much more recent release of the lvm2 packages to be usable, and it’s quite helpful for recovery purposes.

The tradeoff is that the Qubes developers want a stable dom0 platform, which is important. My only ask is really to try to sync up the 4.2 release with the most recent release of Fedora at the time 4.2 goes into RC stage. I know, moving targets…

B

1 Like
6

Just to make sure we’re starting with the same set of background assumptions, I’d like to remind everyone that one of the first things you should do after installing any new OS from an ISO is update it:

https://www.qubes-os.org/doc/installation-guide/#next-steps

(This is even true for mainstream OSes like Windows. It’s not Qubes-specific.)

It doesn’t necessarily follow from the fact that a newer release of a given piece of software is available that all older releases are unsafe to use. For example, Debian 11 is out now, but Debian 10 is still supported and safe to use. You should check to see which releases are supported. Some projects support only the latest version, while others support multiple versions.

Also, depending on how the software is used and what kind of environment it’s in (e.g., isolated in dom0), it may be safe to use an older version, as long as that older version doesn’t have any vulnerabilities that can be exploited given that software’s position in the Qubes architecture. You can rest assured that the Qubes developers take these considerations very seriously and do not run old software haphazardly in supported Qubes OS releases.

1 Like