Ubuntu LTS: many vulnerabilities despite long-term support

We can't really blame them

I hope the Debian guys create a more user-friendly installer. But if you notice, the installer is the same since what, 2005? hehehehe. I don't think a new installer will land any time soon.

 

I am used to those type of installers, it certainly is better than the FreeBSD sysinstall I used many times

 

Yep, when I started the Deb installer nearly did me in. Determination persisted along with some great help from a few of you guys. I can say that Debian never misses a beat for me. I had a couple of issues with /boot on a flash while using a usb3 port to mount the system. Once I learned the issue and I now use a usb2 port, I never have any issues. Granted my install was anything but typical.

Now I actually like the Deb installer because is allows users to customize the config, LUKS headers, etc.....

 

yeah its pretty good e.g. able to setup LVM containers.

I remember having to use the centos installer over a KVM which was awkward due to the GUI, in some respects text based installers are better when doing remote server installs.

 

What specific CPU features are we talking about here?

 

https://outflux.net/blog/archives/2014/02/03/compiler-hardening-in-ubuntu-and-debian/ interesting to note here about compiler hardening of Ubuntu packages over Debian.

 

Yes, I've seen that before. It's a rather old post, though. I wonder if there are newer figures somewhere.

 

He is still active, why not ask him.

 

https://bugs.launchpad.net/ubuntu/ source/update-manager/ bug/1574670

ubuntu-support-status returns inaccurate and misleading information.

 

https://bugs.archlinux.org/task/49616

Interesting take on security, RH, Canonical, Debian all have this patched.

 

It requires adjacent network access, and so its "hard to pull off." This is similar to the crap Mint does with a number of packages, only Mint I dont think even drops the upstream release when it happens (so Mint is even worse); Mint however this can be turned off. Stuff like this is the one area where Arch is really meh on security. When upstream fails to be prompt with a security patch and its not a vulnerability of critical importance, Arch is left vulnerable.

Debian's policy is vastly superior here especially if the user has unattended-upgrades installed and setup; unattended upgrades provides no stability risk on Stable or Old Stable since the package versions arent changing- just security-patched versions of the same package version are installed. Arch's rolling release makes such an approach impossible.

Arch has had a policy of "vanilla packages" since the beginning and as such are always hesitant to patch anything. As security threats for all operating systems mount, I do hope eventually Arch will reconsider in terms of security patching but I dont find it likely.

There's been some fantastic exploration of security policy for Linux systems here on Wilders over the last few weeks- its good all of us *nix heads are getting some education on the strengths and weaknesses of each distro.

So far I would say Alpine, Fedora, and Debian are among the best with security. Its hard to say with Subgraph as its still being put together and there isnt a ton of information on it. Ubuntu is also good, but the very short support period of the non-LTS releases is concerning- you must make sure to update to the newest version when it is released or you can be exposed to potentially very nasty security bugs. Or stick with LTS releases... Arch is prolly next in line given that at least they seem to patch nasty security bugs and upstream takes care of the rest (except in cases like what you point out).

When Debian starts hardening its packages by default, I may very well switch.

 

Ubuntu short support is not for critical deployment and Ubuntu LTS packages have more hardening by default over Debian as the graph posted above shows. This is why better to stick to big guns if you need security and stability and btw, Gentoo devs are way better in this respect.

 

Take a look at this, its a confirmed bug and its also occurring with Skylake but Arch devs won't listen. A Arch bug report has been listed as well. https://bbs.archlinux.org/viewtopic.php?id=184817

 

Yeah thats pretty crap... Opened almost a year and a half ago yet still nothing.

If I had that architecture Id just use Debian or an Ubuntu LTS minimal install.

 

I use ck-kernel from graysky, its a basic issue of setting config Hz=250 as Ubuntu and SUSE does and also another setting that Ubuntu does specifically, this makes the CPU scale normally and keep temps under control. Just adamant attitude as 300 setting in Arch is for better PAL/NTSC performance but that was in days of dual core CPU, with today's multicore and GPU handling via VDPAU or others, not needed.

 

Arch devs have always been real stiff with things like that. Im fortunate that my hardware is very linux friendly and doesnt seem to have any difficult hardware where these sort of changes would be vital.

Funny how fast they jumped on systemd when it came out considering the resistance to change theyve shown in other areas.

 

Arch only has ~30 developers, and I'm pretty sure they traded patching with maintaining good quality packages.

 

Its because of this my next CPU will be the new AMD which hopefully will work well on Arch.

 

In this case they just need to resort to the standard kernel config of 250 in config Hz.

 

Hopefully you'll be getting a Zen processor And a RX 480.

I know It's so simple.

 

FTFY

 

Yes waiting for it with baited breath.

 

I could compile the Kernel for you if you want. Just tell me which option to tweak in the config file, or give me the patch ready-to-rock.

 

I was coming to check the update on this thread and noticed this reply at the top which I never really saw.

I just thought id mention- in some ways its easier to install debian from within an existing linux distro. I just got done doing that- installed Debian Jessie from Arch into a different btrfs subvolume. I had to do this due to btrfs/luks corruption bugs prior to kernel version 3.20- even trying to install from a liveUSB (also on 3.20) could cause the corruption. This way I did the install from a 4.6.3 kernel (on Arch), and installed a 4.6.0 kernel from backports (prolly work on a grsecurity setup once I get everything setup). Trying KDE 4 for a change since Ive been on Openbox for ages...

Requires editing some config files and searching for a few packages, but some people might want to give this way a try.

 

A tutorial wouldn't be a bad thing, you know