back to article Debian 9 feels like home with security upgrades and a flaming vulpine warming your toes

The Debian Project has released Debian 9 after two years and, as you might expect for a work that's taken so long, it's quite an overhaul. In addition to major updates and changes to nearly every bit of software, there have been some important policy changes too. This version – dedicated to Ian Murdock, Debian founder and the …

  1. Steve the Cynic

    Um. Excuse me?

    "Also be aware that Debian 9 moves to use the libinput X.Org driver, so if you've got a bunch of customisations that rely on the evdev driver (the default in Debian 8) you'll need to migrate them to use libinput syntax"

    Um. Excuse me? It doesn't migrate things automatically? :wtf:?

    1. tom dial Silver badge

      Re: Um. Excuse me?

      I took that to mean that local customisations would need redo, as is proper.

      When I started work as a mainframe system programmer 25 years ago, my boss laid out three rules:

      1. We do not code.

      2. We do no work without a change request.

      3. We install with vendor defaults.

      They were not followed rigidly, but contributed a good deal, I think, to system stability and to ease and cost of maintenance. I generally have adhered to them and rarely had trouble since then.

    2. Anonymous Coward
      Anonymous Coward

      SystemD = No Go!

      I switched to Devuan linux distro, a Debian fork without SystemD.

      It's appalling that Debian maintainer are bribed to infest Debian with SystemD. We all know SystemD is state sponsored spyware.

  2. Voland's right hand Silver badge

    Some rough edges

    The new firefox "run in a container" security tech comes close to killing a machine at times - container + new input subsystem + badly written javascript (hello screwfix) == accepting one character per few seconds. It does not get completely stuck so you can Alt-Shift away and kill the process, but still unpleasant.

    The upgrade is also hellishly long, especially on SSDs. It is so big that it hits the "reclaim" twilight zone on most consumer SSDs. As a comparison - two roughly equivalent machines, one with spinning rust, one with SSD, full desktop + development environment install. The spinning rust finished in under 3h. The SSD just about managed to complete the upgrade in 8.

    There are also some gremlins related to the way locking the screen now works, especially on media center machines.

    Otherwise, not bad. I will chose a weekend to update my the servers though - the process is way too long to consider doing it during working hours.

    1. This post has been deleted by its author

    2. Ramazan

      Re: The new firefox "run in a container" security tech

      firefox should be run in separate chroot on separate FS IMO.

      I run it on hardened Gentoo under strict RBAC policy subject with all .so and other files it uses written explicitly in the subject and everything else hidden. On the first run it requires stat() access to /home/username directory, but it can and must be hidden from firefox afterwards (because firefox installs inotify() watch on it and you'd be surprised by grsec alerts like "grsec: (username:U:/usr/lib/firefox/firefox) denied access to hidden file /home/username/.viminfz.tmp by /usr/lib/firefox/firefox[gmain:1234]" each time you edit something or modify files in your home directory). What I do in my home directory and names of files I work with are none of firefox'es fucking business.

    3. Anonymous Coward
      Anonymous Coward

      Re: Some rough edges

      Not suee what you were doing, but I upgraded several server systems already in under 20 minutes each.

      1. Voland's right hand Silver badge

        Re: Some rough edges

        but I upgraded several server systems already in under 20 minutes each.

        dpkg-query -l | wc -l

        Development + office + day-to-day use desktop : 4338

        Web, VPN + Mail Hosted Server with a fully blown catalyst env and a gazillion perl modules dragged in by foswiki dependencies: 858.

        Single purpose server: < 400

        There is nothing "wrong" to what I am doing, just a server is an easy upgrade. Very easy. Piece of cake compared to a desktop you develop on. 2.5-3h to upgrade that is actually not a very bad score.

  3. wolfetone Silver badge

    I thought Debian had ditched MySQL for MariaDB long ago? I'm sure on my Debian 8 laptop it's MariaDB installed and I didn't install it in any special way? Then again, it's been 2 years and I can't remember what I did yesterday let alone 2 years ago.

    1. Anonymous Coward
      Anonymous Coward

      MariaDB in Debian 8

      "I thought Debian had ditched MySQL for MariaDB long ago?"

      The article is a bit misleading in this respect; Debian doesn't have a default RDBMS nor choose which RDBMS is used by which package; both MariaDB and MySQL were in the Debian 8 repos, and that's not going to change in Debian 9; both will remain available.

      What has actually happened is that many packages have been switched from using MySQL, as their RDBMS back-end, to MariaDB by their upstream maintainers since the release of Debian 8. However, because Debian stable only releases updates for bug-fixes and security issues (because stability precludes feature changes*) none of those changes will have made it in to Debian 8.

      The new stable release means that those feature changes can now be included, so now many packages that used to use MySQL will now use MariaDB.

      * Any new feature changes behaviour, either by changing existing behaviour or by adding new behaviour; any change in behaviour can not be regarded as stable.

  4. Anonymous Coward
    Anonymous Coward

    Bold Statement

    "My advice is update to Debian 8.8 before attempting to update to 9.0. That way you won't encounter any problems."

    A very bold statement, indeed!

    1. Voland's right hand Silver badge

      Re: Bold Statement

      A very bold statement, indeed! - Concur.

      Depends on the complexity of the install. My desktops worked fine, but the machine which I use for media processing and has an ungodly amount of packages on top of the desktop build + remnants of the build reqs for them barfed twice through the upgrade. It was on 8.8.

      So it can barf even from 8.8. It does, however, recover so "Keep calm and carry on apt-getting" still applies.

      I have not tried arm and ppc systems yet to see how it works there. They are next on my "menu"

    2. This post has been deleted by its author

  5. hplasm

    Nice changes-

    Shame about the SystemD...

    1. Tim99 Silver badge

      Re: Nice changes-

      If Debian 8 works for you, it might be worth a look at Devuan: Link.

      1. hplasm

        Re: Nice changes-

        Already on Devuan for my latest; works like a charm!

      2. tom dial Silver badge

        Re: Nice changes-

        Devuan 9 ("ascii") also is quite decent, although on the machine I put it on the splash screen says "debian 8" for some reason. I assume this will be switched to GA shortly.

      3. Trilkhai
        Thumb Up

        Re: Nice changes-

        And if Devuan doesn't fulfill their needs, PCLinuxOS is also systemd-free and easy to leap to from Debian, thanks to its use of apt & Synaptic.

    2. steelpillow Silver badge

      Re: Nice changes-

      "Shame about the SystemD..."


      I am now torn between Devuan Jessie and Debian Stretch. Or, I could be lazy and wait for Devuan Stretch. Um.

    3. Gene Cash Silver badge

      Re: Nice changes-

      "Using sysvinit instead of systemd in Debian Stretch"

      Works for me w/o issues

  6. Christian Berger

    Stop claiming that secure boot is a security advantage...'s not, it's only a feature to protect business models. Nobody attacks systems via the boot process any more. (yes there were bootsector viri way back in MS-DOS)

    If you have access to the physical device there are so many things you can do so much simpler, with the simplest being a modified laptop of the same model which you swap with the original one. It only needs to show a password promt, transmit that password to your computer and display "incorrect password." Then you can use that password to unlock the actual computer, get all the files, and bring it back, claiming that you mixed them up on mistake. After all companies typically have standardized on laptop models and they all look alike. For most larger companies that should work, as few employees would report that. After all it would mean admitting that they made an error.

    1. Voland's right hand Silver badge

      Re: Stop claiming that secure boot is a security advantage...

      Secure boot is not about bootsector.

      It is about having an uninterrupted chain of verified components starting at the BIOS/Firmware/Bootloader and all the way to the executable proven by cryptography.

      Microsoft implementation of this is quite poor and relatively benign. If you want to see how really funky can this get have a look at ChromeOS on Arm ChromeBooks.

      I am starting to swear at the mere thought of pushing Debian 8.8 on my Samsung Chromebook to 9.0. It took me one whole f*** afternoon to win the fight last time when I got it from 7 to 8. It is installed properly - on the internal SSD. That is something even Debian wiki claims to be not possible - it has a procedure for SD card install only and/or Crouton installs. While it is not impossible, the whole idiocy with the signed kernel makes it a form of BSDM experience. Very BDSM.

      1. steelpillow Silver badge

        Re: Stop claiming that secure boot is a security advantage...

        Secure Boot is not about either the boot sector or a secure chain for the user. It is about a secure chain for the commercial proprietor of certificate provision. The conflict of licensing ethos this creates is enough to stop Debian in its tracks, and rightly so.

        As a user, there are several easy workarounds - even if the hardware provider locks SB down.

        Consequently, as a Black Hat there are several easy workarounds....

      2. Christian Berger

        Re: Stop claiming that secure boot is a security advantage...

        "It is about having an uninterrupted chain of verified components starting at the BIOS/Firmware/Bootloader and all the way to the executable proven by cryptography."

        Yes, but what does it prove? It only proves that there is a signature which was signed by a CA. It doesn't prove that it's in any way secure, it doesn't prove that the CA private key was not stolen or the CA was forced/tricked into signing malware. Signed malware is not just a theoretical problem, there has been some in the wild.

        "Secure Boot" tries to outsource security to a 3rd party which somehow is secure. It gives you a false sense of security without providing any actual security.

      3. Ramazan

        Re: It took me one whole f*** afternoon to win the fight last time when I got it from 7 to 8

        In the past 10 years none of the Debian's dist upgrades worked without manual intervention on my systems. Upgrade from 8.8 to 9 hasn't suceeded for me yet, this one is the worst! YMMV

    2. Anonymous Coward
      Anonymous Coward

      Stop claiming that secure boot is evil just because you can't undestand it.

      I would like secure boot to harden my Debian-based appliances. Most issues around secure boot are ideological, not technical, and only because Microsoft is involved. As long as the bootloader and kernel can be tricked into running untrusted code, there's a big security hole. Sure, it can also be used to stop cracked software, but that's exactly a security hole.

      1. Ramazan

        Re: I would like secure boot to harden my Debian-based appliances

        If you want to harden your appliances, you should use hardened Gentoo instead (but it will take a pair of months or more to properly set up grsecurity RBAC).

        By the way, enabling RBAC early in the boot process is _not_ recommended. If you read default /etc/grsec/learn_config file, you'll notice this:

        # the below lines are for catching the occasional use of init.d scripts at runtime

        # comment them out if you are starting learning before services are started by init

        # (a highly non-recommended choice)

        inherit-learn /etc/init.d

        inherit-learn /etc/rc.d/init.d

        1. Anonymous Coward
          Anonymous Coward

          Re: I would like secure boot to harden my Debian-based appliances

          Sorry, the special hardware I need to use on my appliances has no support for Gentoo. It's only RedHat/SuSE/Debian/Ubuntu. It's fairly expensive, and we have to go a supported route, support won't investigate and fix issues for an unsupported OS.

      2. Christian Berger

        Re: Stop claiming that secure boot is evil just because you can't undestand it.

        "Most issues around secure boot are ideological, not technical, and only because Microsoft is involved."

        And that's virtually the _only_ reply you get when you actually make sensible points against Secure Boot and "Trusted Computing".

        This is unfortunately a common problem right now. People invent something, then other people criticise it, and instead of replying to the critique in a sensible way providing arguments, they claim that the critique is just ideological and therefore bad. That's the typical strategy one applies when they are out of arguments. At this point the other side is usually giving up, which sounds like winning to the first side.

        And yes, in a way it is an ideological argument. I want to have control over the computer I bought. I paid for it, so I make the rules on my computer. You may disagree, but I see this as the base to being able to trust my computer, which I see as an extension to my brain. (just like pen and paper when your're solving equations) In this ideology Secure Boot does not bring any advantage. Even if I can add my own keys to the system, I'll have to have the private keys on that system so I can sign the code I want to execute.

        1. Anonymous Coward
          Anonymous Coward

          " then other people criticise it, and instead of replying to the critique in a sensible way"

          Which is what people criticizing secure boot and anti-tamper chips exactly do, especially if Microsoft is involved. Especially the OP was babbling about "boot sector viruses" (UEFI AFAIK has no boot sector at all) which showed how sensible and technical was his critique. And your attempt to shutdown my argument it's exactly applying the strategy you pretend to blame.

          Explain how secure boot takes control away from you. You can disable it. You can load keys. Don't believe me? Maybe you will believe

          Sure, some system may be locked down. Don't buy them. They are not designed to be extensible and programmable systems. Sometimes it may be useful. Would you like a critical system allow easy tampering with? Sometimes it's just "commercial control", true, like a phone or a console. If you don't like them, vote with your money, don't buy them. Looks they may be very successful, though.

          Why should you have the private keys on the same system??? Keep them on external (encrypted) storage, sign the code, remove the storage. Heck, they can (and should) be on a tamper proof external cryptographic device.

          So, once again, critiques looks to stem from a lack of knowledge, using second hand incorrect information only. Is pointing out factual incorrect statements, being out of arguments? Or you have "alternative facts", which are so common today?

          And still most critiques about secure boot are FUD about not being able to run Linux (and since secure boot was introduced, how many weren't able to run their preferred distro of LInux), "commercial control" - yes, it makes harder or impossible to run pirated copies, where's the issue? After all you all run Linux, not a pirated copy of Windows, don't you?, you use only open source software, you don't try to pirate PS or XBox games, don't you?

          And about MS controlling the keys and refusing to allow other OS to run (it will hit an antitrust wall immediately, especially in the EU).

          And that all utterly blind to what from a security perspective being able to spot rogue code from the very beginning means.

          It's just an ideological and political position - the FSF/GNU one, after all - there is no sensible and technical critique, it's just the fear of being controlled by the evil Spectre who's attempting to rule the world, and will be saved only by the open source militants, especially those who just use open source because they don't have to pay for, while attempting to crack what they like but they don't want to pay for, but still hypocrites enough to try to shield under a false "freedom" cloak.

          1. Christian Berger

            Re: " then other people criticise it, and instead of replying to the critique in a sensible way"

            a) We live in a vendor dominiated economy. If no vendor offers open systems, you cannot buy them. Most high profile ARM devices are already locked down, and Microsoft has already made some steps in that direction, shutting down (still rather obscure) features like connected standby. Windows 8 on ARM even forced secure boot.

            Being able to turn off Secure Boot is now an optional feature:


            b) I need to have the secret keys on the same system, since in the full concept of "Trusted Computing" no code should ever run that is not signed. Therefore every little 3 line program I write as a bash script would have to be signed. Since the whole hypothetical advantage of "Trusted Computing" relies on there being a complete chain of trust to be unbroken, I have to sign every command. Otherwise the whole tower of babel breaks down.

            c) Yes, I know what malware can do at the boot level, but that's largely irrelevant as you can reach the same relevant goals even in unprivileged userspace. It doesn't matter if you have control over the kernel without the user knowing, as you can access all user files via its user privileges. It doesn't matter where you enter the system, once you are inside, you have typically reached your goal.

            d) BTW nobody talks about "running pirated copies" of whatever. I don't see why you bring up that topic.

            However, at least you had some arguments, and I applaud you for that.

        2. steelpillow Silver badge

          Re: Stop claiming that secure boot is evil just because you can't undestand it.

          @Christian Berger. No need to feed the troll. Just let the sunlight do its job.

  7. Frank Zuiderduin

    Check your facts please

    "...KDE 4.16..."

    Not bloody likely! Stretch/Testing has had KDE 5 for well over a year.

  8. frank ly

    re. MATE version

    The MATE version in Stretch is 1.16.2. The MATE organisation has recently released version 1.18 and this will be available in Mint 18.2, probably before the end of June. I've no idea if Debian will update MATE in Stretch as time goes by.

    I've been running Stretch for two months now and had no problems with it after manually migrating from Mint 18.1. The only problem is that in Debian, the MATE panels have a transient cosmetic problem associated with the drawers. This problem does not exist in Mint 18.1 with the same version of MATE. These types of problem have been in MATE for about five years now and the only good thing is that their severity seems to get less as time goes by. Anyway, it's only a little cosmetic thing.

    Stretch works fine and I'd recommend trying it, in a VM or a spare hard drive.

  9. tony2heads


    It a nickname for the red panda (Ailurus fulgens) not a burning fox. It is related to the raccoon

    1. steelpillow Silver badge

      Re: firefox

      "It a nickname for the red panda (Ailurus fulgens) not a burning fox. It is related to the raccoon"

      Oh, I thought it was a fictional MiG fighter stolen by Clint Eastwood.

  10. Ramazan

    X.Org no longer needs root privileges

    "Among the most significant, X.Org no longer needs root privileges to run the display server. That eliminates an entire class of attacks that work by going after privilege escalation via X.Org. However, to run X.Org as non-root you'll need to install logind and libpam-systemd and use GDM 3 for your login tool since only GDM 3 supports running it without root privileges."

    This is interesting indeed and I'd like to see this in action. Unfortunately, all me Debian setups have systemd (and libpam-systemd and libsystemd0 and policykit* and libpolkit-* etc and so on) purged, so I doubt I'll ever witness this on real hardware, maybe on VM some other time.

    BTW, running X without full root privileges should be possible if you remove suid/sgid from /usr/bin/X and use 'setcap' on it instead. Judging from my RBAC policy for /usr/bin/Xorg subject, CAP_IPC_OWNER, CAP_WAKE_ALARM and CAP_SYS_RAWIO should be sufficient for Xorg with "VESA" driver and CAP_IPC_OWNER, CAP_WAKE_ALARM and CAP_SYS_ADMIN should work for Xorg with "intel" one.

  11. Sven Coenye

    SysV holdouts using LUKS: beware

    Stretch come with a rather nasty bug that prevents LUKS volumes from unmounting properly on reboot or shutdown. It bites particularly on reboots as the kernel will eventually hard kill everything and it is then a crapshoot as to whether or not you end up with dirty filesystems.


  12. Ramazan

    Re: and it only has cold water because hot has been deprecated

    "Previous versions of the smartmontools package included a tool update-smart-drivedb which downloaded updated drive definitions from the smartmontools website and stored them at /var/lib/smartmontools/drivedb/drivedb.h"

    "This tool did not download the definitions in a secure manner and so the feature has been removed in this version. Future drive DB updates will be propagated via normal Debian package updates, including backports."

    Ha-ha-ha. The hot water pipe did not deliver hot water in a secure manner and has been disconnected. In the future water will be delivered pre-heated and packaged in 19 liter bottles via normal FedEx channels.

  13. Ramazan

    openssh-server now depends on libsystemd0, the same do unix-utils, xserver-xorg and a lot of other tools. My dist upgrade attempts have failed thus.

    Goodbye, Debian. It's very telling they dedicated this release to Ian. RIP

    1. Ramazan

      I've set pin 1001 for jessie versions and rolling back my partially upgraded system back to jessie. After the downgrade is finished, I'm switching to Devuan by following the guide.

      I used to be a co-maintainer of some Debian packages in the past (won't disclose which ones in order to remain anonymous), but now I'm done with this distro even as a user, what a shame. It was a good time, though...

    2. Justin Pasher

      Re: libsystemd0

      Are you sure that matters?

      I haven't had a chance to test an upgrade yet, but all of my machines are set up using SysV (package sysvinit-core). They also all have libsystemd0 already installed. I know the key package to avoid in Debian Jessie was systemd-sysv. Perhaps it changed in Stretch? I'm hoping not.

      1. Ramazan

        Re: libsystemd0

        "Are you sure that matters?"

        I think you _can_ upgrade if you hadn't pinned libsystemd0 to -1. Having libsystemd0 on a system without the actual systemd daemon is not a big deal for most people, but it does matter to me, so I don't feel "like home" in Debian anymore.

  14. NB

    In my head that entire article was being read by Morgan Freeman...

  15. Anonymous Coward
    Anonymous Coward

    I had a prefectly painless transition

    I normally run Debian "testing" from about six months since it transited from the previous "unstable" or "sid" and had some opportunity to gain some proven stability. It has an advantage over running always the "stable" as slowly it becomes obsolete.

    Thus, I was running "stretch" for already at least one and a half years and there were thus no transition pains when it graduated from "testing" to stable.

    I always keep an up to date version of the "new" testing, often on different partition, accessing a common "home" partition and separately bootable root partition. "home" data is regularly and continually backed up, so that as soon as the new "testing" gains reasonable stability it can be easily tested by rebooting into it, and, in the unlikely event of a disaster one can simply reboot into the "stable" and if necessary restore relatively a small amount of data back on safe ground.

    Most of my Debian boxes are eight to ten years old "laptops" or "notebooks" still with Celeron processors. Despite being 32 bit machines, they have all been experimentally migrated a while back to run as "multiarch" "amd64" + "i386" boxes rather than exclusively "i386" as some independent apps lost i386 support. Eventually I discovered that the "amd64" software and apps were running perfectly even on the 32 bit machines, except for some machines which were waiting for some drivers and thus still required for a while running the 3.16 "amd64" Kernel, but this was solved with the latest, 4.9.0-3 "amd64" kernel. Now, the only "i386" apps being run are those "non-free" apps that were not developed by their vendors beyond "i386".

    Bootable partitions running "stretch" as the previous "testing" were simply "anchored" to "stretch" in sources.list, thus transiting to "stable" without any change.

    Testing bootable partitions simply retained "testing" in sources.list and thus, seamlessly transited from "stretch" to "buster" as the new "testing", and, so far are using the same "amd64" kernel while various apps get updated at least daily, so far with no ill effects.

    I was not running the old "sid" as "unstable" nor the new one because previous experience proved them to be too unstable for normal daily use.

    All the machines started off new with various Microsoft Windows versions pre-installed which were immediately repartitioned and had Debian installed into a multi-boot environment.

    Sooner or later we were forced to remove the Windows partitions usually because of Windows instability, and/or the hardware becoming inadequate to cope with Windows unquenchable hunger for resources, and thus the space was freed to meet the Linux demands which were also growing but not as fast as Microsofts'.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like