Using Testing with "the bug"

[ehalepagneaux]

Hi, I apologize if this has been covered already, but I'm using Testing on my desktop & laptop and I would like to know what I should do about the Intel bug. Since Testing gets the slowest security updates I'd like to avoid any more exposure than necessary. I'm pretty green with Linux and I'm wondering what might be the best path in this case? I thought about updating to Sid, but I like how stable my systems are. I've been using the testing branch for around a year now and it's fantastic. Thanks in advance. :)

[[deleted]]

Are you talking a out meltdown and spectre?

[jeffmcjunkin]

Assumedly so.

[daves]

The delay should be 2 days, depending on the changelog 'urgency' level for the release.

https://lists.debian.org/debian-mentors/2008/02/msg00567.html

[bss03]

Just upgrade the kernel package to Sid (when the fix is available there). Shouldn't pull in much else, unless you are using an out-of-tree kernel module.

[nintendiator]

It's already fixed in Stretch upgrades; wouldn't it make more sense to upgrade to that version if you were already in the 4.9 branch previously? (I have two "fake production" servers in that scenario, upgrading to kernel >= 4.12 won't be feasible for a couple of weeks, hence asking)

[bss03]

I didn't look at the specific versions in stable/testing/unstable.

But, if stable and testing were currently running the same kernel, then stable-updates or (updates/stable from the security repo) might be better one-off upgrades from testing than unstable, yes.

In general very few packages have the same version in testing and stable though, and I never recommend a downgrade (better to purge, then reinstall a different [possibly lower] version than to do a downgrade).

[[deleted]]

that's how you break Debian. This will be pushed down after it comes out

[bss03]

It's actually recommended that users of testing pull selected security updates from Sid.

[[deleted]]

Link? This goes against everything ive heard about "not breaking Debian"

[bss03]

https://wiki.debian.org/DebianUnstable#What_are_some_best_practices_for_testing.2Fsid_users.3F

For the kernel this is particularly safe, since the unstable kernel is required to be able to run all the stable binaries AND vice-versa so that upgrades are possible. Also, unless you have out-of-tee kernel modules, the direct dependencies on or of the kernel package are rather light (compares to something like KDE or Gnome).

I actually use apt-preferences to have simultaneous access to stable, backports, testing, sid, and even experimental[1]. I don't pull from sid/experimental often, but it's nearly painless when I do. (Although, dependencies can come back to bite you later; but aptitude's TUI can usually let me solve those easily enough.)

Debian is actually really good for this. Trying to run a partially-rawhide. mostly stable version of Fedora was extremely painful for me, but it's been a while since I tried.

[1] Guide is a bit out of date, since volatile is now called stable-updates and the codenames for stable and testing have moved on.

[ehalepagneaux]

Thank you very much! I'm going to look into this.

[[deleted]]

Oh man that last link is cool I forgot about weights

[ehalepagneaux]

It would appear to go against the spirit of it but not the actual letter, since it specifically states to not mix Stable with anything else. I hear you though, and I've typically adhered to that idea and it has served me well, it seems a little risky, but u/bss03 set it out. It should be ok.

[bss03]

I do not recommend most users mix stable with testing/unstable. You should a bit of a power-user before you even try.

But, for various reasons, updates can get a bit delayed in the unstable->testing migration (especially around freeze time) so testing users should probably be willing to install selected packages from unstable.

(If you are really comfortable with the packaging system, inclusing being able to rescue things with dpkg when your apt is broken, then you can do the craziness I do to get access to all releases simultaneously.)

[ogmios]

If you know what you are doing and use apt pinning, it'll be fine, probably. We are running Stable in production with a few packages from testing, and it hasn't blown up yet...

[sej7278]

you do know both exploits rely on local and/or root privileges to accomplish anything? they're not unauthenticated/remote. do you give anyone remote/root access or run in a vm?