Ubuntu vs Debian stable (security patches)

Hi all, :wave:

Lately I stumbled across an article which made me ponder about the aspect of security with regards to ubuntu vs debian.

Currently I´m using Debian Buster (stable) in a VM, so in this scenario might not be of really great relevance for me but for those using Debian stable as their daily driver it´s certainly something else. :thinking:

The article I´m referring to can be found here:
Sicherheitsupdates bei Debian - Wie viel Verzögerung ist normal? • [Mer]Curius .

Alas it´s written in German, so I´ll try to summarize it (to a certain degree) here.

rough translation:

During the last few days, a gap in Samba has hit the newspapers.
This is a replica of Windows network services that almost every Linux distribution has preinstalled.
The problem is in the vfs_fruit module.
Apple users are probably familiar with this as a prerequisite for storing Time Machine backups on a Linux server.

The vulnerability is classified as critical and registered under CVE-2021-44142.

All distributions I know of quickly rolled out patches. Ubuntu, SUSE, Red Hat - the patches were usually already on my system before I read the corresponding message. Only with Debian nothing has happened for days - again.

Chromium is also lagging behind once more and when skimming over the current security issues, I immediately noticed a few packages for which I have had updates on my openSUSE Leap systems for days (e.g. Expat), although to be fair they are not particularly critical.

The same with MariaDB […]

Two points just surprise me:

1.) How did Debian get its reputation as a secure operating system? They offer average at best when looking at the speed of response to issues.

2.) Why doesn’t anyone in the Debian community notice this at all? I haven’t found a single serious discussion about it.

For example, one could discuss how high the price one is willing to pay can be to keep versions absolutely stable.

Which packages do you want to sacrifice for this, how much delay in security updates do you find acceptable for this goal?

Do you prioritize things like reproducible builds over security? Those would be interesting points for a policy.

(author: [Mer]Curius )

My thoughts about this article were:

Does anyone of you use Debian stable :question:

And if so, what experience with Debian stable do you have as far as security updates are concerned :question:
I´m deliberately not speaking of testing or Sid (unstable). My question just refers to stable.

I know its primary goal is (as the name suggests) stability of packages. Absolutely not bleeding edge.
This is exactly what I would be looking for in Debian stable. :blush:
But timely updates of security patches would still be vital methinks. :expressionless:

Thanks for your opinions in advance.
Many greetings
Rosika :slightly_smiling_face:


At the time of writing CVE-2021-44142 still lists “CVE-2021-44142” as vulnerable.

In contrast to that I received security patches on my Lubuntu system as early as Feb 1:

2022-02-01 14:37:56 status installed samba-libs:amd64 2:4.13.17~dfsg-0ubuntu0.21.04.1

Yes, when I’m forced to, like in WSL2, for example. However, if I can, I usually use Testing.

Well, there is a security repository and strong vulnerabilities should be fixed ASAP. So, I assumed it would be the case for Debian stable, just like for other distributions.

I ran apt update and looked up the Samba version available from the official repositories:

policy samba
  Installed: (none)
  Candidate: 2:4.13.13+dfsg-1~deb11u2
  Version table:
     2:4.13.13+dfsg-1~deb11u2 500
        500 http://deb.debian.org/debian bullseye/main amd64 Packages
        500 http://security.debian.org/debian-security bullseye-security/main amd64 Packages

So, I looked up, what version of Samba is vulnerable to CVE-2021-44142:

2022-02-07 14_53_05-Main _Samba - Security Updates and Information — Mozilla Firefox

The version I would be able to install in Debian Bullseye (current stable):


Which is a Debian derivative of the Samba version:


Which, according to the security patch version list on Samba’s homepage, is vulnerable.

I couldn’t believe it. I assumed it might perhaps be manually patched by Debian or whatever. So I looked up what Debian is saying about that package:


Indeed, it’s still vulnerable.

In this case, you would still install an obsolete & vulnerable version of Samba in Debian stable.

That really surprised me. I expected it to be fixed since knowledge about the vulnerability was published.

1 Like

Hi @Akito, :wave:

thank you very much for your opinion and providing your insights into the matter.
I appreciate it a lot. :hearts:

Well, I was thinking about testing, too. But I´m a bit of a stable junkie, therefore my asking around…

That was my assumption, too. Like you, I was pretty astonished to learn about how things still stand at the moment.

Oh, and thanks for the links as well. :+1:

On my Debian stable (buster) VM machine it´s the same case:

buster (security) 2:4.9.5+dfsg-5+deb10u2 vulnerable

This version was installed on 2021-06-16 and received an update on 2021-12-01 and then … nothing :slightly_frowning_face: :

rosika2@debian ~> zgrep installed /var/log/dpkg.log.*.gz | grep samba
/var/log/dpkg.log.2.gz:2021-12-01 16:06:58 status half-installed samba-libs:amd64 2:4.9.5+dfsg-5+deb10u1
/var/log/dpkg.log.2.gz:2021-12-01 16:07:03 status installed samba-libs:amd64 2:4.9.5+dfsg-5+deb10u2
/var/log/dpkg.log.8.gz:2021-06-16 16:46:28 status half-installed samba-libs:amd64 2:4.9.5+dfsg-5+deb10u1
/var/log/dpkg.log.8.gz:2021-06-16 16:55:50 status installed samba-libs:amd64 2:4.9.5+dfsg-5+deb10u1

The article I was referring to surprised me as well, especially in view of the fact that I was contemplating using Debian stable as a daily driver in the future…

To be clear: I´m perfectly satisfied with Lubuntu. The only thing that slightly bothers me is having to do a fresh-/clean-install every two years… :thinking:

But as things stand now I´ll definitively stay on Lubuntu. :slightly_smiling_face:

Thanks again @Akito for your help.

Many greetings from Rosika :slightly_smiling_face:

This could be improved by using regular expressions:

zgrep -E 'installed.*samba' /var/log/dpkg.log.*.gz

Hi @Akito again, :wave:

thank you so much for the hint (and the link, of course).

I´ve been using the “-E” parameter on occasions as well like in
watch "sensors | grep -E 'Core|fan2'" .

So I immediately tried your suggestion but it seems to yield the same result :thinking: :

… the only difference seems to be that the search word isn´t coloured by default… :thinking:

Still, thanks a lot. It´s greatly appreciated.

Many greetings.
Rosika :slightly_smiling_face:

Yes. It’s just a way to do more advanced queries, without having to chain a lot of grep instances, just making the command more confusing. The advanced queries are more powerful and concise. You can grep text through regular expressions in a variety of advanced ways, saving you time and effort.
For example, if you only search for a word that could be named in different ways, but only if it is in the same line as another word, or something like that. Chaining grep instances to do this would be quite tiresome compared to creating a single regular expression to achieve the same.

1 Like

Hello again, :wave:

I see. Thanks for the clarification.
Yes, regular expressions seem to provide a lot of comfort and ease when using serach-words.

I was dealing with the topic as well but it´s been a while. :blush:
So brushing up on the subject with your help is really appreciated. :hearts:


Getting coloured output (of the search-word) can be achieved (according to the grep man-pages) by making use of the color/colour-parameter. I tried it and it works:

zgrep -E --colour=always 'installed.*samba' /var/log/dpkg.log.*.gz

Thanks again and many greetings.
Rosika :slightly_smiling_face:

1 Like