Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.devel > #104164 > unrolled thread
| Started by | Steve McIntyre <steve@einval.com> |
|---|---|
| First post | 2022-04-19 02:30 +0200 |
| Last post | 2022-04-30 14:10 +0200 |
| Articles | 20 on this page of 148 — 47 participants |
Back to article view | Back to linux.debian.devel
Firmware - what are we going to do about it? Steve McIntyre <steve@einval.com> - 2022-04-19 02:30 +0200
Re: Firmware - what are we going to do about it? Ansgar <ansgar@43-1.org> - 2022-04-19 08:40 +0200
Re: Firmware - what are we going to do about it? Devin Prater <r.d.t.prater@gmail.com> - 2022-04-19 10:00 +0200
Re: Firmware - what are we going to do about it? Marco d'Itri <md@Linux.IT> - 2022-04-19 10:30 +0200
Re: Firmware - what are we going to do about it? parodper <parodper@disroot.org> - 2022-04-19 10:40 +0200
Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-19 10:50 +0200
Re: Firmware - what are we going to do about it? Steve McIntyre <steve@einval.com> - 2022-04-19 12:00 +0200
Re: Firmware - what are we going to do about it? Luca Boccassi <bluca@debian.org> - 2022-04-19 11:40 +0200
Re: Re: Firmware - what are we going to do about it Steven Robbins <steve@sumost.ca> - 2022-04-23 20:40 +0200
Re: Firmware - what are we going to do about it Steve McIntyre <steve@einval.com> - 2022-04-24 01:30 +0200
Re: Firmware - what are we going to do about it Luca Boccassi <bluca@debian.org> - 2022-04-25 09:40 +0200
Re: Firmware - what are we going to do about it? Christian Kastner <ckk@debian.org> - 2022-04-19 12:00 +0200
Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-19 12:10 +0200
Re: Firmware - what are we going to do about it? Jonas Smedegaard <jonas@jones.dk> - 2022-04-19 12:50 +0200
Re: Firmware - what are we going to do about it? intrigeri <intrigeri@debian.org> - 2022-04-19 13:40 +0200
Re: Firmware - what are we going to do about it? Jonas Smedegaard <jonas@jones.dk> - 2022-04-19 14:40 +0200
Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-19 14:50 +0200
Re: Firmware - what are we going to do about it? Jonas Smedegaard <jonas@jones.dk> - 2022-04-19 16:20 +0200
Re: Firmware - what are we going to do about it? Tim Woodall <debiandevel@woodall.me.uk> - 2022-04-19 17:50 +0200
Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-19 18:10 +0200
Re: Firmware - what are we going to do about it? Timothy M Butterworth <timothy.m.butterworth@gmail.com> - 2022-04-19 18:30 +0200
Re: Firmware - what are we going to do about it? Jonas Smedegaard <jonas@jones.dk> - 2022-04-19 19:00 +0200
Re: Firmware - what are we going to do about it? Ansgar <ansgar@43-1.org> - 2022-04-19 19:10 +0200
Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-19 20:00 +0200
Re: Firmware - what are we going to do about it? Jonas Smedegaard <jonas@jones.dk> - 2022-04-19 23:10 +0200
Re: Firmware - what are we going to do about it? Ansgar <ansgar@43-1.org> - 2022-04-20 08:10 +0200
Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-20 08:20 +0200
Re: Firmware - what are we going to do about it? Tim Woodall <debiandevel@woodall.me.uk> - 2022-04-19 19:00 +0200
Re: Firmware - what are we going to do about it? Russ Allbery <rra@debian.org> - 2022-04-19 19:30 +0200
Re: Firmware - what are we going to do about it? Jonas Smedegaard <jonas@jones.dk> - 2022-04-19 23:40 +0200
Re: Firmware - what are we going to do about it? Russ Allbery <rra@debian.org> - 2022-04-20 00:00 +0200
Re: Firmware - what are we going to do about it? Jonas Smedegaard <jonas@jones.dk> - 2022-04-20 11:10 +0200
Re: Firmware - what are we going to do about it? Steve McIntyre <steve@einval.com> - 2022-04-20 18:20 +0200
Re: Firmware - what are we going to do about it? Ansgar <ansgar@43-1.org> - 2022-04-20 18:30 +0200
Re: Firmware - what are we going to do about it? Steve McIntyre <steve@einval.com> - 2022-04-20 18:50 +0200
Re: Firmware - what are we going to do about it? Russ Allbery <rra@debian.org> - 2022-04-20 20:00 +0200
Re: Firmware - what are we going to do about it? Sam Hartman <hartmans@debian.org> - 2022-04-21 02:10 +0200
Re: Firmware - what are we going to do about it? Steve McIntyre <steve@einval.com> - 2022-04-21 15:50 +0200
writing good GR ballots (Re: Firmware - what are we going to do about it?) Holger Levsen <holger@layer-acht.org> - 2022-04-22 12:00 +0200
Re: Firmware - what are we going to do about it? Luca Boccassi <bluca@debian.org> - 2022-04-20 00:30 +0200
Re: Firmware - what are we going to do about it? Christian Kastner <ckk@debian.org> - 2022-04-19 14:10 +0200
Re: Firmware - what are we going to do about it? Jonathan Dowland <jmtd@debian.org> - 2022-04-20 12:50 +0200
Re: Firmware - what are we going to do about it? Paul Wise <pabs@debian.org> - 2022-04-20 09:30 +0200
Re: Firmware - what are we going to do about it? Timo Röhling <roehling@debian.org> - 2022-04-19 12:10 +0200
Re: Firmware - what are we going to do about it? Jeremy Stanley <fungi@yuggoth.org> - 2022-04-19 14:40 +0200
Re: Firmware - what are we going to do about it? Bastian Blank <waldi@debian.org> - 2022-04-19 23:10 +0200
Re: Firmware - what are we going to do about it? Jeremy Stanley <fungi@yuggoth.org> - 2022-04-20 01:00 +0200
Re: Firmware - what are we going to do about it? Steve McIntyre <steve@einval.com> - 2022-04-20 17:40 +0200
Keep both images but stop pretending no-free is unofficial Sam Hartman <hartmans@debian.org> - 2022-04-19 16:30 +0200
Re: Keep both images but stop pretending no-free is unofficial Marc Haber <mh+debian-devel@zugschlus.de> - 2022-04-19 19:00 +0200
Re: Keep both images but stop pretending no-free is unofficial Sam Hartman <hartmans@debian.org> - 2022-04-19 22:10 +0200
Re: Keep both images but stop pretending no-free is unofficial Bastian Blank <waldi@debian.org> - 2022-04-19 23:10 +0200
Re: Keep both images but stop pretending no-free is unofficial Pirate Praveen <praveen@onenetbeyond.org> - 2022-04-20 09:30 +0200
Re: Keep both images but stop pretending no-free is unofficial Andrey Rahmatullin <wrar@debian.org> - 2022-04-20 09:50 +0200
Re: Keep both images but stop pretending no-free is unofficial Pirate Praveen <praveen@onenetbeyond.org> - 2022-04-20 10:00 +0200
Re: Keep both images but stop pretending no-free is unofficial Andrey Rahmatullin <wrar@debian.org> - 2022-04-20 10:10 +0200
Re: Keep both images but stop pretending no-free is unofficial Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2022-04-20 14:30 +0200
Re: Keep both images but stop pretending no-free is unofficial Andrey Rahmatullin <wrar@debian.org> - 2022-04-20 15:10 +0200
Re: Keep both images but stop pretending no-free is unofficial Ansgar <ansgar@43-1.org> - 2022-04-20 10:30 +0200
Re: Keep both images but stop pretending no-free is unofficial Samuel Thibault <sthibault@debian.org> - 2022-04-20 16:30 +0200
Re: Keep both images but stop pretending no-free is unofficial Ansgar <ansgar@43-1.org> - 2022-04-20 16:40 +0200
Re: Keep both images but stop pretending no-free is unofficial Marco d'Itri <md@Linux.IT> - 2022-04-19 23:10 +0200
Re: Keep both images but stop pretending no-free is unofficial Gunnar Wolf <gwolf@debian.org> - 2022-04-21 20:20 +0200
Re: Keep both images but stop pretending no-free is unofficial Hakan Bayındır <hakan@bayindir.org> - 2022-04-21 20:30 +0200
Re: Keep both images but stop pretending no-free is unofficial Gunnar Wolf <gwolf@debian.org> - 2022-04-21 21:20 +0200
Re: Firmware - what are we going to do about it? Diederik de Haas <didi.debian@cknow.org> - 2022-04-19 21:40 +0200
Re: Firmware - what are we going to do about it? Paul Wise <pabs@debian.org> - 2022-04-20 09:40 +0200
Re: Firmware - what are we going to do about it? Paul Wise <pabs@debian.org> - 2022-04-21 08:20 +0200
Re: Firmware - what are we going to do about it? Pirate Praveen <praveen@onenetbeyond.org> - 2022-04-20 09:50 +0200
Re: Firmware - what are we going to do about it? Devin Prater <r.d.t.prater@gmail.com> - 2022-04-20 12:10 +0200
Re: Firmware - what are we going to do about it? Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2022-04-20 14:40 +0200
Re: Firmware - what are we going to do about it? Steve McIntyre <steve@einval.com> - 2022-04-20 17:50 +0200
Re: Firmware - what are we going to do about it? Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2022-04-20 14:40 +0200
Re: Firmware - what are we going to do about it? Samuel Thibault <sthibault@debian.org> - 2022-04-20 14:50 +0200
Re: Firmware - what are we going to do about it? Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2022-04-20 15:10 +0200
Re: Firmware - what are we going to do about it? Samuel Thibault <sthibault@debian.org> - 2022-04-20 15:20 +0200
Re: Firmware - what are we going to do about it? Jonathan Dowland <jmtd@debian.org> - 2022-04-20 15:40 +0200
Re: Firmware - what are we going to do about it? Devin Prater <r.d.t.prater@gmail.com> - 2022-04-20 17:00 +0200
Re: Firmware - what are we going to do about it? Steve Langasek <vorlon@debian.org> - 2022-04-20 18:40 +0200
Re: Firmware - what are we going to do about it? Devin Prater <r.d.t.prater@gmail.com> - 2022-04-20 20:00 +0200
Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-20 21:20 +0200
Re: Firmware - what are we going to do about it? Steve McIntyre <steve@einval.com> - 2022-04-21 16:00 +0200
Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-20 19:20 +0200
Re: Firmware - what are we going to do about it? Jonathan Dowland <jmtd@debian.org> - 2022-04-20 12:50 +0200
Re: Firmware - what are we going to do about it? Simon Richter <sjr@debian.org> - 2022-04-21 22:10 +0200
Re: Firmware - what are we going to do about it? Russell Stuart <russell-debian@stuart.id.au> - 2022-04-20 13:40 +0200
Re: Firmware - what are we going to do about it? Paul Wise <pabs@debian.org> - 2022-04-20 14:40 +0200
Re: Firmware - what are we going to do about it? Steve McIntyre <steve@einval.com> - 2022-04-20 18:00 +0200
Re: Firmware - what are we going to do about it? Steve Langasek <vorlon@debian.org> - 2022-04-20 21:30 +0200
Re: Firmware - what are we going to do about it? nervuri <nervuri@disroot.org> - 2022-04-20 22:20 +0200
Re: Firmware - what are we going to do about it? Paul Wise <pabs@debian.org> - 2022-04-21 08:00 +0200
Re: Firmware - what are we going to do about it? Hakan Bayındır <hakan.bayindir@tubitak.gov.tr> - 2022-04-21 09:30 +0200
Re: Firmware - what are we going to do about it? Hakan Bayındır <hakan@bayindir.org> - 2022-04-21 10:00 +0200
Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-21 10:20 +0200
Re: Firmware - what are we going to do about it? Hakan Bayındır <hakan@bayindir.org> - 2022-04-21 12:50 +0200
Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-21 18:40 +0200
Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-21 10:00 +0200
Re: Firmware - what are we going to do about it? Russ Allbery <rra@debian.org> - 2022-04-21 19:20 +0200
Re: Firmware - what are we going to do about it? Andreas Tille <andreas@an3as.eu> - 2022-04-22 07:20 +0200
Re: Firmware - what are we going to do about it? Hakan Bayındır <hakan@bayindir.org> - 2022-04-22 08:40 +0200
Re: Firmware - what are we going to do about it? IOhannes m zmölnig <umlaeute@debian.org> - 2022-04-22 09:40 +0200
Re: Firmware - what are we going to do about it? Marc Haber <mh+debian-devel@zugschlus.de> - 2022-04-23 12:20 +0200
Re: Firmware - what are we going to do about it? Thomas Goirand <zigo@debian.org> - 2022-04-21 09:40 +0200
Re: Firmware - what are we going to do about it? Mattias Wadenstein <maswan@acc.umu.se> - 2022-04-21 11:30 +0200
Re: Firmware - what are we going to do about it? Paul Wise <pabs@debian.org> - 2022-04-21 11:50 +0200
Re: Firmware - what are we going to do about it? Hakan Bayındır <hakan@bayindir.org> - 2022-04-21 11:40 +0200
Re: Firmware - what are we going to do about it? Moritz Mühlenhoff <jmm@inutil.org> - 2022-04-21 20:10 +0200
Re: Firmware - what are we going to do about it? Leandro Cunha <leandrocunha016@gmail.com> - 2022-04-22 00:30 +0200
Re: Firmware - what are we going to do about it? Philip Hands <phil@hands.com> - 2022-04-22 11:20 +0200
shim-signed (was: Firmware - what are we going to do about it?) Marc Haber <mh+debian-devel@zugschlus.de> - 2022-04-23 12:30 +0200
Re: shim-signed (was: Firmware - what are we going to do about it?) Ansgar <ansgar@43-1.org> - 2022-04-23 14:00 +0200
Re: shim-signed (was: Firmware - what are we going to do about it?) Marc Haber <mh+debian-devel@zugschlus.de> - 2022-04-26 16:10 +0200
Re: shim-signed (was: Firmware - what are we going to do about it?) Ansgar <ansgar@43-1.org> - 2022-04-26 17:00 +0200
Re: shim-signed (was: Firmware - what are we going to do about it?) Steve McIntyre <steve@einval.com> - 2022-04-23 19:30 +0200
Re: shim-signed (was: Firmware - what are we going to do about it?) Paul Wise <pabs@debian.org> - 2022-04-24 04:40 +0200
Re: shim-signed (was: Firmware - what are we going to do about it?) Marc Haber <mh+debian-devel@zugschlus.de> - 2022-04-26 16:20 +0200
Re: shim-signed (was: Firmware - what are we going to do about it?) Steve McIntyre <steve@einval.com> - 2022-04-26 18:40 +0200
Re: shim-signed (was: Firmware - what are we going to do about it?) Bastian Blank <waldi@debian.org> - 2022-04-26 21:10 +0200
Re: shim-signed (was: Firmware - what are we going to do about it?) Paul Wise <pabs@debian.org> - 2022-04-27 00:10 +0200
Re: shim-signed The Wanderer <wanderer@fastmail.fm> - 2022-04-27 00:40 +0200
Re: shim-signed Steve McIntyre <steve@einval.com> - 2022-04-28 18:20 +0200
Re: shim-signed The Wanderer <wanderer@fastmail.fm> - 2022-04-27 00:40 +0200
Re: shim-signed Tollef Fog Heen <tfheen@err.no> - 2022-04-28 06:30 +0200
Re: shim-signed Steve McIntyre <steve@einval.com> - 2022-04-28 18:30 +0200
Re: shim-signed Tollef Fog Heen <tfheen@err.no> - 2022-04-24 09:00 +0200
Re: shim-signed Hanno 'Rince' Wagner <wagner@debian.org> - 2022-04-24 09:20 +0200
Re: shim-signed Tollef Fog Heen <tfheen@err.no> - 2022-04-28 06:30 +0200
Re: shim-signed Steve McIntyre <steve@einval.com> - 2022-04-28 18:30 +0200
Re: Firmware - what are we going to do about it? Holger Levsen <holger@layer-acht.org> - 2022-04-22 11:50 +0200
Re: Firmware - what are we going to do about it? Paul van der Vlis <paul@vandervlis.nl> - 2022-04-23 15:30 +0200
Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-23 16:10 +0200
Re: Firmware - what are we going to do about it? Paul van der Vlis <paul@vandervlis.nl> - 2022-04-23 23:00 +0200
Re: Firmware - what are we going to do about it? Iustin Pop <iustin@debian.org> - 2022-04-23 23:10 +0200
Re: Firmware - what are we going to do about it? Simon Richter <sjr@debian.org> - 2022-04-24 05:10 +0200
Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-24 09:50 +0200
Re: Firmware - what are we going to do about it? Timothy M Butterworth <timothy.m.butterworth@gmail.com> - 2022-04-23 23:20 +0200
Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-23 23:30 +0200
Re: Firmware - what are we going to do about it? Paul van der Vlis <paul@vandervlis.nl> - 2022-04-25 18:10 +0200
Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-25 18:50 +0200
Re: Firmware - what are we going to do about it? Hakan Bayındır <hakan@bayindir.org> - 2022-04-25 22:50 +0200
Re: Firmware - what are we going to do about it? Ansgar <ansgar@43-1.org> - 2022-04-26 08:20 +0200
Re: Firmware - what are we going to do about it? Hakan Bayındır <hakan@bayindir.org> - 2022-04-26 09:50 +0200
Re: Firmware - what are we going to do about it? Ansgar <ansgar@43-1.org> - 2022-04-26 10:40 +0200
Re: Firmware - what are we going to do about it? Hakan Bayındır <hakan@bayindir.org> - 2022-04-26 11:00 +0200
Re: Firmware - what are we going to do about it? Andrey Rahmatullin <wrar@debian.org> - 2022-04-26 11:10 +0200
Re: Firmware - what are we going to do about it? Hakan Bayındır <hakan@bayindir.org> - 2022-04-26 11:50 +0200
Re: Firmware - what are we going to do about it? Hans <hans.ullrich@loop.de> - 2022-04-26 11:50 +0200
Re: Firmware - what are we going to do about it? Helmut Grohne <helmut@subdivi.de> - 2022-04-30 14:10 +0200
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | Timothy M Butterworth <timothy.m.butterworth@gmail.com> |
|---|---|
| Date | 2022-04-19 18:30 +0200 |
| Message-ID | <EdYTL-9OIi-1@gated-at.bofh.it> |
| In reply to | #104187 |
[Multipart message — attachments visible in raw view] — view raw
> > My laptop requires the non-free binary blobs for WiFi, AMD GPU and HDMI > Sound. I think making the non-free images easier to find is a good idea. I > didn't know they even existed until I got this new laptop and nothing was > working with the regular installer. Placing the non-free and non-free live > images along side with the free installer images would be very nice. > Tim
[toc] | [prev] | [next] | [standalone]
| From | Jonas Smedegaard <jonas@jones.dk> |
|---|---|
| Date | 2022-04-19 19:00 +0200 |
| Message-ID | <EdZmN-9OSv-1@gated-at.bofh.it> |
| In reply to | #104187 |
[Multipart message — attachments visible in raw view] — view raw
Quoting Andrey Rahmatullin (2022-04-19 18:01:10) > 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? I notice that you shift the conversation topic from *upgrading* firmware to *introducing* firmware. I already mentioned that I would sometimes upgrade to newer firmware, which I mean to imply that yes I would sometimes dare to permit my devices to execute firmware. Sorry if that was unclear. My concern is about hardware changing behavior. I.e. hardware not being stable. Sometimes I choose to let my devices be broken (e.g. not load firmware onto a builtin wifi or audio device that I don't really use). Sometimes I choose to let my devices work like they did last year (e.g. not upload newer firmware onto a bluetooth or ethernet device that last year worked fine with its builtin firmware). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
[toc] | [prev] | [next] | [standalone]
| From | Ansgar <ansgar@43-1.org> |
|---|---|
| Date | 2022-04-19 19:10 +0200 |
| Message-ID | <EdZwt-9PaZ-5@gated-at.bofh.it> |
| In reply to | #104189 |
On Tue, 2022-04-19 at 18:51 +0200, Jonas Smedegaard wrote: > I notice that you shift the conversation topic from *upgrading* > firmware to *introducing* firmware. > > I already mentioned that I would sometimes upgrade to newer firmware, > which I mean to imply that yes I would sometimes dare to permit my > devices to execute firmware. Sorry if that was unclear. > > My concern is about hardware changing behavior. I.e. hardware not > being stable. Firmware shipped as packages part of stable releases will probably change the same way as software (i.e., security updates, other important updates). So there should be not much reason for such concern. Such concerns would be more relevant for firmware updates using other update channels such as `fwupd` uses. And there is still the option to not install the firmware packages and managing firmware files on your own, but I do not think this is a good default. Ansgar
[toc] | [prev] | [next] | [standalone]
| From | Andrey Rahmatullin <wrar@debian.org> |
|---|---|
| Date | 2022-04-19 20:00 +0200 |
| Message-ID | <Ee0iR-9Prj-9@gated-at.bofh.it> |
| In reply to | #104189 |
[Multipart message — attachments visible in raw view] — view raw
On Tue, Apr 19, 2022 at 06:51:16PM +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? > > I notice that you shift the conversation topic from *upgrading* firmware > to *introducing* firmware. You partially narrowed the topic to upgrading firmware in <165037188392.1708.14819384411900940205@auryn.jones.dk>, so yes, I'm asking about both sides of the question. I will even say that the situation where some perfectly usable firmware is already available on the device, and Debian just offers an update to it, is much less important (but still very important for e.g. intel-microcode) than the situation where the device is not usable without firmware loaded by Debian, which is the main usability problem with the status quo. -- WBR, wRAR
[toc] | [prev] | [next] | [standalone]
| From | Jonas Smedegaard <jonas@jones.dk> |
|---|---|
| Date | 2022-04-19 23:10 +0200 |
| Message-ID | <Ee3gJ-9RpH-19@gated-at.bofh.it> |
| In reply to | #104194 |
[Multipart message — attachments visible in raw view] — view raw
Quoting Andrey Rahmatullin (2022-04-19 19:49:59) > On Tue, Apr 19, 2022 at 06:51:16PM +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? > > > > I notice that you shift the conversation topic from *upgrading* > > firmware to *introducing* firmware. > You partially narrowed the topic to upgrading firmware in > <165037188392.1708.14819384411900940205@auryn.jones.dk>, so yes, I'm > asking about both sides of the question. I will even say that the > situation where some perfectly usable firmware is already available on > the device, and Debian just offers an update to it, is much less > important (but still very important for e.g. intel-microcode) than the > situation where the device is not usable without firmware loaded by > Debian, which is the main usability problem with the status quo. Ah, so your view is that newer blob might... * fix bugs * add functionality that I want I can understand how in such a World there is no sense in avoiding newer blobs: They are only ever improvements. We do not share that view, though. Quoting Ansgar (2022-04-19 19:04:36) > Firmware shipped as packages part of stable releases will probably > change the same way as software (i.e., security updates, other > important updates). So there should be not much reason for such > concern. > > Such concerns would be more relevant for firmware updates using other > update channels such as `fwupd` uses. I wonder how you can confidently know that non-free blobs packages for Debian are only likely to be improvements, when you cannot verify their contents. And how is it that fwupd distributed blobs are less likely to be reliable. What am I missing here? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
[toc] | [prev] | [next] | [standalone]
| From | Ansgar <ansgar@43-1.org> |
|---|---|
| Date | 2022-04-20 08:10 +0200 |
| Message-ID | <EebHj-9WsC-11@gated-at.bofh.it> |
| In reply to | #104200 |
On Tue, 2022-04-19 at 23:00 +0200, Jonas Smedegaard wrote:
> Quoting Ansgar (2022-04-19 19:04:36)
> > Firmware shipped as packages part of stable releases will probably
> > change the same way as software (i.e., security updates, other
> > important updates). So there should be not much reason for such
> > concern.
> >
> > Such concerns would be more relevant for firmware updates using
> > other
> > update channels such as `fwupd` uses.
>
> I wonder how you can confidently know that non-free blobs packages
> for Debian are only likely to be improvements, when you cannot
> verify their contents.
I did not say that.
It was a reply to "My concern is about hardware changing behavior", but
you are shifting the conversation topic to something different (reverse
engineering firmware or other things to know it only includes
improvements[1]) now?
If you care about "hardware changing behavior" due to firmware updates,
feel free to check how many firmware updates stable gets.
[1]: And not also sometimes regressions like Debian's regular
security or other stable updates. Or behavior changes between
different Firefox ESR releases.
> And how is it that fwupd distributed blobs are less likely to be
> reliable. What am I missing here?
I did not say that.
It was still a reply to the same topic as above.
Ansgar
[toc] | [prev] | [next] | [standalone]
| From | Andrey Rahmatullin <wrar@debian.org> |
|---|---|
| Date | 2022-04-20 08:20 +0200 |
| Message-ID | <EebQZ-9WvD-3@gated-at.bofh.it> |
| In reply to | #104200 |
[Multipart message — attachments visible in raw view] — view raw
On Tue, Apr 19, 2022 at 11:00:23PM +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? > > > > > > I notice that you shift the conversation topic from *upgrading* > > > firmware to *introducing* firmware. > > You partially narrowed the topic to upgrading firmware in > > <165037188392.1708.14819384411900940205@auryn.jones.dk>, so yes, I'm > > asking about both sides of the question. I will even say that the > > situation where some perfectly usable firmware is already available on > > the device, and Debian just offers an update to it, is much less > > important (but still very important for e.g. intel-microcode) than the > > situation where the device is not usable without firmware loaded by > > Debian, which is the main usability problem with the status quo. > > Ah, so your view is that newer blob might... I thought I shifted the conversation topic from *upgrading* firmware to *introducing* firmware? I even called this situation "much less important" than the other one. -- WBR, wRAR
[toc] | [prev] | [next] | [standalone]
| From | Tim Woodall <debiandevel@woodall.me.uk> |
|---|---|
| Date | 2022-04-19 19:00 +0200 |
| Message-ID | <EdZmP-9OSv-13@gated-at.bofh.it> |
| In reply to | #104187 |
On Tue, 19 Apr 2022, Andrey Rahmatullin wrote: > 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? > No, of course not. But I wouldn't upgrade the firmware by default any more than I upgrade the firmware of my radio-alarm clock by default. I upgraded the alarm clock _once_ because it had the new (wanted) feature of being able to set three differently timed alarms rather than the two that it had out of the box but since then I've never even looked to see if there's an upgrade available. Even if someone discovered a security threat that allowed a rogue actor to broadcast a signal to it that turned it on at full volume I still wouldn't bother to upgrade it unless someone actually started doing that in my neighbourhood. (not that the manufacturer would provide an update anyway now) And I cannot buy the same model any more. Subsequent models have the "feature" that in the event of a power failure the radio turns on when power is restored, great, I really wanted to be woken up at 2am to be told that the powercut I didn't know about is over, it has the "feature" that it only sets the time while the radio is actually on, so the first alarm after the clocks change is an hour wrong. (I have no idea whether upgrading the firmware of the one that works the way I want will cause it to adopt the "new, improved" behaviour and I have no intention of finding out.) Those are the sorts of "upgrades" that you'll inadvertently pick up with closed source firemware upgrades. Most of these devices, like my automatic sheet feed scanner, have no credible threat to running "out of date" firmware and unlikely to benefit from an upgrade unless you either hit a known issue or happen to hit an issue that the manufacturer is willing to fix after you report it. Tim.
[toc] | [prev] | [next] | [standalone]
| From | Russ Allbery <rra@debian.org> |
|---|---|
| Date | 2022-04-19 19:30 +0200 |
| Message-ID | <EdZPQ-9Phv-5@gated-at.bofh.it> |
| In reply to | #104180 |
Jonas Smedegaard <jonas@jones.dk> writes: > Now, some may argue that I am describing a case for package pinning > here, and that *might* be true but I don't know that yet - because the > proposed change to the system does not exist yet so I cannot really know > that yet. Possibly the implementation will be so that I continuously > need to check if some new non-free blobs was introduced and block those, > instead of the current situation of not needing to do anything actively > to keeping most possible risky "stuff" away from my systems. I feel like Debian already offers multiple mechanisms to prevent installation or updates of packages, both specific packages and packages by suite, archive, etc. I'm dubious that we need some additional extra-special mechanism just for firmware, as opposed to documenting the many and varied mechanisms we already support for pinning old packages, disabling automated upgrades, and so forth. We need some way to clearly label non-free firmware packages so that you can apply whatever installation or upgrade policy locally that you want to apply, but solution #5 provides that by keeping the non-free firmware in a separate archive area (which apt calls "components") to which you can apply different apt policy. Given your problem description above where you want to manually review each new non-free package, I suspect you will want to pin the non-free firmware archive area to something like priority 1 (similar to experimental) so that you can access those packages but they're not otherwise installed or upgraded. Another option would be priority 100, which would give automatic upgrades but not new installs. I'm assuming we'll continue to maintain the invariant that free packages won't depend on non-free packages, so unless you install a non-free metapackage, you presumably won't get new non-free firmware packages without seeking them out. We may want to install such a metapackage by default when the non-free-firmware-enabled installer is used (leaving open the question of whether that's the only installer or not), but you could remove it, of course. (I suspect you, like me and probably most other Debian contributors, make pretty extensive modifications to the installed package list after installing a new system, and have lists of packages that you always add or always remove.) -- Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
[toc] | [prev] | [next] | [standalone]
| From | Jonas Smedegaard <jonas@jones.dk> |
|---|---|
| Date | 2022-04-19 23:40 +0200 |
| Message-ID | <Ee3JL-9Rzb-1@gated-at.bofh.it> |
| In reply to | #104193 |
[Multipart message — attachments visible in raw view] — view raw
Quoting Russ Allbery (2022-04-19 19:29:09) > Jonas Smedegaard <jonas@jones.dk> writes: > > > Now, some may argue that I am describing a case for package pinning > > here, and that *might* be true but I don't know that yet - because > > the proposed change to the system does not exist yet so I cannot > > really know that yet. Possibly the implementation will be so that I > > continuously need to check if some new non-free blobs was introduced > > and block those, instead of the current situation of not needing to > > do anything actively to keeping most possible risky "stuff" away > > from my systems. > > I feel like Debian already offers multiple mechanisms to prevent > installation or updates of packages, both specific packages and > packages by suite, archive, etc. I'm dubious that we need some > additional extra-special mechanism just for firmware, as opposed to > documenting the many and varied mechanisms we already support for > pinning old packages, disabling automated upgrades, and so forth. > > We need some way to clearly label non-free firmware packages so that > you can apply whatever installation or upgrade policy locally that you > want to apply, but solution #5 provides that by keeping the non-free > firmware in a separate archive area (which apt calls "components") to > which you can apply different apt policy. The issue I have with option 5 is that non-free blobs are then enabled by default. Yes, I can then block it, just as I can block other parts of Debian. Difference is that non-free blobs are (generally) bkack magic that I need to trust blindfolded, whereas Debian as it exists today I can (hire someone clever to) verify what it does. I agree that we should make it easier for our users to choose to trust black magic "stuff" that they need to enable their devices. I do not think that we should impose on our users to trust black magic by default, though. I think that all non-free code distributed by Debian (be that code executed on the main CPU, and code uploaded to external devices, and code served to other people's web browsers) should be easy to use but opt-in, not (some of it) opt-out. Because we cannot reasonably know what it realy does and therefore not reasonably decide if sensible to trust or not. We can only blindly assume that "newer is better". - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
[toc] | [prev] | [next] | [standalone]
| From | Russ Allbery <rra@debian.org> |
|---|---|
| Date | 2022-04-20 00:00 +0200 |
| Message-ID | <Ee438-9RGC-5@gated-at.bofh.it> |
| In reply to | #104201 |
Jonas Smedegaard <jonas@jones.dk> writes: > Quoting Russ Allbery (2022-04-19 19:29:09) >> We need some way to clearly label non-free firmware packages so that >> you can apply whatever installation or upgrade policy locally that you >> want to apply, but solution #5 provides that by keeping the non-free >> firmware in a separate archive area (which apt calls "components") to >> which you can apply different apt policy. > The issue I have with option 5 is that non-free blobs are then enabled > by default. I just re-read option 5 and I don't see where it says that. My understanding of the proposal is that the firmware would be on the image and thus available to the installer. That doesn't imply that it will be automatically enabled, either in the installer or on the installed system. That could still be gated by a prompt. In other words, rather than having to do what one does now and choose between the free installer and the non-free installer, my understanding of option #5 is that there would be one install image, but there could then be a prompt asking you whether you want to install non-free firmware. We could even offer a few different options (with the caveat that options tend to confuse users, so we may not want to add too many or gate them behind an advanced mode): 1. Purely free installation. 2. Enable non-free firmware in the installer but don't put it on the installed system. (Not sure how useful this is, but I could see needing non-free firmware to bootstrap from wifi but the running system may eventually not use the non-free firmware.) 3. Enable non-free firmware and install it on the system but pin it so that it's never upgraded by default. 4. Enable non-free firmware and enable normal upgrades, similar to adding the non-free archive area today but only adding the firmware archive area. I think 1 and 4 are the most useful options, and I'm not sure how many people really want 2 or 3, but if there are enough people who want them, I don't see any technical barriers to adding them. I feel professionally obligated to argue that Debian should, *by default*, upgrade anything that it installs, since from a security standpoint that is the least risky default configuration (with, as always, the caveat that there are special cases with different security models for which this default isn't appropriate). But that doesn't rule out a prompt or allowing a user to turn this off if they want to. > I agree that we should make it easier for our users to choose to trust > black magic "stuff" that they need to enable their devices. > I do not think that we should impose on our users to trust black magic > by default, though. I think this is a somewhat different question than whether we put the firmware on the default installation media so that it's *available* if users want it. -- Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
[toc] | [prev] | [next] | [standalone]
| From | Jonas Smedegaard <jonas@jones.dk> |
|---|---|
| Date | 2022-04-20 11:10 +0200 |
| Message-ID | <Eeevv-9Y7x-1@gated-at.bofh.it> |
| In reply to | #104202 |
[Multipart message — attachments visible in raw view] — view raw
Quoting Russ Allbery (2022-04-19 23:57:21) > Jonas Smedegaard <jonas@jones.dk> writes: > > Quoting Russ Allbery (2022-04-19 19:29:09) > > >> We need some way to clearly label non-free firmware packages so > >> that you can apply whatever installation or upgrade policy locally > >> that you want to apply, but solution #5 provides that by keeping > >> the non-free firmware in a separate archive area (which apt calls > >> "components") to which you can apply different apt policy. > > > The issue I have with option 5 is that non-free blobs are then > > enabled by default. > > I just re-read option 5 and I don't see where it says that. My > understanding of the proposal is that the firmware would be on the > image and thus available to the installer. That doesn't imply that it > will be automatically enabled, either in the installer or on the > installed system. That could still be gated by a prompt. Oh. Re-reading again myself, and I agree. Sorry for all the noise: I support option 5. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
[toc] | [prev] | [next] | [standalone]
| From | Steve McIntyre <steve@einval.com> |
|---|---|
| Date | 2022-04-20 18:20 +0200 |
| Message-ID | <EeldD-a2da-5@gated-at.bofh.it> |
| In reply to | #104202 |
Russ Allbery wrote: >Jonas Smedegaard <jonas@jones.dk> writes: > >In other words, rather than having to do what one does now and choose >between the free installer and the non-free installer, my understanding of >option #5 is that there would be one install image, but there could then >be a prompt asking you whether you want to install non-free firmware. We >could even offer a few different options (with the caveat that options >tend to confuse users, so we may not want to add too many or gate them >behind an advanced mode): > >1. Purely free installation. >2. Enable non-free firmware in the installer but don't put it on the > installed system. (Not sure how useful this is, but I could see > needing non-free firmware to bootstrap from wifi but the running system > may eventually not use the non-free firmware.) >3. Enable non-free firmware and install it on the system but pin it so > that it's never upgraded by default. >4. Enable non-free firmware and enable normal upgrades, similar to adding > the non-free archive area today but only adding the firmware archive > area. > >I think 1 and 4 are the most useful options, and I'm not sure how many >people really want 2 or 3, but if there are enough people who want them, I >don't see any technical barriers to adding them. Nod, exactly. We can add those options via boot flags and menu options, with later d-i screens too to allow the choice (maybe in advanced mode). That's probably the easiest way to manage it. Now, the *default* is going to be the hard choice for us to make. With the example of blind people using d-i, we'll want to make an easy option for those people to boot the installer with all firmware enabled and installed - see the firmware-sof-signed package that they'll need to get audio prompts during installation. >I feel professionally obligated to argue that Debian should, *by default*, >upgrade anything that it installs, since from a security standpoint that >is the least risky default configuration (with, as always, the caveat that >there are special cases with different security models for which this >default isn't appropriate). But that doesn't rule out a prompt or >allowing a user to turn this off if they want to. Yup. >> I agree that we should make it easier for our users to choose to trust >> black magic "stuff" that they need to enable their devices. > >> I do not think that we should impose on our users to trust black magic >> by default, though. > >I think this is a somewhat different question than whether we put the >firmware on the default installation media so that it's *available* if >users want it. Nod. -- Steve McIntyre, Cambridge, UK. steve@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
[toc] | [prev] | [next] | [standalone]
| From | Ansgar <ansgar@43-1.org> |
|---|---|
| Date | 2022-04-20 18:30 +0200 |
| Message-ID | <Eelnj-a2gh-1@gated-at.bofh.it> |
| In reply to | #104242 |
Hi Steve, On Wed, 2022-04-20 at 17:11 +0100, Steve McIntyre wrote: > > Russ Allbery wrote: > > 1. Purely free installation. [ Other options ] > > 4. Enable non-free firmware and enable normal upgrades, [...] [...] > Now, the *default* is going to be the hard choice for us to make. Do you think the choice for the default should be part of a GR too, a separate GR or decided some other way? Ansgar
[toc] | [prev] | [next] | [standalone]
| From | Steve McIntyre <steve@einval.com> |
|---|---|
| Date | 2022-04-20 18:50 +0200 |
| Message-ID | <EelGF-a2mW-1@gated-at.bofh.it> |
| In reply to | #104243 |
Hey Ansgar! Ansgar wrote: >On Wed, 2022-04-20 at 17:11 +0100, Steve McIntyre wrote: >> > Russ Allbery wrote: >> > 1. Purely free installation. >[ Other options ] >> > 4. Enable non-free firmware and enable normal upgrades, [...] >[...] >> Now, the *default* is going to be the hard choice for us to make. > >Do you think the choice for the default should be part of a GR too, a >separate GR or decided some other way? Thanks! That's a really good question, and one that we should also include on the GR. I'd split my option 5 into two: 5. Include non-free firmware but do not enable it by default 6. Include non-free firmware and enable it by default In either case, we'd make the opposite choice available via a d-i kernel command line option and a boot menu option. I think that makes sense? -- Steve McIntyre, Cambridge, UK. steve@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
[toc] | [prev] | [next] | [standalone]
| From | Russ Allbery <rra@debian.org> |
|---|---|
| Date | 2022-04-20 20:00 +0200 |
| Message-ID | <EemMq-a2YG-3@gated-at.bofh.it> |
| In reply to | #104245 |
Steve McIntyre <steve@einval.com> writes: > Thanks! That's a really good question, and one that we should also > include on the GR. I'd split my option 5 into two: > 5. Include non-free firmware but do not enable it by default > 6. Include non-free firmware and enable it by default > In either case, we'd make the opposite choice available via a d-i kernel > command line option and a boot menu option. I think that makes sense? I agree with this option split, but that reminds me of a different procedural note. While I recognize and respect the desire to create a comprehensive ballot, I'm still going to advocate for proposing a GR only with the options that the person proposing the GR would vote above NOTA, and possibly only your preferred options. There are a couple of reasons for this. One is that the people who prefer your disfavored options may have their own way of wording them that's slightly different than what you might believe they would want to say, and it's awkward to update other people's ballot options. The other, somewhat more technical reason is that I expect this GR to require a 3:1 majority for some options, and mixing 3:1 and 1:1 majority options on the same GR can be rather confusing. We may end up needing to do that anyway for this vote, but I think it would be a good idea to avoid creating the problem unless someone steps forward and proposes a 1:1 option that they really want to win. (That said, I think there's a big exception, which is that if you've canvassed a bunch of people who may not want to try to craft their own ballot options, and developed options to reflect their views, I think that's a fine approach and a good reason to propose options that aren't your personal preference.) As a side note, I don't remember exactly how this worked before, but under the current constitutional rules the original GR proposer doesn't have a special ability to put a bunch of options on the original ballot. You start with one option, and then you can add more options but they all need to be sponsored independently. So that also pushes in this direction of ballot construction. -- Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
[toc] | [prev] | [next] | [standalone]
| From | Sam Hartman <hartmans@debian.org> |
|---|---|
| Date | 2022-04-21 02:10 +0200 |
| Message-ID | <Eesyt-a6EP-7@gated-at.bofh.it> |
| In reply to | #104248 |
>>>>> "Russ" == Russ Allbery <rra@debian.org> writes:
Russ> I agree with this option split, but that reminds me of a
Russ> different procedural note.
Russ> While I recognize and respect the desire to create a
Russ> comprehensive ballot, I'm still going to advocate for
Russ> proposing a GR only with the options that the person proposing
Russ> the GR would vote above NOTA, and possibly only your preferred
Russ> options.
I agree with Russ in this instance, which may b surprising to some given
how I approached the systemd GR.
I think that we will likely find people to sponsor something close to
all of Steve's options.
And I think that allowing those people to craft the wording of those
options will give them the best chance of winning.
Russ> (That said, I think there's a big exception, which is that if
Russ> you've canvassed a bunch of people who may not want to try to
Russ> craft their own ballot options, and developed options to
Russ> reflect their views, I think that's a fine approach and a good
Russ> reason to propose options that aren't your personal
Russ> preference.)
I also agree with this exception.
[toc] | [prev] | [next] | [standalone]
| From | Steve McIntyre <steve@einval.com> |
|---|---|
| Date | 2022-04-21 15:50 +0200 |
| Message-ID | <EeFm2-aepD-15@gated-at.bofh.it> |
| In reply to | #104248 |
Russ Allbery wrote: >Steve McIntyre <steve@einval.com> writes: > >> Thanks! That's a really good question, and one that we should also >> include on the GR. I'd split my option 5 into two: > >> 5. Include non-free firmware but do not enable it by default >> 6. Include non-free firmware and enable it by default > >> In either case, we'd make the opposite choice available via a d-i kernel >> command line option and a boot menu option. I think that makes sense? > >I agree with this option split, but that reminds me of a different >procedural note. > >While I recognize and respect the desire to create a comprehensive ballot, >I'm still going to advocate for proposing a GR only with the options that >the person proposing the GR would vote above NOTA, and possibly only your >preferred options. ACK, that's fair and reasonable. -- Steve McIntyre, Cambridge, UK. steve@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
[toc] | [prev] | [next] | [standalone]
| From | Holger Levsen <holger@layer-acht.org> |
|---|---|
| Date | 2022-04-22 12:00 +0200 |
| Subject | writing good GR ballots (Re: Firmware - what are we going to do about it?) |
| Message-ID | <EeYeZ-apx4-1@gated-at.bofh.it> |
| In reply to | #104248 |
[Multipart message — attachments visible in raw view] — view raw
On Wed, Apr 20, 2022 at 10:52:04AM -0700, Russ Allbery wrote: > I agree with this option split, but that reminds me of a different > procedural note. > > While I recognize and respect the desire to create a comprehensive ballot, > I'm still going to advocate for proposing a GR only with the options that > the person proposing the GR would vote above NOTA, and possibly only your > preferred options. > > There are a couple of reasons for this. One is that the people who prefer > your disfavored options may have their own way of wording them that's > slightly different than what you might believe they would want to say, and > it's awkward to update other people's ballot options. The other, somewhat > more technical reason is that I expect this GR to require a 3:1 majority > for some options, and mixing 3:1 and 1:1 majority options on the same GR > can be rather confusing. We may end up needing to do that anyway for this > vote, but I think it would be a good idea to avoid creating the problem > unless someone steps forward and proposes a 1:1 option that they really > want to win. > > (That said, I think there's a big exception, which is that if you've > canvassed a bunch of people who may not want to try to craft their own > ballot options, and developed options to reflect their views, I think > that's a fine approach and a good reason to propose options that aren't > your personal preference.) > > As a side note, I don't remember exactly how this worked before, but under > the current constitutional rules the original GR proposer doesn't have a > special ability to put a bunch of options on the original ballot. You > start with one option, and then you can add more options but they all need > to be sponsored independently. So that also pushes in this direction of > ballot construction. would it make sense to document this (and more) somewhere as 'guidelines for writting good GR ballots' or some such? I'd guess the wiki would be a good starting point or maybe somewhere else? does this exist already -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The entire society has no clue what the word freedom means in the context of relating to the world around them. It has degenerated into "my ego first". It is why the entire planet is dying right now.
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2022-04-20 00:30 +0200 |
| Message-ID | <Ee4wa-9S5O-7@gated-at.bofh.it> |
| In reply to | #104201 |
[Multipart message — attachments visible in raw view] — view raw
On Tue, 2022-04-19 at 23:33 +0200, Jonas Smedegaard wrote: > I do not think that we should impose on our users to trust black magic > by default, though. > > I think that all non-free code distributed by Debian (be that code > executed on the main CPU, and code uploaded to external devices, and > code served to other people's web browsers) should be easy to use but > opt-in, not (some of it) opt-out. Because we cannot reasonably know > what it realy does and therefore not reasonably decide if sensible to > trust or not. We can only blindly assume that "newer is better". It's firmware. If you have an x86 CPU there's no opting in or opting out, you and every one Debian user are using non-free microcode, whether you like it or not. The only difference is whether it's an old version, vulnerable to known and exploited security bugs, or not. Pretending it doesn't exist won't make it go away, won't make a machine "free", and won't help any cause. It's simply pushing the problems away from the distribution maintainers down to the users, and we know for a fact they are very real and very tangible problems. We know that newer is better: CVE numbers are there to prove it. You can't reasonably "know" what your hardware does anyway, unless you've got a degree in electronic engineering, industrial acid, an electron microscope and a whole lot of spare time. As mentioned earlier, modern machines are networks of hundreds of components, most if not all of which is proprietary hardware. You have to blindly trust it. The act of running a given machine _is_ the opt-in to trust that hardware and all its various firmwares, some of which happen to be updatable (which is a good thing). -- Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | linux.debian.devel
csiph-web