Re: xz backdoor

[Christian Kastner <ckk@kvr.at>]

On 2024-03-30 20:20, Russ Allbery wrote:
> I personally specifically want my workstation to be running unstable, so
> I'm watching to see if that's considered unsafe (either, immediately,
> today, or in theory, in the future).
> 
> If I have to use a stable host, I admit I will be sad.  I've been using
> unstable for my personal client and development (not server, never
> exposing services to the Internet) systems for well over a decade (and,
> before, that, testing systems for as long as I've been working on Debian)
> and for me it's a much nicer experience than using stable.

I've heard many people say that, and I believe them. It might also work
for me if I had more time for Debian ($dayjob is unrelated to FOSS) and
thus more time to react to/report issues I find, but when I come home
from work, I really just want a system where I'm practically never
surprised by a significant change, other than security fixes.

Also, I don't possess the skill to quickly work around transient issues
as you mention below.

> It also lets
> me directly and practically dogfood Debian, which has resulted in a fair
> number of bug reports.

I wish I could do that in general. I try to do so during freezes, for
contributing polish to a release, but otherwise I (1) just place my
faith in upstream's own tests and hope autopkgtests have good coverage
so debci catches things, and (2) I rely on the fact that my work in
containers is also a form of dog-fooding.

For more elaborate projects, I do have complex systems set up based on
various environments. They are trivial to set up, tear down, snapshot,
"fork", etc. And they can be locked down pretty tightly.

And it's actually pretty convenient. Reproducing an issue for some other
release, even of a derivative, often only requires trivial changes to a
Dockerfile, like simply replacing the base image name.

(Actually, now that I think about it, apart from my browser, I probably
spend most of my time in terminals within unstable or experimental
containers, and/or connected to containers running services...)

> (This is an analysis specific to me, not general advice, and relies
> heavily on the fact that I'm very good at working around weird problems
> that transiently arise in unstable.)

Best,
Christian