On Tue, Apr 19, 2022 at 04:30:44PM +0100, Tim Woodall wrote: > > On Tue, Apr 19, 2022 at 02:38:03PM +0200, Jonas Smedegaard wrote: > > > When I install systems, I consider non-free blobs more risky than other > > > code. > > Do you consider loadable non-free blobs more risky than their older > > versions soldered onto the hardware? > > > Definitely "more risky" possibly not "less secure" > > One of my biggest frustrations is that it's impossible to selectively > apply "security patches" and companies are wont to "smuggle" in feature > changes along with security fixes. [...] > No, but I do see a benefit in them not being applied automatically as > part of a standard update. And for something like a firmware upgrade for > a network card, I might only want to install it if there was a security > issue that might actually impact me or I was having a problem. Otherwise > it's hard to imagine a scenario where a firmware upgrade can make things > better but it's easy to imagine it making things much worse. Then what about hardware that doesn't have soldered firmware, only loadable one? Would you not use it at all? > apt-get upgrade will tell you that linux-image-amd64 has a newer version > but it then takes apt-get dist-upgrade to commit to that update. (this is not really relevant, not exactly true and not really a feature) > (kernels are a bit of a funny case because some kernel updates happen > under apt-get upgrade) (most package updates happen under apt-get upgrade) > I'd like to see something similar for (non-free) firmeware where users > can choose to default upgrade with their regular updates or can hold > back updates. Considering what I wrote above, this isn't really something we usually do. -- WBR, wRAR
Attachment:
signature.asc
Description: PGP signature