Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel.testing > #1200 > unrolled thread

Current bullseye security and stability

Back to article view | Back to linux.debian.devel.testing

Contents

  Current bullseye security and stability "Jorge P. de Morais Neto" <jorge+list@disroot.org> - 2021-01-14 14:50 +0100
    Re: Current bullseye security and stability ldavila@syt.net - 2021-01-14 15:30 +0100
      Re: Current bullseye security and stability MichaIng <micha@dietpi.com> - 2021-01-14 16:10 +0100
        Re: Current bullseye security and stability Jorge P. de Morais Neto <jorge+list@disroot.org> - 2021-01-16 17:20 +0100
          Re: Current bullseye security and stability MichaIng <micha@dietpi.com> - 2021-01-16 21:20 +0100
            Re: Current bullseye security and stability Jorge P. de Morais Neto <jorge+list@disroot.org> - 2021-01-17 00:00 +0100

#1200 — Current bullseye security and stability

Hi.

I love having fresh packages.  To work around the oldness of Debian
stable, I have installed dozens of packages from buster-backports; 81
packages from Guix; 12 Flatpak applications (excluding runtimes); 20
pip3 packages (excluding their dependencies); and ≃10 npm packages
(excluding their many dozens of dependencies).

The complementary package managers do not quench my thirst for
freshness, so I would like to upgrade Debian to bullseye.  Now that the
freeze has started, is it a good time to upgrade my personal notebook?
Should bullseye, by now, be relatively stable and, more importantly,
secure enough?

I do not run any server; it is a personal laptop behind NAT---at least
for IPv4 (I don't know the details of IPv6).  I am subscribed to
`debian-security' and am willing to manually pull specific packages from
/unstable/ for security reasons.  That is, when a /testing/ package in
my installation has a serious security vulnerability, I am willing to
upgrade it to the security-fixed version from /unstable/ instead of
waiting for it to propagate to testing.

In this context, is bullseye secure enough?

Regards

-- 
- <https://jorgemorais.gitlab.io/justice-for-rms/>
- If an email of mine arrives at your spam box, please notify me.
- Please adopt free/libre formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
- Free/libre software for Replicant, LineageOS and Android: https://f-droid.org
- [[https://www.gnu.org/philosophy/free-sw.html][What is free software?]]

[toc] | [next] | [standalone]

#1201

[Multipart message — attachments visible in raw view] — view raw

Hey!

I have a couple of notebooks, a VM and like ~30 servers running debian testing 
for 2 years now.
My experience says you can count on stability.
I have not detected any security issues yet... I'm also subscribed to 
debian-security, most of the announcements on the list are already solved on by 
the packages on bullseye.

regards
lucas

El 14/1/2021 a las 10:44, Jorge P. de Morais Neto escribió:
> Hi.
> 
> I love having fresh packages.  To work around the oldness of Debian
> stable, I have installed dozens of packages from buster-backports; 81
> packages from Guix; 12 Flatpak applications (excluding runtimes); 20
> pip3 packages (excluding their dependencies); and ≃10 npm packages
> (excluding their many dozens of dependencies).
> 
> The complementary package managers do not quench my thirst for
> freshness, so I would like to upgrade Debian to bullseye.  Now that the
> freeze has started, is it a good time to upgrade my personal notebook?
> Should bullseye, by now, be relatively stable and, more importantly,
> secure enough?
> 
> I do not run any server; it is a personal laptop behind NAT---at least
> for IPv4 (I don't know the details of IPv6).  I am subscribed to
> `debian-security' and am willing to manually pull specific packages from
> /unstable/ for security reasons.  That is, when a /testing/ package in
> my installation has a serious security vulnerability, I am willing to
> upgrade it to the security-fixed version from /unstable/ instead of
> waiting for it to propagate to testing.
> 
> In this context, is bullseye secure enough?
> 
> Regards
> 

[toc] | [prev] | [next] | [standalone]

#1202

Hi,

I can only agree, running some Bullseye systems as well since Buster was 
released, not facing any relevant issues.

Generally, I think that Debian testing is not necessarily less secure 
than Debian stable at any time. Newer software/package versions on 
Debian testing may contain newly introduced security vulnerabilities 
(e.g. with new upstream features, or less reviewed implementations) 
which may be in balance with fixed old security vulnerabilities, which 
are usually patched into Debian stable packages with short delay. But 
newer software/package versions as well make use of newer 
security/encryption protocols and standards. For the same reason I as 
well would not rate Debian necessarily more secure than a 
rolling-release distro.

The main difference IMO is the reliability and stability, as all 
packages on Debian stable have been much tested to be compatible with 
each other and no breaking changes happen when doing APT upgrades that 
would require configuration or setup changes to maintain the 
functionality of your system. Especially for server systems with 
multiple server daemons depending on each other, which must have at best 
zero downtime, while still doing regular security upgrades/backports, 
this is of high value. For a client system (no server), as long as you 
are able to use the console in case some mistake has happened, I 
personally would always use Debian testing right from the start. That 
way you do not need to mess with mixing repo suites (stable, testing, 
unstable).

And as you mention "unstable"/sid: Do not use it if it's not for testing 
(I mean help testing new package implementations on a test system) or 
development reasons. It's easy to run into a dependency mess or that 
suddenly large parts of the system are upgraded to sid packages. It's a 
development playground, not meant for production systems. It should be 
pretty fine to wait until a certain software version has reached the 
"testing" (currently Bullseye) suite, where dependency integrity and a 
basic testing by maintainers has been done already.

Kind regards,

Micha

Am 14.01.2021 um 15:20 schrieb ldavila@syt.net:
> Hey!
> 
> I have a couple of notebooks, a VM and like ~30 servers running debian 
> testing for 2 years now.
> My experience says you can count on stability.
> I have not detected any security issues yet... I'm also subscribed to 
> debian-security, most of the announcements on the list are already 
> solved on by the packages on bullseye.
> 
> regards
> lucas
> 
> El 14/1/2021 a las 10:44, Jorge P. de Morais Neto escribió:
>> Hi.
>>
>> I love having fresh packages.  To work around the oldness of Debian
>> stable, I have installed dozens of packages from buster-backports; 81
>> packages from Guix; 12 Flatpak applications (excluding runtimes); 20
>> pip3 packages (excluding their dependencies); and ≃10 npm packages
>> (excluding their many dozens of dependencies).
>>
>> The complementary package managers do not quench my thirst for
>> freshness, so I would like to upgrade Debian to bullseye.  Now that the
>> freeze has started, is it a good time to upgrade my personal notebook?
>> Should bullseye, by now, be relatively stable and, more importantly,
>> secure enough?
>>
>> I do not run any server; it is a personal laptop behind NAT---at least
>> for IPv4 (I don't know the details of IPv6).  I am subscribed to
>> `debian-security' and am willing to manually pull specific packages from
>> /unstable/ for security reasons.  That is, when a /testing/ package in
>> my installation has a serious security vulnerability, I am willing to
>> upgrade it to the security-fixed version from /unstable/ instead of
>> waiting for it to propagate to testing.
>>
>> In this context, is bullseye secure enough?
>>
>> Regards
>>

[toc] | [prev] | [next] | [standalone]

#1206

Em [2021-01-14 qui 16:08:43+0100], MichaIng escreveu:

> I can only agree, running some Bullseye systems as well since Buster was 
> released, not facing any relevant issues.
> [...]

Thank you Micha and lucas.  I have then upgraded my notebook to bullseye
and so far it has been pleasant indeed.

> And as you mention "unstable"/sid: Do not use it if it's not for
> testing (I mean help testing new package implementations on a test
> system) or development reasons. It's easy to run into a dependency
> mess or that suddenly large parts of the system are upgraded to sid
> packages. It's a development playground, not meant for production
> systems. It should be pretty fine to wait until a certain software
> version has reached the "testing" (currently Bullseye) suite, where
> dependency integrity and a basic testing by maintainers has been done
> already.

So you recommend avoiding sid even for specific package minor-version
upgrades with security fixes?

The Debian wiki says otherwise.  See
https://wiki.debian.org/DebianTesting#Best_practices_for_Testing_users

I currently follow the Debian wiki advice.  I carefully monitor the list
of installed packages from unstable, to avoid unintended upgrades.

Regards

-- 
- <https://jorgemorais.gitlab.io/justice-for-rms/>
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- <https://www.defectivebydesign.org/>
- <https://www.gnu.org/>

[toc] | [prev] | [next] | [standalone]

#1207

 > So you recommend avoiding sid even for specific package minor-version
 > upgrades with security fixes?
 >
 > The Debian wiki says otherwise.  See
 > https://wiki.debian.org/DebianTesting#Best_practices_for_Testing_users
 >
 > I currently follow the Debian wiki advice.  I carefully monitor the list
 > of installed packages from unstable, to avoid unintended upgrades.

Hi Jorge,

the way you explain how you use it, especially carefully reviewing the 
upgrade list, and are okay with the chance to run into bugs with the 
implementation, it should be fine, but I would never recommend it to a 
"regular" user, not knowing the experience level.

Read the notes at the top about which requirements need to be fulfilled 
before a package is merged from "unstable" to "testing":
- The package has been in "unstable" at least for 2-10 days (depending 
on the urgency of the upload).
- The package has been built for all the architectures which the present 
version in testing was built for.
- Installing the package into testing will not make the distribution 
more uninstallable.
- The package does not introduce new release critical bugs.

The other way round, the above points are not guaranteed for "unstable" 
and usually critical security fixes are available in testing a couple of 
days later, which should outweigh the possible chance for a major 
security issue introduced with a package from unstable due to a 
non-reviewed/tested implementation change for example.

When using testing only, APT upgrades can be applied without issues 
(dist/full-upgrade still needs to be reviewed of course due to possibly 
changing major versions) and a minimum of test and review is guaranteed, 
which IMO is worth it to wait for.

But it all depends on the use-case and personal preference, of course. 
And, if you do report bugs back to the package maintainers, you can help 
making testing->stable better for other users, so it's actually great if 
more (experienced) users use "unstable", but it's just not what I would 
recommend to a "regular" user ;).

Kind regards,

Micha

[toc] | [prev] | [next] | [standalone]

#1208

Hi.

Em [2021-01-16 sáb 21:11:32+0100], MichaIng escreveu:

> the way you explain how you use it, especially carefully reviewing the
> upgrade list, and are okay with the chance to run into bugs with the
> implementation,

To be clear, I don't assess the origin (testing or sid) of each new
package version every time I upgrade (daily).  What I actually do:
1. I review the upgrade list in aptitude looking for suspicious removals
2. I use `apt-listchanges' and `apt-listbugs'
3. I periodically invoke the following script:

--8<---------------cut here---------------start------------->8---
#!/usr/bin/env bash

declare -r SID="?narrow(?not(~Atesting),~i~Aunstable)"
aptitude search "${SID}" |
    tee /dev/stderr |
    wc -l
aptitude -s -t unstable full-upgrade "${SID}"
--8<---------------cut here---------------end--------------->8---

The pipeline that begins with `aptitude search "${SID}"' tells which
(and how many) sid packages are currently installed.  The second
aptitude invocation tells whether the installed sid packages are fully
up-to-date.

The second aptitude invocation should address the danger of an installed
sid package being barred from upgrading to its latest version because
that new version needs additional sid packages.  If that happens, I need
to be aware and decide whether the benefit of the new version outweighs
the downside of increasing the number of sid packages.

The question, of course, is whether software freshness is worth all this
work.  It this may be obsessive/compulsive behavior on my part.

> The other way round, the above points are not guaranteed for
> "unstable" and usually critical security fixes are available in
> testing a couple of days later, which should outweigh the possible
> chance for a major security issue introduced with a package from
> unstable due to a non-reviewed/tested implementation change for
> example.

You make valid points.  I will keep that in mind.

Regards

-- 
- <https://jorgemorais.gitlab.io/justice-for-rms/>
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- Free Software Supporter: <https://www.fsf.org/free-software-supporter>
- If an email of mine arrives at your spam box, please notify me.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.devel.testing

csiph-web