Re: Firmware - what are we going to do about it?

[Marc Haber]

On Wed, 1 Jun 2022 15:21:01 +, "Andrew M.A. Cater"
 wrote:
>Basic tasks include networking - many IBM and Dell servers use(d) Broadcom
>chipsets which wouldn't work without a non-free driver. Been caught out like
>that installing in a data centre: can't get networking to work to get the 
>drivers I need for the network card.

PXE boot will work and load a kernel and a doctored initrd that
contains the non-free firmware. Been there, done that, for thousands
of machines.

It would be so nice if Debian would offer such an initrd out of the
box.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Firmware - what are we going to do about it?

[Andrew M.A. Cater]

Hi Hakan,

On Wed, Jun 01, 2022 at 09:41:35AM +0300, Hakan Bayındır wrote:
> 
> 
> On 30.05.2022 09:36, Andrey Rahmatullin wrote:
> > On Sun, May 29, 2022 at 05:33:21PM -0400, Bobby wrote:
> > > There are definitely people who use forks because it's easier to
> > > install non-free firmware. What's the problem with that? Let them use
> > > forks. A distro can't be all things to all people.
> > This would mean almost officially dropping support for user computers and,
> > as I've heard, many of the servers. It's certainly possible but I'm afraid
> > this will lead to even fewer new contributors to Debian.
> 
> As a person who's handling a lot of servers, I can tell that most high
> performance hardware is running either load-on-boot (generally ethernet and
> other network cards) or persistent (generally storage and RAID contollers)
> non-free firmware blobs.
> 
> First category can perform basic tasks without firmware, but servers being
> servers, this low performance mode is undesirable barring light-load servers
> which is both a minority and a contradiction to the word server in my
> profession.
> 
Basic tasks include networking - many IBM and Dell servers use(d) Broadcom
chipsets which wouldn't work without a non-free driver. Been caught out like
that installing in a data centre: can't get networking to work to get the 
drivers I need for the network card.

> Also, this persistent firmware is meant to be updated throughout the life of
> the hardware (5-10 years in normal cases). This is why there's fwupd which
> can manage this upgrade process very elegantly.
> 
If you're unlucky, you may find that support just isn't there any more -
some MegaRAID / LSI cards :(

> > > Debian is unique in this area, and it would be a shame to sacrifice that
> > > and make it just like all the rest. And it's unclear what benefit there
> > > is to attracting a larger and larger userbase as a bottom-line. It is
> > > not a commercial project, so they will not be paying customers. The
> > > best-case scenario is that people are attracted to making contributions
> > > or becoming more interested in free software, which I thought was the
> > > main goal. So if that isn't prioritized, what's the point?
> > I'm afraid that not providing hardware support is not the same as
> > prioritizing free software, or even free hardware.
> 
> While I proposed a different way for supporting this binary blobs and
> defended it rather strongly in this mailing list, I'd love to see Debian
> support more hardware.
> 
> On the other hand, I still hold the view that inclusion of this firmware
> should be in line with the due-diligence Debian is famous for. i.e. Labeling
> non-free firmware correctly, and giving the user freedom to not install
> them, even if this cripples the target hardware in question.
> 
> Cheers,
> 
> Hakan
> 

All the very best, as ever,

Andy Cater

Re: Firmware - what are we going to do about it?

[Hakan Bayındır]

On 1.06.2022 14:33, Marc Haber wrote:

On Wed, 1 Jun 2022 09:41:35 +0300, Hakan Bay?nd?r 
wrote:

As a person who's handling a lot of servers, I can tell that most high
performance hardware is running either load-on-boot (generally ethernet
and other network cards) or persistent (generally storage and RAID
contollers) non-free firmware blobs.

First category can perform basic tasks without firmware, but servers
being servers, this low performance mode is undesirable barring
light-load servers which is both a minority and a contradiction to the
word server in my profession.


A machine that can boot and install debian without needing the
firmware blob is already one step better than a machine that needs an
install medium with firmware.


You're indeed right. On the other hand, No server I touched ever refused 
to boot w/o any firmware blobs on the install medium. IOW, servers can 
boot current Debian as is, but linux-firmware-non-free contains some 
performance enhancing and useful blobs for them post installation.


Persistent firmware comes loaded out of the box already (like the old days).

Cheers,

Hakan



Greetings
Marc

Re: Firmware - what are we going to do about it?

[Marc Haber]

On Wed, 1 Jun 2022 09:41:35 +0300, Hakan Bay?nd?r 
wrote:
>As a person who's handling a lot of servers, I can tell that most high 
>performance hardware is running either load-on-boot (generally ethernet 
>and other network cards) or persistent (generally storage and RAID 
>contollers) non-free firmware blobs.
>
>First category can perform basic tasks without firmware, but servers 
>being servers, this low performance mode is undesirable barring 
>light-load servers which is both a minority and a contradiction to the 
>word server in my profession.

A machine that can boot and install debian without needing the
firmware blob is already one step better than a machine that needs an
install medium with firmware.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Firmware - what are we going to do about it?

[Hakan Bayındır]

On 30.05.2022 09:36, Andrey Rahmatullin wrote:

On Sun, May 29, 2022 at 05:33:21PM -0400, Bobby wrote:

There are definitely people who use forks because it's easier to
install non-free firmware. What's the problem with that? Let them use
forks. A distro can't be all things to all people.

This would mean almost officially dropping support for user computers and,
as I've heard, many of the servers. It's certainly possible but I'm afraid
this will lead to even fewer new contributors to Debian.


As a person who's handling a lot of servers, I can tell that most high 
performance hardware is running either load-on-boot (generally ethernet 
and other network cards) or persistent (generally storage and RAID 
contollers) non-free firmware blobs.


First category can perform basic tasks without firmware, but servers 
being servers, this low performance mode is undesirable barring 
light-load servers which is both a minority and a contradiction to the 
word server in my profession.


Also, this persistent firmware is meant to be updated throughout the 
life of the hardware (5-10 years in normal cases). This is why there's 
fwupd which can manage this upgrade process very elegantly.



Debian is unique in this area, and it would be a shame to sacrifice that
and make it just like all the rest. And it's unclear what benefit there
is to attracting a larger and larger userbase as a bottom-line. It is
not a commercial project, so they will not be paying customers. The
best-case scenario is that people are attracted to making contributions
or becoming more interested in free software, which I thought was the
main goal. So if that isn't prioritized, what's the point?

I'm afraid that not providing hardware support is not the same as
prioritizing free software, or even free hardware.


While I proposed a different way for supporting this binary blobs and 
defended it rather strongly in this mailing list, I'd love to see Debian 
support more hardware.


On the other hand, I still hold the view that inclusion of this firmware 
should be in line with the due-diligence Debian is famous for. i.e. 
Labeling non-free firmware correctly, and giving the user freedom to not 
install them, even if this cripples the target hardware in question.


Cheers,

Hakan

Re: Firmware - what are we going to do about it?

[Andrey Rahmatullin]

On Sun, May 29, 2022 at 05:33:21PM -0400, Bobby wrote:
> There are definitely people who use forks because it's easier to
> install non-free firmware. What's the problem with that? Let them use
> forks. A distro can't be all things to all people. 
This would mean almost officially dropping support for user computers and,
as I've heard, many of the servers. It's certainly possible but I'm afraid
this will lead to even fewer new contributors to Debian.

> Debian is unique in this area, and it would be a shame to sacrifice that
> and make it just like all the rest. And it's unclear what benefit there
> is to attracting a larger and larger userbase as a bottom-line. It is
> not a commercial project, so they will not be paying customers. The
> best-case scenario is that people are attracted to making contributions
> or becoming more interested in free software, which I thought was the
> main goal. So if that isn't prioritized, what's the point?
I'm afraid that not providing hardware support is not the same as
prioritizing free software, or even free hardware. 

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Timothy Butterworth]

On May 29, 2022, at 6:40 PM, Theodore Ts'o  wrote:

>On Sun, May 29, 2022 at 05:33:21PM -0400, Bobby wrote: > FWIW, as a 10+ years 
>user (first time caller :p) I strongly support > sticking with the status quo. 
>There are plenty of systems that don't > require firmware to work, and often 
>when people say it doesn't "work" > they really mean that its functionality is 
>more limited. Unfortunately, that's not true. Without the firmware, in many 
>cases on modern laptops (for example, the Samsung Galaxy Book 360) the WiFi 
>and Ethernet devices will simply *not* *work*. If the user has only downloaded 
>the Netinst installer onto a USB stick (since most modern laptops also don't 
>have DVD drives), they will not be able to install their system. This is a 
>rather negative user experience. > Further, there are security concerns with 
>blobs. Yes, we can get > microcode updates, but were those updates themselves 
>actually audited? > As far as I know, they are just as opaque as the code 
>they're > replacing. They could be making security worse, and we won't know > 
>until someone finds the exploits. The rare event where a microcode > update is 
>released and it increases security is far outweighed by the > vast majority of 
>the situations where installing opaque code is > detrimental to security. On 
>many modern peripherals, the microcode updates are digitally signed by the 
>manufacturer. So if you didn't trust, say, the CPU updated microcode for your 
>Intel processor, why are you trusting the original CPU microcode, which would 
>have also come from Intel? > If people are unhappy with the status quo, my 
>proposal would be to > encourage more people to work on free alternatives. 
>There is an ocean > of possibilities here, from open hardware to reverse 
>engineering. My > feeling is that a lot more could be done to better support 
>hardware > that doesn't involve non-free code at all. There are many free > 
>projects that have never made it to Debian. Unfortunately, if you want a 
>modern laptop, which supports the latest WiFi standards, and which is thin and 
>light, you're not going to find one which is using purely free alternatives. 
>100% free laptop alternatives do exist, but typically you will end up are 
>using ten year old hardware, or the devices are significantly heavier and more 
>cumbersome. And unfortunately, open hardware is signficantly more difficult 
>and requires far more capital outlay than "open software". Simply encouraging 
>more people to work on free alternatives is not going to be enough unless 
>someone is willing bankroll these efforts to the tunes of millions of dollars. 
>If people want to use really awful, old hardware, all in the name of "free 
>software", they should certainly have the freedom to do so, and it should be 
>easy for them to make sure that the purity of their system is not compromised. 
>However, if someone has already purchased the hardware, it's rather horrible 
>user experience when they discover that Debian won't install a working system 
>on it, and to find the that the the non-free firmware in a locked filing 
>cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of 
>the leopard'. Remember, the Debian Social Contract says that our priorities 
>are our users *and* free software. Making it nearly impossible for a novice 
>user to install Debian on their brand new laptop where Windows 10 and Ubuntu 
>just *works* might not be the best way of balancing the competing needs here 
>of the users and free software. Best regards, - Ted 

I personally need the non-free firmware and would like the non-free installer 
to be easy to locate. 

Re: Firmware - what are we going to do about it?

[Theodore Ts'o]

On Sun, May 29, 2022 at 05:33:21PM -0400, Bobby wrote:
> FWIW, as a 10+ years user (first time caller :p) I strongly support
> sticking with the status quo. There are plenty of systems that don't
> require firmware to work, and often when people say it doesn't "work"
> they really mean that its functionality is more limited.

Unfortunately, that's not true.  Without the firmware, in many cases
on modern laptops (for example, the Samsung Galaxy Book 360) the WiFi
and Ethernet devices will simply *not* *work*.  If the user has only
downloaded the Netinst installer onto a USB stick (since most modern
laptops also don't have DVD drives), they will not be able to install
their system.

This is a rather negative user experience.

> Further, there are security concerns with blobs. Yes, we can get
> microcode updates, but were those updates themselves actually audited?
> As far as I know, they are just as opaque as the code they're
> replacing. They could be making security worse, and we won't know
> until someone finds the exploits. The rare event where a microcode
> update is released and it increases security is far outweighed by the
> vast majority of the situations where installing opaque code is
> detrimental to security.

On many modern peripherals, the microcode updates are digitally signed
by the manufacturer.  So if you didn't trust, say, the CPU updated
microcode for your Intel processor, why are you trusting the original
CPU microcode, which would have also come from Intel?

> If people are unhappy with the status quo, my proposal would be to
> encourage more people to work on free alternatives. There is an ocean
> of possibilities here, from open hardware to reverse engineering. My
> feeling is that a lot more could be done to better support hardware
> that doesn't involve non-free code at all. There are many free
> projects that have never made it to Debian.

Unfortunately, if you want a modern laptop, which supports the latest
WiFi standards, and which is thin and light, you're not going to find
one which is using purely free alternatives.  100% free laptop
alternatives do exist, but typically you will end up are using ten
year old hardware, or the devices are significantly heavier and more
cumbersome.

And unfortunately, open hardware is signficantly more difficult and
requires far more capital outlay than "open software".  Simply
encouraging more people to work on free alternatives is not going to
be enough unless someone is willing bankroll these efforts to the
tunes of millions of dollars.

If people want to use really awful, old hardware, all in the name of
"free software", they should certainly have the freedom to do so, and
it should be easy for them to make sure that the purity of their
system is not compromised.

However, if someone has already purchased the hardware, it's rather
horrible user experience when they discover that Debian won't install
a working system on it, and to find the that the the non-free firmware
in a locked filing cabinet stuck in a disused lavatory with a sign on
the door saying 'Beware of the leopard'.

Remember, the Debian Social Contract says that our priorities are our
users *and* free software.  Making it nearly impossible for a novice
user to install Debian on their brand new laptop where Windows 10 and
Ubuntu just *works* might not be the best way of balancing the
competing needs here of the users and free software.   

Best regards,

- Ted

Re: Firmware - what are we going to do about it?

[Bobby]

FWIW, as a 10+ years user (first time caller :p) I strongly support
sticking with the status quo. There are plenty of systems that don't
require firmware to work, and often when people say it doesn't "work"
they really mean that its functionality is more limited. I use Debian
specifically because it has a good free license policy that separates
these things out cleanly and makes it easy to get rid of all the
proprietary junk -- by never installing it. Debian is, in my
experience, the most stable and accessible way to reliably have a free
system, and I would be very disappointed to lose that. I think the
ideological element is important, drawing a line in the sand and
making it clear to users that if hardware isn't working, the
manufacturer is at fault. And I like to know that myself, so I can
return the hardware and replace it — it can sometimes be hard to find
documentation as to whether hardware will be useable or crippled with
the need for proprietary crap. I have not personally encountered these
widespread problems you describe with modern hardware — more sporadic
issues — but I am not a bleeding edge, buy it ASAP person. (This is
another ideological point: we are destroying the environment with
e-waste thanks to unnecessary hardware upgrades and planned
obsolescence.) I think sacrificing a core aspect of Debian for the
sake of covenient access to novelty hardware is a real shame.

There are definitely people who use forks because it's easier to
install non-free firmware. What's the problem with that? Let them use
forks. A distro can't be all things to all people. Debian is unique in
this area, and it would be a shame to sacrifice that and make it just
like all the rest. And it's unclear what benefit there is to
attracting a larger and larger userbase as a bottom-line. It is not a
commercial project, so they will not be paying customers. The
best-case scenario is that people are attracted to making
contributions or becoming more interested in free software, which I
thought was the main goal. So if that isn't prioritized, what's the
point?

Further, there are security concerns with blobs. Yes, we can get
microcode updates, but were those updates themselves actually audited?
As far as I know, they are just as opaque as the code they're
replacing. They could be making security worse, and we won't know
until someone finds the exploits. The rare event where a microcode
update is released and it increases security is far outweighed by the
vast majority of the situations where installing opaque code is
detrimental to security.

If people are unhappy with the status quo, my proposal would be to
encourage more people to work on free alternatives. There is an ocean
of possibilities here, from open hardware to reverse engineering. My
feeling is that a lot more could be done to better support hardware
that doesn't involve non-free code at all. There are many free
projects that have never made it to Debian.

Anyway, I'm just a user/lurker, so I appreciate that my voice doesn't
carry much weight. And this discussion is a bit old now, so I hope I'm
not stepping on toes. Just my two cents! Thank you everyone for all
the hard work you do to make my computer significantly less
infuriating to use. It's the best operating system I've ever used, and
I have used quite a few.
-pnppl

Re: Firmware - what are we going to do about it?

[Helmut Grohne]

Hi Steve et al,

On Tue, Apr 19, 2022 at 01:27:46AM +0100, Steve McIntyre wrote:
> TL;DR: firmware support in Debian sucks, and we need to change this. See the
> "My preference, and rationale" Section below.

Thank you for the excellent write-up.

>  5. We could split out the non-free firmware packages into a new
> non-free-firmware component in the archive, and allow a specific exception
> only to allow inclusion of those packages on our official media. We would
> then generate only one set of official media, including those non-free
> firmware packages.

My perception is that we already have largely consensus on this option
despite a few vocal minorities disagreeing with it.

I think that the main disagreements fall into one of two categories:

 * Debian should provide an entirely free installation media.
 * The user should have a choice for whether to run/install non-free
   firmware.

A few people have spoken in favour of continuing the building of free
images. Can you give more intuition on how much extra cost (work) these
images add if the alternative is to only produce the ones with non-free
firmware? How about reducing the effort to test free images?

I imagine here that we kinda reverse our current presentation. Rather
than show the free ones and hide the non-free ones, we'd present the
ones with firmware as official installation media. I trust that those
users that really need the free ones, will be able to locate them
despite not being presented prominently.

If continuing the production of free images does not impose an undue
workload, I think we could increase the consensus for an option 5b (and
also produce hidden free images).

Regarding the choice, Russ and others mentioned that the presentation of
that choice is not encoded in the option. From a GR-pov, I think that's
the right way forward. However, we may discuss it separately.

The argument about making an informed choice seems rather convincing to
me. As such, I'd prefer for the default installation to do the
following:
 * Check whether any non-free firmware is being used by the installer.
   I'm not 100% sure whether this is possible with reasonable effort and
   precision, but an approximation might not be too bad. A first try
   could be: dmesg | grep "firmware: direct-loading firmware"
 * Add a prompt to the default installation that asks whether non-free
   firmware should be included in the installation. It should also
   indicate whether non-free firmware has already been used in the
   process of booting the installation media. Regardless of whether it
   has been used, I'd prefer the default answer to be "yes".
 * Possibly add a second prompt in case firmware has been used and the
   user said "no" to ask for confirmation as this outcome would be
   very unlikely.
 * The prompts should be preseedable. This one likely is easy.

I understand that much of what I'm proposing here puts extra load on the
installer team. That's why I'm interested in better understanding how
much extra work that'd be and whether it's worth.

My expectation is that these two adaptions would alleviate much of the
concern presented in this thread.

>From a practical side, I'd likely put option 5 (without the extra
changes requested here) somewhere close to the top for all the good
reasons given in this thread. Quite clearly, the default installation
medium should work and it kinda does not right now.

Helmut

Re: Firmware - what are we going to do about it?

[Andres Salomon]

Thanks for starting this conversation!


>  5. We could split out the non-free firmware packages into a new
>     non-free-firmware component in the archive, and allow a specific 
exception
>     only to allow inclusion of those packages on our official media. 
We would
>     then generate only one set of official media, including those 
non-free

>     firmware packages.
>
>     (We've already seen various suggestions in recent years to split 
up the

>     non-free component of the archive like this, for example into
>     non-free-firmware, non-free-doc, non-free-drivers, etc. Disagreement
>     (bike-shedding?) about the split caused us to not make any 
progress on
> this. I believe this project should be picked up and completed. 
We don't
>     have to make a perfect solution here immediately, just something 
that works
>     well enough for our needs today. We can always tweak and improve 
the setup

>     incrementally if that's needed.)
>
> These are the most likely possible options, in my opinion. If you 
have a better

> suggestion, please let us know!
>
> I'd like to take this set of options to a GR, and do it soon. I want 
to get a
> clear decision from the wider Debian project as to how to organise 
firmware and
> installation images. If we do end up changing how we do things, I 
want a clear

> mandate from the project to do that.


Personally, I'm a fan of option #5. However, I'd like to point out that 
these are two separate things, the first of which (creating a 
non-free-firmware archive component) would benefit users greatly and 
doesn't require a GR. I use non-free on my systems pretty much 
exclusively for non-free firmware. On my systems that require it, I 
would appreciate an archive that is ONLY non-free firmware. That would 
ensure that I never accidentally pull in a piece of (non-firmware) 
software from non-free.


In the past, I have absentmindedly installed rar or unrar from non-free 
when I meant to install unrar-free from main. Ideally that shouldn't be 
a mistake that could even happen. With a non-free-firmware archive, I 
could ensure that it never happens again.



Thanks,

Andres

Re: shim-signed (was: Firmware - what are we going to do about it?)

[Paul Wise]

On Tue, 2022-04-26 at 20:41 +0200, Bastian Blank wrote:

> secure boot signing process at Microsoft is a review-sign process

What kind of review are Microsoft doing of the Debian shim?

Are they reviewing the source and checking for a reproducible build?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: shim-signed (was: Firmware - what are we going to do about it?)

[Bastian Blank]

Moin

On Tue, Apr 26, 2022 at 04:14:02PM +0200, Marc Haber wrote:
> On Sat, 23 Apr 2022 18:21:47 +0100, Steve McIntyre 
> wrote:
> >We don't have good docs around this in general (hey, it's security
> >software - it's against the law to write good and complete docs!), but
> >I've certainly discussed this with a few folks over the years.
> It would be great to have that written down somewhere to tell poeple
> what they're actually doing.

Something like https://wiki.debian.org/SecureBoot?

> >Alternatively, people can build replacement shim-signed packages using
> >their own root of trust if desired. If we had a large enough number of
> >users wanting a different root of trust, we could even offer our own
> >different shim-signed package to match.
> I would probably prefer to have grub an/or the kernel signed, avoiding
> additional code, but maybe having some explanation would convince me
> that the shim actually improves things additionally to adding
> complexity.

All the UEFI parts (GRUB, kernel) and also the kernel modules _are_
signed.  Otherwise this whole stunt would be kind of useless.

However, secure boot signing process at Microsoft is a review-sign
process, aka you send the binary to the authority and get a signature
back.  They don't provide a signed certificate, which you could use to
sign stuff at will, as you would do with an e-mail (to be exact, S/MIME
and secure boot uses the same signature format).

So it is simply not possible with the existing process, to sign
everything with it.  So shim was introduced, which is signed using the
review process, and adapts the signing to accept signatures done by
another CA, which is controlled by Debian and used to sign everything.

Regards,
Bastian

-- 
Extreme feminine beauty is always disturbing.
-- Spock, "The Cloud Minders", stardate 5818.4

Re: shim-signed (was: Firmware - what are we going to do about it?)

[Steve McIntyre]

Marc Haber wrote:
>On Sat, 23 Apr 2022 18:21:47 +0100, Steve McIntyre 
>
>>Better than that, our shim-signed source package always double-checks
>>things here. At build time it removes the Microsoft signature and
>>compares that shim binary to the binary that we submitted for
>>signing. We would spot immediately if there was any code added.
>
>And if that check fails at build time, the Debian process refrains
>from putting a Debian signature on the deb and from uploading? Can the
>end user build the shim herself, remove the signature from the signed
>shim and compare the binary, preferably in a documented way?

Look at the shim-signed source - the build will fail if the code has
changed.

-- 
Steve McIntyre, Cambridge, UK.st...@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

Re: shim-signed (was: Firmware - what are we going to do about it?)

[Ansgar]

On Tue, 2022-04-26 at 16:04 +0200, Marc Haber wrote:
> On Sat, 23 Apr 2022 13:54:59 +0200, Ansgar  wrote:
> > Why?
> 
> If only I knew. I myself don't feel to comfortable to rely on
> Microsoft being able to pull the plug on us any time. I don't know
> whether they can, but I imagine some kind of revocation mechanism
> being in place.

As with all certificate systems, the revocation system is fairly broken
;-)

> > Because it contains a third-party signature for which the private
> > key is not included in Debian? The same is true for signatures in
> > debian-archive-keyring, debian-keyring, ca-certificates, wireless-
> > regdb, and many other packages.
> 
> A running system doesn't rely on any of those.

It will also work if Secure Boot is disabled (which should be possible
on at least all x86 systems). If you want Secure Boot w/ Microsoft's
key[1], then you obviously have to rely on Microsoft's key.

  [1]: As far as I understand, one reason it's Microsoft's key is that
   nobody else wanted to run a CA for this.

> > Debian's buildds build shim (binary package: shim-unsigned); the
> > binary generated by Debian is then signed by Microsoft's key.
> 
> And we have a mechanism to check whether the code is actually the
> same?

You can do that even manually:

+---
| $ diff -u <(hexdump -C ../s/usr/lib/shim/shimx64.efi) <(hexdump -C 
shimx64.efi.signed) | head -n 26
| --- /proc/self/fd/11  2022-04-26 16:35:32.983515245 +0200
| +++ /proc/self/fd/17  2022-04-26 16:35:32.983515245 +0200
| @@ -11,12 +11,12 @@
|  00a0  00 72 06 00 00 00 00 00  00 20 02 00 00 20 02 00  |.r... ... 
..|
|  00b0  00 00 00 00 00 00 00 00  00 10 00 00 00 02 00 00  
||
|  00c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  
||
| -00d0  00 00 0d 00 00 04 00 00  9b 82 0e 00 0a 00 00 00  
||
| +00d0  00 00 0d 00 00 04 00 00  bb af 0e 00 0a 00 00 00  
||
|  00e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  
||
|  *
|  0100  00 00 00 00 10 00 00 00  00 00 00 00 00 00 00 00  
||
|  0110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  
||
| -*
| +0120  00 00 00 00 00 00 00 00  e8 1f 0e 00 78 21 00 00  
|x!..|
|  0130  00 f0 07 00 0a 00 00 00  00 00 00 00 00 00 00 00  
||
|  0140  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  
||
|  *
| @@ -57279,5 +57279,540 @@
|  000e1fb0  44 00 6c 6f 61 64 5f 6f  70 74 69 6f 6e 73 00 50  
|D.load_options.P|
|  000e1fc0  4b 45 59 5f 55 53 41 47  45 5f 50 45 52 49 4f 44  
|KEY_USAGE_PERIOD|
|  000e1fd0  5f 69 74 00 58 35 30 39  5f 4e 41 4d 45 5f 45 4e  
|_it.X509_NAME_EN|
| -000e1fe0  54 52 59 5f 69 74 00  |TRY_it.|
| -000e1fe7
| +000e1fe0  54 52 59 5f 69 74 00 00  78 21 00 00 00 02 02 00  
|TRY_it..x!..|
| +000e1ff0  30 82 21 6b 06 09 2a 86  48 86 f7 0d 01 07 02 a0  
|0.!k..*.H...|
| +000e2000  82 21 5c 30 82 21 58 02  01 01 31 0f 30 0d 06 09  
|.!\0.!X...1.0...|
+---

If I remember correctly:
- the first change (~0xd0) should be a checksum of either the file or
  just the header
- the second change (~0x120) is the offset of the signature table in 
  the database (0xe1fe8) and its size.
- the third change (~0xe1fe0) is appending the signature

You can also extract the signature, attach the signature to the
unsigned file and verify you get the same binary (src:shim-signed does
this[2]).

  [2]: 
https://salsa.debian.org/efi-team/shim-signed/-/blob/52f43dc447fdc4fbb948a5883c0a04077aeb7dd4/Makefile#L9

One could also teach diff tools to strip/ignore signatures. This would
be useful if we decide to sign ELF executables, files lists or binary
package themselves: without excluding the signature, no package would
be reproducible any longer...

Ansgar

Re: shim-signed (was: Firmware - what are we going to do about it?)

[Marc Haber]

On Sat, 23 Apr 2022 18:21:47 +0100, Steve McIntyre 
wrote:
>We don't have good docs around this in general (hey, it's security
>software - it's against the law to write good and complete docs!), but
>I've certainly discussed this with a few folks over the years.

It would be great to have that written down somewhere to tell poeple
what they're actually doing.

>Alternatively, people can build replacement shim-signed packages using
>their own root of trust if desired. If we had a large enough number of
>users wanting a different root of trust, we could even offer our own
>different shim-signed package to match.

I would probably prefer to have grub an/or the kernel signed, avoiding
additional code, but maybe having some explanation would convince me
that the shim actually improves things additionally to adding
complexity.

>Better than that, our shim-signed source package always double-checks
>things here. At build time it removes the Microsoft signature and
>compares that shim binary to the binary that we submitted for
>signing. We would spot immediately if there was any code added.

And if that check fails at build time, the Debian process refrains
from putting a Debian signature on the deb and from uploading? Can the
end user build the shim herself, remove the signature from the signed
shim and compare the binary, preferably in a documented way?

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: shim-signed (was: Firmware - what are we going to do about it?)

[Marc Haber]

On Sat, 23 Apr 2022 13:54:59 +0200, Ansgar  wrote:
>On Sat, 2022-04-23 at 12:21 +0200, Marc Haber wrote:
>> >Is the presence of shim-signed on the install media enough to make
>> >people feel somehow contaminated?
>>
>> I think so, yes. Personally, I don't care too much but i can
>> understand why some people might.
>
>Why?

If only I knew. I myself don't feel to comfortable to rely on
Microsoft being able to pull the plug on us any time. I don't know
whether they can, but I imagine some kind of revocation mechanism
being in place.

And it's anther lay of indirection. While RFC compliant (1925, 6a)
this introduces another possible attach vector since shim-signed might
have to do its own check about the kernel to load. I do not know zilch
about the shim, but this might be an issue for people.

> Because it contains a third-party signature for which the private
>key is not included in Debian? The same is true for signatures in
>debian-archive-keyring, debian-keyring, ca-certificates, wireless-
>regdb, and many other packages.

A running system doesn't rely on any of those.

>If we were to include more signatures in binary packages (e.g., a
>signed manifest listing files (with hashes) shipped by the package,
>signed executables, an embedded signature for the .deb itself), would
>that be a problem?
>
>We do include signatures for source packages (*.dsc and also for
>upstream tarballs) as well.

I would LOVE to have an easier possibility to check the actual
uploader's signature for anything in the archive short of squatting on
every changes file ever visible.

>> We can compile shim-signed and compare the signed code with our own
>> object code, can't we?  That we we would only have to worry about the
>> validity and benignness of the signature and not worry about having
>> undocumented functionality in the signed code.
>
>Debian's buildds build shim (binary package: shim-unsigned); the binary
>generated by Debian is then signed by Microsoft's key.

And we have a mechanism to check whether the code is actually the
same?

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Firmware - what are we going to do about it?

[Hans]

Dear developers,

if like to here an opinion from the useer side, please listen.

I made many installations of debian in the last years, mostly notebooks 
preinstalled with windows. What often lacks is, that on many newer notebooks 
the network card is not accessible. Either due of missing firmware or because 
the network card is not included in the old installer kernel (speaking of 
debian/stable).

This includes wireless and wired cards. Especially Intel, Atheros and Realtec 
cards are involved in this issue.

So, if you ask me, what should be improved:

1. For installation the latest kernel should be used. Can be deinstalled after 
installation.

2. All (and I mean ALL!) firmware should be available on the installer. This 
means not, they should be installed. It should be installable, but must not 
forcely be installed. Maybe it CAN be installed, when it is needed during the 
installation.

3. Kernel developers (and that is only a suggestion!), should take care , that 
"debian/stable" kernels support newest hardware.

Just my 2 cents

Best regards

Hans

 

Re: Firmware - what are we going to do about it?

[Hakan Bayındır]

On 4/26/22 12:08, Andrey Rahmatullin wrote:

On Tue, Apr 26, 2022 at 11:59:20AM +0300, Hakan Bayındır wrote:

No, they do not. Most popular devices won't work at all without non-
free firmware, including boring things such as mass storage (SD cards,
SSD, HDD, ..., and controllers), input devices (keyboards, mice, ...).


Yeah, you’re right. Since the firmware images always there and doesn’t
need to be hot-loaded by the driver itself 99% of the time (for these
classes of devices), I tend to forget about them.

Note that this fact was mentioned many times in this thread.


I personally didn't have the time to follow/reread all of the thread 
unfortunately, however considering here's a development thread with a 
lot of knowledgeable people, it's of course expected.



I wonder whether these “proper” firmware can be considered as part of the 
hardware,

FSF and/or some FSF proponents certainly think like this. Others just
conveniently ignore it completely.


I didn't come to that point by being a FSF "proponent", but starting at 
an early age with a Commodore 64, and learning that firmware is 
something inside that you can't proverbially touch or update, then being 
able to touch it as my knowledge accumulates and firmware becomes closer 
to surface as the technology evolves.


I always believed that everything should be open and accessible before I 
knew about Linux or FSF. These are just two things which align with my 
values well, and I use Debian for 15 years, since it's the best aligning 
distribution with my values, amongst many other things.


I have no intention to derail the discussion by moving the goalposts or 
to "conveniently ignore" things.



since it’s bundled with the hardware, but not with the driver itself.

In the Linux world loadable firmware is rarely "bundled with the driver".
This includes the use case discussed in this thread.


By bundled with the driver I didn't mean "Linux World", but the bundle 
you receive from the vendor, mostly for Windows environment, and the 
media where the firmware lives (in the hardware vs. the driver image). 
Probably the days when Linux is considered as a second class citizen by 
most hardware vendors is still too ingrained in me. I wasn't clear 
enough, sorry about that.



This makes matters more complicated, of course, but starting somewhere
may create the same wedging effect as in the drivers, over time.

Such arguments seem to ignore that
1) it's not about "starting somewhere" because we aren't discussing
something we will need to decide before some point in the future: the
situation exists for many years, we are discussing whether we should
change how to handle it, not how to start handling it;
2) the often mentioned expected effect on hardware manufacturers should be
already felt in some form as the status quo of not providing any non-free
firmware on the official image is many years old;
3) so far the usability of systems with the official image becomes worse,
not better, over time.



I'm aware of all three, and this is why I proposed a 6th option as my 
first message to this thread, which consists of creating a tool which 
combines the firmware.zip and the current free image to a USB flash 
drive and directly "burn" it, as an "automagic" solution, allowing users 
to assemble their images without complicating things on the policy side 
much.


Again, to reiterate, I'm not "hard-against" adding firmware images to 
the official ISO and asking a question about installing them during 
installation, but considering the role and place of Debian among the 
Linux distributions, I just want to highlight that the choices done here 
will probably have a ripple effect, so we need to consider it correctly 
and have to be well-aware of the ethical implications, the DFSG and the 
Social Contract. And not undermine these two inadvertently with the 
actions we take.


Hope it's more clear now,

Regards,

H.

Re: Firmware - what are we going to do about it?

[Andrey Rahmatullin]

On Tue, Apr 26, 2022 at 11:59:20AM +0300, Hakan Bayındır wrote:
> > No, they do not. Most popular devices won't work at all without non-
> > free firmware, including boring things such as mass storage (SD cards,
> > SSD, HDD, ..., and controllers), input devices (keyboards, mice, ...).
> 
> Yeah, you’re right. Since the firmware images always there and doesn’t
> need to be hot-loaded by the driver itself 99% of the time (for these
> classes of devices), I tend to forget about them.
Note that this fact was mentioned many times in this thread.

> I wonder whether these “proper” firmware can be considered as part of the 
> hardware,
FSF and/or some FSF proponents certainly think like this. Others just
conveniently ignore it completely.

> since it’s bundled with the hardware, but not with the driver itself. 
In the Linux world loadable firmware is rarely "bundled with the driver".
This includes the use case discussed in this thread.

> This makes matters more complicated, of course, but starting somewhere
> may create the same wedging effect as in the drivers, over time.
Such arguments seem to ignore that
1) it's not about "starting somewhere" because we aren't discussing
something we will need to decide before some point in the future: the
situation exists for many years, we are discussing whether we should
change how to handle it, not how to start handling it;
2) the often mentioned expected effect on hardware manufacturers should be
already felt in some form as the status quo of not providing any non-free
firmware on the official image is many years old;
3) so far the usability of systems with the official image becomes worse,
not better, over time.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Hakan Bayındır]

> On 26 Apr 2022, at 11:30, Ansgar  wrote:
> 
> On Tue, 2022-04-26 at 10:47 +0300, Hakan Bayındır wrote:
>> While I understand where you're coming from, I don't think such thing
>> is  necessary, because a) Most popular devices with non-free firmware
>> blobs already work without such firmware
> 
> No, they do not. Most popular devices won't work at all without non-
> free firmware, including boring things such as mass storage (SD cards,
> SSD, HDD, ..., and controllers), input devices (keyboards, mice, ...).

Yeah, you’re right. Since the firmware images always there and doesn’t need to 
be hot-loaded by the driver itself 99% of the time (for these classes of 
devices), I tend to forget about them.

I wonder whether these “proper” firmware can be considered as part of the 
hardware, since it’s bundled with the hardware, but not with the driver itself. 
This makes matters more complicated, of course, but starting somewhere may 
create the same wedging effect as in the drivers, over time.

> 
>> , albeit with a lower performance 
>> (e.g. Realtek NICs), and b) The drivers gracefully handle the lack of
>> firmware already, with a couple of harmless "ERROR:" messages.
> 
> I would assume such NICs actually come with preinstalled non-free
> firmware which just has less functionality...

I generally envision them as an old school hardware with some ARM cores 
attached, and the functionality is disabled since you don’t fire up the ARM 
core with the proper so-called “program”.

> 
> I get the impression you pretend that preinstalled non-free firmware
> just doesn't exist.

Ah no, it’s a honest brain-short. Since I exposed to a lot of hardware over the 
decades, my brain tends to categorize resident, non-updatable firmware as part 
of the hardware itself, since you have no access to it as you don’t have access 
to the silicon.

Sorry for the unintentional misunderstanding and possible tension.

Cheers,

H.

> Ansgar
> 

Re: Firmware - what are we going to do about it?

[Ansgar]

On Tue, 2022-04-26 at 10:47 +0300, Hakan Bayındır wrote:
> While I understand where you're coming from, I don't think such thing
> is  necessary, because a) Most popular devices with non-free firmware
> blobs already work without such firmware

No, they do not. Most popular devices won't work at all without non-
free firmware, including boring things such as mass storage (SD cards,
SSD, HDD, ..., and controllers), input devices (keyboards, mice, ...).

> , albeit with a lower performance 
> (e.g. Realtek NICs), and b) The drivers gracefully handle the lack of
> firmware already, with a couple of harmless "ERROR:" messages.

I would assume such NICs actually come with preinstalled non-free
firmware which just has less functionality...

I get the impression you pretend that preinstalled non-free firmware
just doesn't exist.

Ansgar

Re: Firmware - what are we going to do about it?

[Hakan Bayındır]

On 4/26/22 09:12, Ansgar wrote:

On Mon, 2022-04-25 at 23:48 +0300, Hakan Bayındır wrote:

While what you’re saying is technically true, the default selection
means much more than a default. It’s defines the stance of Debian, as
a whole.

[...]

So, if Option 5 is adopted, the default state is as important as the
step itself IMHO. I also still believe that giving people the tools
for assembling their "firmware enabled” install media is a valid
option, but it’s not favored as far as I can see (no hard feelings,
though).


And we stay a possibility for FSF-people.

FSF people condemned Debian long ago:
https://www.gnu.org/distros/common-distros.html#Debian


While I like and support what FSF is standing for, I don’t think
their “condemnation” is a valid reason for not pursuing the ideals
DFSG puts forward. In my opinion, DFSG is one of the things underpins
the essence of Debian, and is a force for creating a more free and
open world. We’re almost there on the driver side, and while it gonna
take some time, we can be there on the firmware side. We just have to
be persistent, sometimes stubborn even.


Maybe then the "DFSG-free" installer should also exclude drivers for
devices that require non-free firmware, including preinstalled non-free
firmware? It could also show a message indicating that such devices are
not supported (if possible).

People could still assemble their "non-free firmware enabled" install
media including such drivers.


While I understand where you're coming from, I don't think such thing is 
necessary, because a) Most popular devices with non-free firmware blobs 
already work without such firmware, albeit with a lower performance 
(e.g. Realtek NICs), and b) The drivers gracefully handle the lack of 
firmware already, with a couple of harmless "ERROR:" messages.


It's worth noting that the drivers in question are already free software 
and might have functionality over time to support newer devices of the 
family which might have open firmware, or ideally the firmware code is 
published retroactively.


Moreover, I guess excluding such drivers would require a new CI/CD 
pipeline, and may require new kernel packages complicating the situation 
further, for both users and maintainers alike.


My ideal to make things as frictionless and transparent possible, while 
making the transition between two states as easy.


I don't believe we have to decide between DFSG and convenience. A more 
gradual spectrum should be possible.


Cheers,

H.


Ansgar

Re: Firmware - what are we going to do about it?

[Ansgar]

On Mon, 2022-04-25 at 23:48 +0300, Hakan Bayındır wrote:
> While what you’re saying is technically true, the default selection
> means much more than a default. It’s defines the stance of Debian, as
> a whole.
[...]
> So, if Option 5 is adopted, the default state is as important as the
> step itself IMHO. I also still believe that giving people the tools
> for assembling their "firmware enabled” install media is a valid
> option, but it’s not favored as far as I can see (no hard feelings,
> though).
> 
> > > And we stay a possibility for FSF-people.
> > FSF people condemned Debian long ago:
> > https://www.gnu.org/distros/common-distros.html#Debian
> 
> While I like and support what FSF is standing for, I don’t think
> their “condemnation” is a valid reason for not pursuing the ideals
> DFSG puts forward. In my opinion, DFSG is one of the things underpins
> the essence of Debian, and is a force for creating a more free and
> open world. We’re almost there on the driver side, and while it gonna
> take some time, we can be there on the firmware side. We just have to
> be persistent, sometimes stubborn even.

Maybe then the "DFSG-free" installer should also exclude drivers for
devices that require non-free firmware, including preinstalled non-free
firmware? It could also show a message indicating that such devices are
not supported (if possible).

People could still assemble their "non-free firmware enabled" install
media including such drivers.

Ansgar

Re: Firmware - what are we going to do about it?

[Hakan Bayındır]

> On 25 Apr 2022, at 19:40, Andrey Rahmatullin  wrote:
> 
> On Mon, Apr 25, 2022 at 05:53:03PM +0200, Paul van der Vlis wrote:
>> I have an idea for an extra option:
>> 
>> 6. Put the closed source firmware somewhere in the Debian images, but 
>> never
>> install closed source firmware by default. "No" should be the default.
> That's the option 3 more or less.
 
 Option 3 says to publish two sets of images.
 
 
 3. We could stop pretending that the non-free images are unofficial, and
 maybe move them alongside the normal free images so they're published
 together. This would make them easier to find for people that need them, 
 but
 is likely to cause users to question why we still make any images without
 firmware if they're otherwise identical.
 
>>> If you want to drop the non-firmware image then it's the option 4 more or
>>> less.
>> 
>> I see it more like option 5, with the difference that no closed source
>> firmware or repository will be installed by default. With the non-free ISO
>> this is the case.
>> 
>> For people who don't like closed source firmware, it gives the option not to
>> install some firmware. E.g.: do I need that bluetooth adapter?
> As I said, this is about d-i questions and defaults more than it's about
> ISO choices and content.

While what you’re saying is technically true, the default selection means much 
more than a default. It’s defines the stance of Debian, as a whole.

So, if Option 5 is adopted, the default state is as important as the step 
itself IMHO. I also still believe that giving people the tools for assembling 
their "firmware enabled” install media is a valid option, but it’s not favored 
as far as I can see (no hard feelings, though).

>> And we stay a possibility for FSF-people.
> FSF people condemned Debian long ago:
> https://www.gnu.org/distros/common-distros.html#Debian

While I like and support what FSF is standing for, I don’t think their 
“condemnation” is a valid reason for not pursuing the ideals DFSG puts forward. 
In my opinion, DFSG is one of the things underpins the essence of Debian, and 
is a force for creating a more free and open world. We’re almost there on the 
driver side, and while it gonna take some time, we can be there on the firmware 
side. We just have to be persistent, sometimes stubborn even.

>> Most SSD devices also have firmware, do you update that firmware?
> Sure.
> 
> -- 
> WBR, wRAR

Re: Firmware - what are we going to do about it?

[Andrey Rahmatullin]

On Mon, Apr 25, 2022 at 05:53:03PM +0200, Paul van der Vlis wrote:
> > > > > I have an idea for an extra option:
> > > > > 
> > > > > 6. Put the closed source firmware somewhere in the Debian images, but 
> > > > > never
> > > > > install closed source firmware by default. "No" should be the default.
> > > > That's the option 3 more or less.
> > > 
> > > Option 3 says to publish two sets of images.
> > > 
> > > 
> > > 3. We could stop pretending that the non-free images are unofficial, and
> > > maybe move them alongside the normal free images so they're published
> > > together. This would make them easier to find for people that need them, 
> > > but
> > > is likely to cause users to question why we still make any images without
> > > firmware if they're otherwise identical.
> > > 
> > If you want to drop the non-firmware image then it's the option 4 more or
> > less.
> 
> I see it more like option 5, with the difference that no closed source
> firmware or repository will be installed by default. With the non-free ISO
> this is the case.
> 
> For people who don't like closed source firmware, it gives the option not to
> install some firmware. E.g.: do I need that bluetooth adapter?
As I said, this is about d-i questions and defaults more than it's about
ISO choices and content.

> And we stay a possibility for FSF-people.
FSF people condemned Debian long ago:
https://www.gnu.org/distros/common-distros.html#Debian

> Most SSD devices also have firmware, do you update that firmware?
Sure.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Paul van der Vlis]

Op 23-04-2022 om 23:30 schreef Andrey Rahmatullin:

On Sat, Apr 23, 2022 at 10:48:03PM +0200, Paul van der Vlis wrote:

I have an idea for an extra option:

6. Put the closed source firmware somewhere in the Debian images, but never
install closed source firmware by default. "No" should be the default.

That's the option 3 more or less.


Option 3 says to publish two sets of images.


3. We could stop pretending that the non-free images are unofficial, and
maybe move them alongside the normal free images so they're published
together. This would make them easier to find for people that need them, but
is likely to cause users to question why we still make any images without
firmware if they're otherwise identical.


If you want to drop the non-firmware image then it's the option 4 more or
less.


I see it more like option 5, with the difference that no closed source 
firmware or repository will be installed by default. With the non-free 
ISO this is the case.


For people who don't like closed source firmware, it gives the option 
not to install some firmware. E.g.: do I need that bluetooth adapter?


And we stay a possibility for FSF-people.


And it says nothing about defaults.

d-i defaults are mostly unrelated to the ISO set and the archive setup
questions. You seem to want to add a yet another "free vs usable, with
free as the default" question, which is not too bad, just yet another
thing for most people to change.


to put "non-free" into sources.list should also be an non-default choice,
even when you install closed source firmware.

No, that's a bad idea, which is one of the main reasons for the option 5.


The idea is not to promote closed source firmware in any way. Have it
available, but only for the people who really want it.

*shrug* that's just "have it available for most people" with extra
complexity. And you seem to miss the problem with installing firmware
packages but not enabling updates for them.
In that case the hardware will work, like how it would be if you would 
have the firmware on a (flash)rom on the device. You need to test the 
hardware only once, because the firmware will not change without special 
action.


Most SSD devices also have firmware, do you update that firmware?

With regards,
Paul van der Vlis



--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl

Re: Firmware - what are we going to do about it

[Luca Boccassi]

On Sun, 2022-04-24 at 00:23 +0100, Steve McIntyre wrote:
> Steven Robbins wrote:
> > 
> > Luca Boccassi wrote:
> > 
> > > Personally, I'd even go for option 4, so that other drivers are covered
> > > too (the general advice that can be found on the internet for users
> > > with nvidia hardware seems to be: "avoid Debian, go Ubuntu/Mint/etc",
> > > which is just a sad state of affairs). But option 5 is already a great
> > > improvement upon the status quo.
> > 
> > Agree!  
> > 
> > The original post did mention video cards, but I'm left unsure whether the 
> > non-free stuff in the NVidia case, for example, would fall into "firmware" 
> > (hence included) or "drivers".  If the latter, my sense is that Option 5 
> > was 
> > intended to be narrowly focused and exclude such drivers.  I'd rather 
> > support 
> > a wider focus that would include drivers -- basically any "non-free 
> > hardware 
> > support package".  So if Option 5 is narrow and Option 4 is wide-open "non-
> > free" maybe there's room for an option in between?
> 
> I have no desire to add a wider set of packages from non-free onto our
> media, I'm afraid. I'm entirely focused on firmware and **not**
> drivers. As and when we start to draft a GR to formalise what the
> project wants, feel free to add an option for that too but I
> personally wouldn't expect it to gain much traction.

Fair enough - making the firmware situation better is definitely more
important and urgent, and worth doing by itself. Focusing on that
sounds like a good strategy. I do not intend to propose alternative
options.

-- 
Kind regards,
Luca Boccassi

Re: Download page/options (was: Firmware - what are we going to do about it?)

[Diederik de Haas]

> My background is as a longtime debian user and support volunteer in #debian.

Thanks for doing that! I haven't been on that channel for a while, but I do 
remember what an incredible help you've been to many there :)

Apologies for my harsh wording wrt auto-download. I shouldn't have have put my 
unfiltered first reaction onto the ML.

> I think pabs's suggestion of improving the visibility of that choice on the
> website instead [of in d-i] could improve user friendliness

Fully agreed. When the user is visiting the DL page/section, they have a 
working PC (+browser) with a working network connection, which may not be the 
case within d-i.
On a webpage it's also trivial to include hyperlinks to further reading.

Here are some other suggestions (hopefully more constructive):

I came to the DL page with my Debian machine ... for which I didn't need an 
installer, but for an other machine which (hypothetically) didn't have it yet.
I think having a (prominent) first DL option is great: "Based on the machine 
you're currently running, we recommend this DL option for you"

Below that a button labeled "Help me choose" which will start a 'wizard' to 
guide the user to select the appropriate download option for their use case.

And below that a section "I want to choose myself" which presents the various 
options for which several suggestions have already been made.


Another idea is to have a multi-platform client program like the RPi Imager 
program which helps the user select the right 'thing' for them and then writes 
that onto the appropriate device. Maybe this is only useful for SBC's, but 
could possibly be wider applicable.

F.e. https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/
README.concatenateable_images is very clear and easy to do ... 
for a person like me.
But I wouldn't be surprised if it is too complicated for a novice person 
(especially if also new to Linux). A Debian Imager client program could 
download the appropriate components, combine them (behind the scene) and 
writes it to the, by the user selected and in a friendly way presented, 
medium.

HTH,
  Diederik

signature.asc
Description: This is a digitally signed message part.

Re: Firmware - what are we going to do about it?

[Andrey Rahmatullin]

On Sun, Apr 24, 2022 at 05:03:29AM +0200, Simon Richter wrote:
> > Making Debian hard to use is a very short-sighted view of how to promote
> > free software - it works in the very short term only.
> 
> The same applies in the other direction -- making no real distinction
> between free and non-free software is a short term solution to the usability
> problem, but does not incentivize hardware vendors to open up designs in the
> slightest.
Does the status quo incentivize them?

> With drivers, user awareness is there at least.
(only for people who can actually differentiate drivers and firmware)

> People know that the nV drivers are essentially unsupported and if it
> breaks, they get to keep the pieces. 
As opposed to "nouveau usually doesn't work and if it indeed doesn't, just
install the non-free driver".

> The same isn't true for firmware, users just expect that stuff will work
> and if it doesn't, it's Debian's fault. We can either validate that
> expectation, or push back on it, saying "this hardware is supported on a
> best-effort basis, but we can't help you because it's closed source."
This, again, should be equally applied to loadable firmware and firmware
on the board.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Simon Richter]

Hi,

On 4/23/22 11:07 PM, Iustin Pop wrote:


Making Debian hard to use is a very short-sighted view of how to promote
free software - it works in the very short term only.


The same applies in the other direction -- making no real distinction 
between free and non-free software is a short term solution to the 
usability problem, but does not incentivize hardware vendors to open up 
designs in the slightest.


With drivers, user awareness is there at least. People know that the nV 
drivers are essentially unsupported and if it breaks, they get to keep 
the pieces. The same isn't true for firmware, users just expect that 
stuff will work and if it doesn't, it's Debian's fault. We can either 
validate that expectation, or push back on it, saying "this hardware is 
supported on a best-effort basis, but we can't help you because it's 
closed source."


   Simon

Re: shim-signed (was: Firmware - what are we going to do about it?)

[Paul Wise]

On Sat, 2022-04-23 at 18:21 +0100, Steve McIntyre wrote:

> If you don't like the fact that Microsoft's keys are involved,
> it's possible on a lot of machines to enrol your own keys

On machines where this isn't possible in the UEFI firmware interface,
IIRC shim-signed is designed to allow you to enrol your own keys; you
should be able to boot Debian's MS-signed shim-signed once, enrol your
own keys and then switch to your own shim-signed. If UEFI bugs prevent
loading your own shim-signed, then Debian's MS-signed shim-signed will
still let you replace the Debian-signed GRUB, Linux etc images. 

IIRC this was done so that the distro docs can ignore the UEFI firmware
user interface for enrolling keys, which is different for every UEFI
vendor, while the shim interface for this is the same everywhere.

Of course, there may be UEFI bugs that break some of this, and on ARM
the MS requirement to allow enrolling keys was initially not present,
not sure if they re-added it for recent ARM based Windows laptops.

> and remove Microsoft's entirely.

ISTR that I read that even if you can do this on your particular UEFI
firmware, in practice this often *isn't* possible because parts of the
pre-installed firmware for some devices (option ROMs?) are MS-signed.

> we could even offer our own different shim-signed package to match.

Renaming shim-signed to shim-signed-microsoft and adding a new package
shim-signed-debian sounds like a good idea to me.

> If we had a large enough number of users wanting a different root of trust

I've seen a few people over the years wanting this, most want their own
root of trust rather a Debian root of trust though. There probably
aren't enough people to justify the extra effort, but it would make
Debian useful in a few more use-cases.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Firmware - what are we going to do about it

[Steve McIntyre]

Steven Robbins wrote:
>
>Luca Boccassi wrote:
>
>> Personally, I'd even go for option 4, so that other drivers are covered
>> too (the general advice that can be found on the internet for users
>> with nvidia hardware seems to be: "avoid Debian, go Ubuntu/Mint/etc",
>> which is just a sad state of affairs). But option 5 is already a great
>> improvement upon the status quo.
>
>Agree!  
>
>The original post did mention video cards, but I'm left unsure whether the 
>non-free stuff in the NVidia case, for example, would fall into "firmware" 
>(hence included) or "drivers".  If the latter, my sense is that Option 5 was 
>intended to be narrowly focused and exclude such drivers.  I'd rather support 
>a wider focus that would include drivers -- basically any "non-free hardware 
>support package".  So if Option 5 is narrow and Option 4 is wide-open "non-
>free" maybe there's room for an option in between?

I have no desire to add a wider set of packages from non-free onto our
media, I'm afraid. I'm entirely focused on firmware and **not**
drivers. As and when we start to draft a GR to formalise what the
project wants, feel free to add an option for that too but I
personally wouldn't expect it to gain much traction.

-- 
Steve McIntyre, Cambridge, UK.st...@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

Re: Firmware - what are we going to do about it?

[Andrey Rahmatullin]

On Sat, Apr 23, 2022 at 10:48:03PM +0200, Paul van der Vlis wrote:
> > > I have an idea for an extra option:
> > > 
> > > 6. Put the closed source firmware somewhere in the Debian images, but 
> > > never
> > > install closed source firmware by default. "No" should be the default.
> > That's the option 3 more or less.
> 
> Option 3 says to publish two sets of images.
> 
> 
> 3. We could stop pretending that the non-free images are unofficial, and
> maybe move them alongside the normal free images so they're published
> together. This would make them easier to find for people that need them, but
> is likely to cause users to question why we still make any images without
> firmware if they're otherwise identical.
> 
If you want to drop the non-firmware image then it's the option 4 more or
less.

> And it says nothing about defaults.
d-i defaults are mostly unrelated to the ISO set and the archive setup
questions. You seem to want to add a yet another "free vs usable, with
free as the default" question, which is not too bad, just yet another
thing for most people to change.

> > > to put "non-free" into sources.list should also be an non-default choice,
> > > even when you install closed source firmware.
> > No, that's a bad idea, which is one of the main reasons for the option 5.
> 
> The idea is not to promote closed source firmware in any way. Have it
> available, but only for the people who really want it.
*shrug* that's just "have it available for most people" with extra
complexity. And you seem to miss the problem with installing firmware
packages but not enabling updates for them.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Timothy M Butterworth]

On Sat, Apr 23, 2022 at 4:50 PM Paul van der Vlis 
wrote:

> Op 23-04-2022 om 16:10 schreef Andrey Rahmatullin:
> > On Sat, Apr 23, 2022 at 03:13:29PM +0200, Paul van der Vlis wrote:
> >>> I see several possible options that the images team can choose from
> here.
> >>> However, several of these options could undermine the principles of
> Debian. We
> >>> don't want to make fundamental changes like that without the clear
> backing of
> >>> the wider project. That's why I'm writing this...
> >>
> >> I have an idea for an extra option:
> >>
> >> 6. Put the closed source firmware somewhere in the Debian images, but
> never
> >> install closed source firmware by default. "No" should be the default.
> > That's the option 3 more or less.
>
> Option 3 says to publish two sets of images.
> And it says nothing about defaults.
>
> 
> 3. We could stop pretending that the non-free images are unofficial, and
> maybe move them alongside the normal free images so they're published
> together. This would make them easier to find for people that need them,
> but is likely to cause users to question why we still make any images
> without firmware if they're otherwise identical.
> 
>
This is the option I like. As a user who needs the closed source binary
blobs they should be easier to find.


> >> to put "non-free" into sources.list should also be an non-default
> choice,
> >> even when you install closed source firmware.
> > No, that's a bad idea, which is one of the main reasons for the option 5.
>
> The idea is not to promote closed source firmware in any way. Have it
> available, but only for the people who really want it.
>
> Maybe it's also an idea to put the firmware in a seperate partition.
>
> With regards,
> Paul
>
> BTW: I sell Debian media like USB-sticks. I know about the problems
> people have to choose a medium-type etc.
>
>
> --
> Paul van der Vlis Linux systeembeheer Groningen
> https://vandervlis.nl
>
>

Re: Firmware - what are we going to do about it?

[Iustin Pop]

On 2022-04-23 22:48:03, Paul van der Vlis wrote:
> Op 23-04-2022 om 16:10 schreef Andrey Rahmatullin:
> > On Sat, Apr 23, 2022 at 03:13:29PM +0200, Paul van der Vlis wrote:
> > > > I see several possible options that the images team can choose from 
> > > > here.
> > > > However, several of these options could undermine the principles of 
> > > > Debian. We
> > > > don't want to make fundamental changes like that without the clear 
> > > > backing of
> > > > the wider project. That's why I'm writing this...
> > > 
> > > I have an idea for an extra option:
> > > 
> > > 6. Put the closed source firmware somewhere in the Debian images, but 
> > > never
> > > install closed source firmware by default. "No" should be the default.
> > That's the option 3 more or less.
> 
> Option 3 says to publish two sets of images.
> And it says nothing about defaults.
> 
> 
> 3. We could stop pretending that the non-free images are unofficial, and
> maybe move them alongside the normal free images so they're published
> together. This would make them easier to find for people that need them, but
> is likely to cause users to question why we still make any images without
> firmware if they're otherwise identical.
> 
> 
> > > to put "non-free" into sources.list should also be an non-default choice,
> > > even when you install closed source firmware.
> > No, that's a bad idea, which is one of the main reasons for the option 5.
> 
> The idea is not to promote closed source firmware in any way. Have it
> available, but only for the people who really want it.

Uh. Have you actually read the start of the thread? Most machines
nowadays *need* it. It's not about wanting, but about the fact that
firmware is needed, and the more barriers you put in front of people,
the more people will just go with Ubuntu or other alternatives.

Making Debian hard to use is a very short-sighted view of how to promote
free software - it works in the very short term only.

regards,
iustin

Re: Firmware - what are we going to do about it?

[Paul van der Vlis]

Op 23-04-2022 om 16:10 schreef Andrey Rahmatullin:

On Sat, Apr 23, 2022 at 03:13:29PM +0200, Paul van der Vlis wrote:

I see several possible options that the images team can choose from here.
However, several of these options could undermine the principles of Debian. We
don't want to make fundamental changes like that without the clear backing of
the wider project. That's why I'm writing this...


I have an idea for an extra option:

6. Put the closed source firmware somewhere in the Debian images, but never
install closed source firmware by default. "No" should be the default.

That's the option 3 more or less.


Option 3 says to publish two sets of images.
And it says nothing about defaults.


3. We could stop pretending that the non-free images are unofficial, and 
maybe move them alongside the normal free images so they're published 
together. This would make them easier to find for people that need them, 
but is likely to cause users to question why we still make any images 
without firmware if they're otherwise identical.




to put "non-free" into sources.list should also be an non-default choice,
even when you install closed source firmware.

No, that's a bad idea, which is one of the main reasons for the option 5.


The idea is not to promote closed source firmware in any way. Have it 
available, but only for the people who really want it.


Maybe it's also an idea to put the firmware in a seperate partition.

With regards,
Paul

BTW: I sell Debian media like USB-sticks. I know about the problems 
people have to choose a medium-type etc.



--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl

Re: Re: Firmware - what are we going to do about it

[Steven Robbins]

Luca Boccassi wrote:

> Personally, I'd even go for option 4, so that other drivers are covered
> too (the general advice that can be found on the internet for users
> with nvidia hardware seems to be: "avoid Debian, go Ubuntu/Mint/etc",
> which is just a sad state of affairs). But option 5 is already a great
> improvement upon the status quo.

Agree!  

The original post did mention video cards, but I'm left unsure whether the 
non-free stuff in the NVidia case, for example, would fall into "firmware" 
(hence included) or "drivers".  If the latter, my sense is that Option 5 was 
intended to be narrowly focused and exclude such drivers.  I'd rather support 
a wider focus that would include drivers -- basically any "non-free hardware 
support package".  So if Option 5 is narrow and Option 4 is wide-open "non-
free" maybe there's room for an option in between?

-Steve



signature.asc
Description: This is a digitally signed message part.

Re: shim-signed (was: Firmware - what are we going to do about it?)

[Steve McIntyre]

Marc Haber wrote:
>On Fri, 22 Apr 2022 11:16:42 +0200, Philip Hands 
>wrote:
>>I understand the urge to insist upon absolute DFSG purity in the media
>>we produce, but when it comes to wanting to avoid every last shred of
>>data that we could not regenerate ourselves, I think we crossed that
>>line some time ago.
>>
>>I'm thinking of shim-signed, which is included in our official media.
>>
>>Despite being free software in source form, it is signed by Microsoft,
>>and can only be expected to work with that signature ... which we cannot
>>create.
>>
>>On most (all?) hardware one is able to avoid UEFI secure-boot, so won't
>>need to use shim-signed, but I'd imagine that some hardware insists on
>>secure-boot, or the opt-outs are somehow broken and so is not usable
>>without shim-signed.
>
>Excuse me for asking a user question on -devel, but do we have any
>docs where someone explains how much a security trade off is
>shim-signed relativ to the optimum? I think that using shim-signed is
>surely worse than a directly signed kernel, but I don't know whether I
>can tell my system (or shim-signed?) to accept MY or Debian's signed
>kernel without the Microsoft intermediate signature, and whether this
>is any more secure than running an encrypted system without secure
>boot at all.

We don't have good docs around this in general (hey, it's security
software - it's against the law to write good and complete docs!), but
I've certainly discussed this with a few folks over the years.

Fundamentally, shim is a compromise. It lets us use an existing root
of trust (that's already installed on the vast majority of x86
machines) to bootstrap our own secure setup.

If you don't like the fact that Microsoft's keys are involved. it's
possible on a lot of machines to enrol your own keys and remove
Microsoft's entirely. If you go that way, you could absolutely sign
grub and/or the kernel directly. But that's not something that's easy
to do - it's not likely to work well for the vast majority of users.

Running an encrypted system without secure boot *at all* is a
difficult thing to support well. The entire point of SB is that the
firmware can use keys to validate the next stage in the boot
process. An *encrypted* kernel stops other people logging in to your
system, but it does not give you protection against somebody tampering
with the system behind your back and doing a MitM attack.

Alternatively, people can build replacement shim-signed packages using
their own root of trust if desired. If we had a large enough number of
users wanting a different root of trust, we could even offer our own
different shim-signed package to match.

...

>>If not, is the problem having other blobs of data on the media that we
>>also cannot generate, or is it the licensing of that data, or something
>>else?
>
>We can compile shim-signed and compare the signed code with our own
>object code, can't we?  That we we would only have to worry about the
>validity and benignness of the signature and not worry about having
>undocumented functionality in the signed code.

Better than that, our shim-signed source package always double-checks
things here. At build time it removes the Microsoft signature and
compares that shim binary to the binary that we submitted for
signing. We would spot immediately if there was any code added.

-- 
Steve McIntyre, Cambridge, UK.st...@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

Re: Firmware - what are we going to do about it?

[Andrey Rahmatullin]

On Sat, Apr 23, 2022 at 03:13:29PM +0200, Paul van der Vlis wrote:
> > I see several possible options that the images team can choose from here.
> > However, several of these options could undermine the principles of Debian. 
> > We
> > don't want to make fundamental changes like that without the clear backing 
> > of
> > the wider project. That's why I'm writing this...
> 
> I have an idea for an extra option:
> 
> 6. Put the closed source firmware somewhere in the Debian images, but never
> install closed source firmware by default. "No" should be the default.
That's the option 3 more or less.

> to put "non-free" into sources.list should also be an non-default choice,
> even when you install closed source firmware.
No, that's a bad idea, which is one of the main reasons for the option 5.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Paul van der Vlis]

Op 19-04-2022 om 02:30 schreef Steve McIntyre:


I see several possible options that the images team can choose from here.
However, several of these options could undermine the principles of Debian. We
don't want to make fundamental changes like that without the clear backing of
the wider project. That's why I'm writing this...


I have an idea for an extra option:

6. Put the closed source firmware somewhere in the Debian images, but 
never install closed source firmware by default. "No" should be the 
default. And to put "non-free" into sources.list should also be an 
non-default choice, even when you install closed source firmware.


Maybe there could also be a patch, what removes the closed-source 
firmware from the image.


With regards,
Paul



--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl

Re: shim-signed (was: Firmware - what are we going to do about it?)

[Ansgar]

On Sat, 2022-04-23 at 12:21 +0200, Marc Haber wrote:
> >Is the presence of shim-signed on the install media enough to make
> >people feel somehow contaminated?
>
> I think so, yes. Personally, I don't care too much but i can
> understand why some people might.

Why? Because it contains a third-party signature for which the private
key is not included in Debian? The same is true for signatures in
debian-archive-keyring, debian-keyring, ca-certificates, wireless-
regdb, and many other packages.

If we were to include more signatures in binary packages (e.g., a
signed manifest listing files (with hashes) shipped by the package,
signed executables, an embedded signature for the .deb itself), would
that be a problem?

We do include signatures for source packages (*.dsc and also for
upstream tarballs) as well.

> We can compile shim-signed and compare the signed code with our own
> object code, can't we?  That we we would only have to worry about the
> validity and benignness of the signature and not worry about having
> undocumented functionality in the signed code.

Debian's buildds build shim (binary package: shim-unsigned); the binary
generated by Debian is then signed by Microsoft's key.

Ansgar

shim-signed (was: Firmware - what are we going to do about it?)

[Marc Haber]

On Fri, 22 Apr 2022 11:16:42 +0200, Philip Hands 
wrote:
>I understand the urge to insist upon absolute DFSG purity in the media
>we produce, but when it comes to wanting to avoid every last shred of
>data that we could not regenerate ourselves, I think we crossed that
>line some time ago.
>
>I'm thinking of shim-signed, which is included in our official media.
>
>Despite being free software in source form, it is signed by Microsoft,
>and can only be expected to work with that signature ... which we cannot
>create.
>
>On most (all?) hardware one is able to avoid UEFI secure-boot, so won't
>need to use shim-signed, but I'd imagine that some hardware insists on
>secure-boot, or the opt-outs are somehow broken and so is not usable
>without shim-signed.

Excuse me for asking a user question on -devel, but do we have any
docs where someone explains how much a security trade off is
shim-signed relativ to the optimum? I think that using shim-signed is
surely worse than a directly signed kernel, but I don't know whether I
can tell my system (or shim-signed?) to accept MY or Debian's signed
kernel without the Microsoft intermediate signature, and whether this
is any more secure than running an encrypted system without secure
boot at all.

Do we have docs for that?

>Is the presence of shim-signed on the install media enough to make
>people feel somehow contaminated?

I think so, yes. Personally, I don't care too much but i can
understand why some people might.

>If not, is the problem having other blobs of data on the media that we
>also cannot generate, or is it the licensing of that data, or something
>else?

We can compile shim-signed and compare the signed code with our own
object code, can't we?  That we we would only have to worry about the
validity and benignness of the signature and not worry about having
undocumented functionality in the signed code.

>If it ensures that fewer people abandon Debian out of frustration with
>the install then I'd suggest that it will actually result in less
>non-free software being used overall, as will having the option to
>enable only non-free-firmware without also enabling non-free.

Those are the people who use Ubuntu without even trying Debian because
somebody told them that Debian is SO hard to install.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Firmware - what are we going to do about it?

[Marc Haber]

On Thu, 21 Apr 2022 10:12:19 -0700, Russ Allbery 
wrote:
>I've been a Debian Developer for quite some time and can usually manage to
>figure out most tasks like this, and providing separate firmware to the
>installer has completely defeated me every time I've tried it.  I've spent
>frustrated hours trying to follow the documentation and doing things that
>look right only to have the installer say that there's no firmware visible
>without any clue as to how to debug the errors.  Every time I have tried
>this, I have eventually given up and found the non-free images, which just
>worked.

Amen. I know one installation with a five digit number of Debian
systems that uses a hacked installer with the Kernel from CentOS
because that one just works. I have talked to the guy who did that
operation (one of the most competent IT people I know) and he said
nearly the same as Russ said.

>If this is going to be the solution, it has to be WAY easier to do.

Yes, absolutely.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

writing good GR ballots (Re: Firmware - what are we going to do about it?)

[Holger Levsen]

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.


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Holger Levsen]

hi Steve,

On Tue, Apr 19, 2022 at 01:27:46AM +0100, Steve McIntyre wrote:
> TL;DR: firmware support in Debian sucks, and we need to change this. See the
> "My preference, and rationale" Section below.
[...]

and anyone involved, especillay including those not listed here:

> Thanks to people who reviewed earlier versions of this document and/or made
> suggestions for improvement, in particular:
> 
>   • Cyril Brulebois
>   • Matthew Garrett
>   • David Leggett
>   • Martin Michlmayr
>   • Andy Simpkins
>   • Neil Williams

I just wanna say THANK YOU VERY MUCH for this thread and everything good
which will undoubtfully arise from it. You rock.

And for those unware I would just like to point out
https://en.wikipedia.org/wiki/Intel_ME#Hardware which explains that on
modern Intel CPUs, there's another 386 CPU inside the CPU, running Minix,
so that "The ME has its own MAC and IP address for the out-of-band interface,
with direct access to the Ethernet controller; one portion of the Ethernet
traffic is diverted to the ME even before reaching the host's operating system".

My point is not, that other CPUs don't have this problem, but rather that
there's a lot of 'invisible' firmware on any modern computer, starting with
the CPU but going down all the way to the battery, screen, mouse and keyboard.

So this thread is (roughly guesstimated) only about 10-23% of the firmware
running on your computer, while today (as opposed to 1993) most of this
firmware *can* be updated.

IMO firmware is (sadly or not) somewhat out of scope for Debian. Even though,
or maybe precisely because hardware *is* software nowadays.


So, I'll say it again: many thanks to everyone involved in improving
running Debian on modern computers.

And huge thanks to those working on free and open hardware too.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

War is peace. Freedom is slavery. Covid is like the flu.


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Philip Hands]

Leandro Cunha  writes:

> Hi,
>
> On Mon, Apr 18, 2022 at 9:28 PM Steve McIntyre  wrote:
>>
>> TL;DR: firmware support in Debian sucks, and we need to change this. See the
>> "My preference, and rationale" Section below.
>>
>> In my opinion, the way we deal with (non-free) firmware in Debian is a mess,
>> and this is hurting many of our users daily. For a long time we've been
>> pretending that supporting and including (non-free) firmware on Debian 
>> systems
>> is not necessary. We don't want to have to provide (non-free) firmware to our
>> users, and in an ideal world we wouldn't need to. However, it's very clearly 
>> no
>> longer a sensible path when trying to support lots of common current 
>> hardware.
>>
>> Background - why has (non-free) firmware become an issue?
>> =
>>
>> Firmware is the low-level software that's designed to make hardware devices
>> work. Firmware is tightly coupled to the hardware, exposing its features,
>> providing higher-level functionality and interfaces for other software to 
>> use.
>> For a variety of reasons, it's typically not Free Software.
>>
>> For Debian's purposes, we typically separate firmware from software by
>> considering where the code executes (does it run on a separate processor? Is 
>> it
>> visible to the host OS?) but it can be difficult to define a single reliable
>> dividing line here. Consider the Intel/AMD CPU microcode packages, or the
>> U-Boot firmware packages as examples.
>>
>> In times past, all necessary firmware would normally be included directly in
>> devices / expansion cards by their vendors. Over time, however, it has become
>> more and more attractive (and therefore more common) for device manufacturers
>> to not include complete firmware on all devices. Instead, some devices just
>> embed a very simple set of firmware that allows for upload of a more complete
>> firmware "blob" into memory. Device drivers are then expected to provide that
>> blob during device initialisation.
>
> I'm from the group that defends Debian current position on this and I
> like to install only what the machine needs to work and I use free
> firmware on my machine for the wireless network card for example. I
> don't see it as a mess, but it's organized by separating what's free
> from what's not. The question of identifying what firmware my machine
> needs, this for me is easy and it was just a question I had to learn
> in the beginning many years ago. It is a problem for some and not for
> all. There is the unofficial installer that solves this problem by
> installing only what the user's machine needs without the user doing
> it himself.

I understand the urge to insist upon absolute DFSG purity in the media
we produce, but when it comes to wanting to avoid every last shred of
data that we could not regenerate ourselves, I think we crossed that
line some time ago.

I'm thinking of shim-signed, which is included in our official media.

Despite being free software in source form, it is signed by Microsoft,
and can only be expected to work with that signature ... which we cannot
create.

On most (all?) hardware one is able to avoid UEFI secure-boot, so won't
need to use shim-signed, but I'd imagine that some hardware insists on
secure-boot, or the opt-outs are somehow broken and so is not usable
without shim-signed.

This seems rather similar to the situation with non-free-firmware, which
many people can avoid the need for it, but without it some people find
our software useless on the hardware they have.

Is the presence of shim-signed on the install media enough to make
people feel somehow contaminated?

If not, is the problem having other blobs of data on the media that we
also cannot generate, or is it the licensing of that data, or something
else?

Does it make any difference that the data in question will not be read
into memory, or copied onto the target system, unless one opts-in to
using it?

Anyway, thanks to Steve for starting the discussion.

Cheers, Phil.

P.S. I think that having some (often unused) data on the media that
allows people to install our software when they'd otherwise fail is more
important than absolute purity in this case. I do not think there is an
increased risk of non-free contamination here.

If it ensures that fewer people abandon Debian out of frustration with
the install then I'd suggest that it will actually result in less
non-free software being used overall, as will having the option to
enable only non-free-firmware without also enabling non-free.

Oh, and I've been a DD for over 25 years, have been a contributor to the
installer for quite a lot of that, so I'd hope that at some point during
that time I must have succeeded in doing the add-firmware dance, if only
for testing, but wouldn't dream of relying on that as my real install
method, or recommending it to a newbie.

Frankly, it makes me wince every time I have to respond with a confusing
answer to the "What 

Re: Firmware - what are we going to do about it?

[IOhannes m zmölnig]

Am 22. April 2022 07:18:50 MESZ schrieb Andreas Tille :
>Am Thu, Apr 21, 2022 at 10:12:19AM -0700 schrieb Russ Allbery:
>> 
>> I've been a Debian Developer for quite some time and can usually manage to
>> figure out most tasks like this, and providing separate firmware to the
>> installer has completely defeated me every time I've tried it. 
 
>
>I confirm that I never ever managed to provide the needed firmware to
>the free official installer.


This is just a "me too".

(similar to Russ and Andreas) I have spent many years with Debian (~25 for me), 
and if the old folks  can't manage to use the free official installers, then I 
think/agree that it's outright hypocrisy to nudge new users into this pitfall. 

I'd be very happy with option 5, and I'm in the camp of those who like a 
strictly opt-in solution (that can be preseeded)


mfh.her.fsr
IOhannes

Re: Firmware - what are we going to do about it?

[Hakan Bayındır]

On 4/22/22 08:18, Andreas Tille wrote:

Am Thu, Apr 21, 2022 at 10:12:19AM -0700 schrieb Russ Allbery:


I've been a Debian Developer for quite some time and can usually manage to
figure out most tasks like this, and providing separate firmware to the
installer has completely defeated me every time I've tried it.  I've spent
frustrated hours trying to follow the documentation and doing things that
look right only to have the installer say that there's no firmware visible
without any clue as to how to debug the errors.  Every time I have tried
this, I have eventually given up and found the non-free images, which just
worked.

If this is going to be the solution, it has to be WAY easier to do.


I confirm that I never ever managed to provide the needed firmware to
the free official installer.  Thus my consequence was to ignore it and
just use the non-free firmware enabled installer.  I do not think that
it is sensible to let users make this experience themselves and I'm
really welcoming the effort Steve did.  Out of the original post I
prefer option 5.  Currently I don't habe time to read the whole thread
but I have spotted some sensible enhancements of option 5 that are
worth discussing.


I understand the sentiment and what you're coming from. This is also my 
experience, but it doesn't mean the process can be refined and made 
better in my opinion.


I think, regardless of the solution we have at the end, making this 
firmware introduction process work better is a nice improvement worthy 
of considering.


Cheers,

H.


Thanks a lot Steve

  Andreas.

Re: Firmware - what are we going to do about it?

[Andreas Tille]

Am Thu, Apr 21, 2022 at 10:12:19AM -0700 schrieb Russ Allbery:
> 
> I've been a Debian Developer for quite some time and can usually manage to
> figure out most tasks like this, and providing separate firmware to the
> installer has completely defeated me every time I've tried it.  I've spent
> frustrated hours trying to follow the documentation and doing things that
> look right only to have the installer say that there's no firmware visible
> without any clue as to how to debug the errors.  Every time I have tried
> this, I have eventually given up and found the non-free images, which just
> worked.
> 
> If this is going to be the solution, it has to be WAY easier to do.

I confirm that I never ever managed to provide the needed firmware to
the free official installer.  Thus my consequence was to ignore it and
just use the non-free firmware enabled installer.  I do not think that
it is sensible to let users make this experience themselves and I'm
really welcoming the effort Steve did.  Out of the original post I
prefer option 5.  Currently I don't habe time to read the whole thread
but I have spotted some sensible enhancements of option 5 that are
worth discussing.

Thanks a lot Steve

 Andreas.

-- 
http://fam-tille.de

Re: Firmware - what are we going to do about it?

[Leandro Cunha]

Hi,

On Mon, Apr 18, 2022 at 9:28 PM Steve McIntyre  wrote:
>
> TL;DR: firmware support in Debian sucks, and we need to change this. See the
> "My preference, and rationale" Section below.
>
> In my opinion, the way we deal with (non-free) firmware in Debian is a mess,
> and this is hurting many of our users daily. For a long time we've been
> pretending that supporting and including (non-free) firmware on Debian systems
> is not necessary. We don't want to have to provide (non-free) firmware to our
> users, and in an ideal world we wouldn't need to. However, it's very clearly 
> no
> longer a sensible path when trying to support lots of common current hardware.
>
> Background - why has (non-free) firmware become an issue?
> =
>
> Firmware is the low-level software that's designed to make hardware devices
> work. Firmware is tightly coupled to the hardware, exposing its features,
> providing higher-level functionality and interfaces for other software to use.
> For a variety of reasons, it's typically not Free Software.
>
> For Debian's purposes, we typically separate firmware from software by
> considering where the code executes (does it run on a separate processor? Is 
> it
> visible to the host OS?) but it can be difficult to define a single reliable
> dividing line here. Consider the Intel/AMD CPU microcode packages, or the
> U-Boot firmware packages as examples.
>
> In times past, all necessary firmware would normally be included directly in
> devices / expansion cards by their vendors. Over time, however, it has become
> more and more attractive (and therefore more common) for device manufacturers
> to not include complete firmware on all devices. Instead, some devices just
> embed a very simple set of firmware that allows for upload of a more complete
> firmware "blob" into memory. Device drivers are then expected to provide that
> blob during device initialisation.

I'm from the group that defends Debian current position on this and I
like to install only what the machine needs to work and I use free
firmware on my machine for the wireless network card for example. I
don't see it as a mess, but it's organized by separating what's free
from what's not. The question of identifying what firmware my machine
needs, this for me is easy and it was just a question I had to learn
in the beginning many years ago. It is a problem for some and not for
all. There is the unofficial installer that solves this problem by
installing only what the user's machine needs without the user doing
it himself.


--
Cheers,
Leandro Cunha
Software Engineer and Debian Contributor

Re: Firmware - what are we going to do about it?

[Jesse Rhodes]

Hi Everyone,

On Thu, 2022-04-21 at 13:52 +0800, Paul Wise wrote:

>After some discussion on #debian-www with sney (author of the current
>auto-download page)

I'm not a voting member of this organization, but since I'm mentioned by name, I
thought I would share my 0.02, if you'll have them. My background is as a
longtime debian user and support volunteer in #debian. I am very familiar with
common issues and stumbling blocks during install, and am glad to see this
firmware issue getting attention.

(re: the auto-download page, don't everyone line up to kill me at once :D, I've
written a short post [1] about that which you can read. I think that topic is
orthogonal to this one but if you want to discuss it further you can find me on
OFTC.)

In the above discussion with pabs and larjona, one thing that came up was
essentially making sure users can make informed choices. I read some expansion
of option 5 in this thread which suggested putting the yes firmware/no firmware
decision in the debian-installer boot menu; I think pabs's suggestion of
improving the visibility of that choice on the website instead could improve
user friendliness, since many people skip through boot menus without looking.
This way, the free-only image would still be available for use cases where no
firmware is required, such as VM installs, as well as any (hopefully soon-to-be
widely adopted) Free hardware such as the power9 and/or riscv stuff. And users
with run-of-the-mill amd64 PC devices would be able to clearly select the
correct installer on the first attempt.

We had also previously discussed having some scripting on the website to guess
the user's cpu architecture and suggest a matching installer; similar logic
could be used to guess whether the free or non-free image is appropriate, put
that option front and center, and have the others appear in smaller buttons
below. Either this approach or hardcoded sorting based on rough popularity
numbers would work fine, in my view. (And yes, we would disable the automatic
download as part of this.)

But I also strongly agree that non-free *firmware* and non-free *software* are
very distinct things, and as such should have separate sections in the archive,
the same way contrib is distinct from non-free. There are leagues of difference
between putting a small binary in /lib/firmware that will only ever be loaded by
the kernel, and installing, say, rar. And since ensuring that the installer
image is able to use common hardware in order to function as intended is what
we're trying to do here, putting them in fully separate sections enables this
without necessarily throwing the user into the deep end of restrictive
licenses.

And I also very much like the suggestion for a menu item in
<20220420195716.GA9369@host>. Having the firmware blobs present in the installer
image doesn't necessarily mean installing them to the system. As an example, the
reliable old Thinkpad that I'm typing this on has a bluetooth radio. I don't use
bluetooth with my laptop, and if the debian installer had asked me whether or
not to install the bluetooth firmware, I might have selected not to. At least,
I'd certainly appreciate the warning and the choice. Different drivers use
firmware to do different things, and it shouldn't be all-or-nothing.

Scenario: A 19-year-old student with a generic laptop made in 2020 that they
bought for schoolwork. It came with Windows 10 and has Realtek wifi, Broadcom
bluetooth, no ethernet, and uses a midrange AMD APU for both CPU and video.
They've heard about Free software and have maybe played with WSL, and now they
want to dive in!

The Free installer would give this person a useless black screen almost
immediately after booting, and if they managed to get a shell in single-user
mode, no network.

But with the website and installer improvements described here, it could play
out like this:

- They go to debian.org, and click Download.

- They click the front-and-center option, with iconography, that clearly
  indicates it's the best option for laptops.

- They click the dropdown and read about non-free firmware, or maybe they don't.
  They can come back to it.

- They write the image to a USB drive. [2]

- They boot the debian installer and make their software selections.

- They get to the firmware menu and make their firmware selections.

- They reboot into a fully functional Debian OS.

- Epilogue: they launch an IRC client and tell the world how smooth and amazing
  it was. ;)

Now, it's true that if there was only one official debian installer and it
included firmware, this hypothetical student would have the same result: a
functional Debian OS. But I think my scenario is better, because it gives
them more opportunities to think about firmware and what it's doing on their
system.

In any case: most of what I've read so far indicates that debian is going in
the right direction on this, and I'm excited to see what the final decision is.
I hope my perspective was useful, and thanks 

Re: Firmware - what are we going to do about it?

[Simon Richter]

Hi,

On 4/20/22 12:14 PM, Jonathan Dowland wrote:


However I think we should continue to produce install media without
non-free components, at least for a period of time after making the
switch (as another reply said, perhaps 1-2 releases and review). It
feels like me too big a step to take to stop producing DFSG-compliant
media.


Indeed that might be a rather big step, especially in light of the 
Debian Social Contract that begins with


 1. Debian will remain 100% free

   We provide the guidelines that we use to determine if a work is
   "free" in the document entitled "The Debian Free Software
   Guidelines". We promise that the Debian system and all its components
   will be free according to these guidelines. We will support people
   who create or use both free and non-free works on Debian. We will
   never make the system require the use of a non-free component.

If we wanted to have an "official" installer containing non-free 
components, I believe we would need to have a GR with a 3:1 
supermajority to change a foundation document, and then explain that 
decision in a press release.


Debian has always understood that (end) users sometimes need to use 
non-free components, but at the same time also worked towards reducing 
our users' dependence on them -- because that is how we've traditionally 
resolved conflicts between our two priorities, our users and free software.


In my opinion, it is quite defeatist to accept that some companies will 
never release free firmware or at least the documentation to allow 
others to do so; the same was said about drivers twenty years ago, and 
now we are in the rather luxurious position that there are rather few 
companies with binary-only drivers, and users are well aware that 
support for these will be spotty and Debian is not to be blamed for any 
problems.


I'd like to reach the same state for firmware.


From simply a principle perspective, that's the "pure" aim
of the project. If we continue to provide it but not on the default
path then we might be able to gather some information on how popular
or useful it is (how many downloads it attracts; or what kind of
hardware configurations it can actually be used on; perhaps cross-
referencing it with popcon or installation-report data)


The popcon result is "the majority of users will use the default."

When popcon was introduced, its purpose was to order installation media, 
and that's what it's good for, but it can't tell us what the default 
should be (otherwise I'd be questioning the decision to make systemd the 
default while the majority of systems were running sysvinit).


   Simon

Re: Firmware - what are we going to do about it?

[Moritz Mühlenhoff]

Steve McIntyre wrote:
> What would I choose to do? My personal preference would be to go with optiob 
> 5:
> split the non-free firmware into a special new component and include that on
> official media.

I fully agree with that (as mentioned before when the discussion came up).
I also believe we can stick with building only the firmware-enriched variant
to reduce complexity in the image build/testing; if anyone is concerned
about the firmware packages tools like vrms can be extended to deal with that.

Having a totally separate archive section apart from non-free (which is not
covered by security support) also allows us to include that new section in
what's supported with security updates (to the extent that is possible with
closed blobs, for some firmware there's simply not enough actionable
information).

But for the cases where it was clear and warranted we did make exceptions in
the past before (e.g. for the various microcode updates needed for 
Spectre/Meltdown
etc. and a separate archive sections allows for more clarity in that regard.

And since all firmware blobs are required to be fully re-distributable this
would also allow to enable auto-building for that new section (as opposed
to non-free where this is limited).

Cheers,
Moritz

Re: Firmware - what are we going to do about it?

[Russ Allbery]

Hakan Bayındır  writes:

> As everybody knows, Debian is also releasing the said firmware as
> compressed archives and these are visible in the download page [0],
> however usage and documentation is neither clearly documented, nor easy
> for the beginners or casual users.

> Considering most users are doing installs over USB, and official Debian
> ISOs are hybrid by default, how the following plan feels?

> 1) Document the use of ZIP files for firmware introduction during install
> more clearly and prominently,
> 2) Make these ZIP archives much more accessible via links and prominent
> placement,
> 3) Document creation of a USB drive which is both bootable and has
> writable space for extra files
> 4) Write another document detailing adding these ZIP files to the said
> media in 3,
> 5) Profit by allowing people to assemble their own installation media with
> firmware blobs if they see the need.

I've been a Debian Developer for quite some time and can usually manage to
figure out most tasks like this, and providing separate firmware to the
installer has completely defeated me every time I've tried it.  I've spent
frustrated hours trying to follow the documentation and doing things that
look right only to have the installer say that there's no firmware visible
without any clue as to how to debug the errors.  Every time I have tried
this, I have eventually given up and found the non-free images, which just
worked.

If this is going to be the solution, it has to be WAY easier to do.

-- 
Russ Allbery (r...@debian.org)  

Re: Firmware - what are we going to do about it?

[Andrey Rahmatullin]

On Thu, Apr 21, 2022 at 01:39:39PM +0300, Hakan Bayındır wrote:
> > > > > As everybody knows, Debian is also releasing the said firmware as 
> > > > > compressed
> > > > > archives and these are visible in the download page [0], however 
> > > > > usage and
> > > > > documentation is neither clearly documented, nor easy for the 
> > > > > beginners or
> > > > > casual users.
> > > > (it's documented at https://www.debian.org/releases/stable/amd64/ch06s04
> > > > for a separate drive, there may be some documentation about putting the
> > > > files to the installation drive but at that point the user should just
> > > > burn the firmware ISO)
> > > 
> > > I know it's documented, but it's buried deep down.
> > It's linked in the same yellow block on the page you linked as the archive
> > itself.
> > I mean, I agree it's not good but most of places on debian.org that are
> > related to downloading are not good. At least
> > https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/
> > is now just two clicks away from the main page.
> 
> Again, I think two clicks is too deep. A newcomer doesn't have to know the
> difference between all the files there. We're having this discussion because
> I see that the current amount of friction is seen as detrimental, and I
> agree.
Yes, my position was always "the only ISO link on the main page should be
the firmware netinst" but I understand that it's a minority one.

> > > In my ideal world (for newcomers), the link should produce the file
> > > directly, not the directory, or they get the tool, insert a USB drive, and
> > > viola.
> > They should just get the firmware ISO and burn it instead of fiddling with
> > all of that.
> 
> "The user shall do X" is not a very correct standpoint either. Even if we
> decide to add the firmware somehow into the "Official" ISOs, I still believe
> having a simple tool to do all of that is beneficial for new starters.
Providing a free ISO and a set of stuff to make it usable is strictly
worse (from the usability perspective) than providing a usable ISO right
away, and we even build the usable ISO already, we just hide it and
surround it with obsolete/hypocritical/outright false words, such as "For
convenience for some users, this unofficial alternative build includes
non-free firmware for extra support for some awkward hardware."

> If we want to have more new users or entice people who're starting to
> use/try Linux, initial barrier should be lowered.
I agree and I don't see why this should be done with a set of additional
tools instead of a directly usable ISO.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Steve McIntyre]

Andrey Rahmatullin wrote:
>
>On Wed, Apr 20, 2022 at 12:53:46PM -0500, Devin Prater wrote:
>> But back on topic, would the nonfree DVD ISO's have more firmware on them
>> than the CD version? Or is that just for offline installs?
>As far as I understand it there is just one set of non-free firmware for
>including in the ISOs and separate drives, which consists of all non-free
>firmware found in the archive.

That's definitely the intention, yes. There may be *minor* differences
in the lists that are in use in various places, as different people
have written the scripts involved. This is actually another place
where we'd benefit from the new non-free-firmware component - we'd be
able to just consistently rely on *that* list of packages.

-- 
Steve McIntyre, Cambridge, UK.st...@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

Re: Firmware - what are we going to do about it?

[Steve McIntyre]

Russ Allbery wrote:
>Steve McIntyre  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.st...@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

Re: Firmware - what are we going to do about it?

[Hakan Bayındır]

On 4/21/22 11:09, Andrey Rahmatullin wrote:

On Thu, Apr 21, 2022 at 10:57:47AM +0300, Hakan Bayındır wrote:

As everybody knows, Debian is also releasing the said firmware as compressed
archives and these are visible in the download page [0], however usage and
documentation is neither clearly documented, nor easy for the beginners or
casual users.

(it's documented at https://www.debian.org/releases/stable/amd64/ch06s04
for a separate drive, there may be some documentation about putting the
files to the installation drive but at that point the user should just
burn the firmware ISO)


I know it's documented, but it's buried deep down.

It's linked in the same yellow block on the page you linked as the archive
itself.
I mean, I agree it's not good but most of places on debian.org that are
related to downloading are not good. At least
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/
is now just two clicks away from the main page.


Again, I think two clicks is too deep. A newcomer doesn't have to know 
the difference between all the files there. We're having this discussion 
because I see that the current amount of friction is seen as 
detrimental, and I agree.



In my ideal world (for newcomers), the link should produce the file
directly, not the directory, or they get the tool, insert a USB drive, and
viola.

They should just get the firmware ISO and burn it instead of fiddling with
all of that.


"The user shall do X" is not a very correct standpoint either. Even if 
we decide to add the firmware somehow into the "Official" ISOs, I still 
believe having a simple tool to do all of that is beneficial for new 
starters.


I'm using Debian since 3.0, and I still holding my view that for a 
newcomer, Debian is a bit too clunky. It's much smoother when spends 
some time with it (I can too install it in advanced/text mode with 
muscle memory, for example).


If we want to have more new users or entice people who're starting to 
use/try Linux, initial barrier should be lowered.

Re: Firmware - what are we going to do about it?

[Paul Wise]

On Thu, 2022-04-21 at 11:12 +0200, Mattias Wadenstein wrote:

> For free software reasons, I believe that Debian should encourage this 
> method of distribution too, because it opens up the option for free 
> firmware to be developed as replacement for the non-free ones (or 
> encouraging vendors to (eventually) release their firmware under a free 
> licence). In the case of firwmare on the device, it is much harder to load 
> a free one.

Agreed, but firmware signatures are blocking free firmware in two ways:

Some hardware requires the vendor's signature and the only firmware
they have signed is proprietary firmware. The Intel/AMD CPU microcode
and nvidia GPU firmware are examples of this.

Some free firmware runs without signatures on some computers, but on
other computers the OEM requires the hardware vendor's signature on the
binaries, preventing users from modifying the firmware and loading it
on their hardware. An example of this is the Intel Sound Open Firmware
project, which requires no signatures on a select few devices (IIRC
Chromebooks) but requires Intel signatures on most devices, and Debian
packages only the Intel signed binaries.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Firmware - what are we going to do about it?

[Hakan Bayındır]

Sorry for duplicate - It was from a wrong account. Re sending just to 
ensure delivery.


---

Dear All and Steve,

I'm kinda late to the discussion, but upon reading the message, a 
possible solution has been popped into my mind.


As everybody knows, Debian is also releasing the said firmware as 
compressed archives and these are visible in the download page [0], 
however usage and documentation is neither clearly documented, nor easy 
for the beginners or casual users.


Considering most users are doing installs over USB, and official Debian 
ISOs are hybrid by default, how the following plan feels?


1) Document the use of ZIP files for firmware introduction during 
install more clearly and prominently,
2) Make these ZIP archives much more accessible via links and prominent 
placement,
3) Document creation of a USB drive which is both bootable and has 
writable space for extra files
4) Write another document detailing adding these ZIP files to the said 
media in 3,
5) Profit by allowing people to assemble their own installation media 
with firmware blobs if they see the need.


The whole process can be simplified with a simple GUI/CLI tool akin to 
GRML2USB which accepts the ISO file and burns (sic) it to a USB drive, 
and simplifying the whole process a lot. The tool can accept the ZIP 
file, or can have checkbox saying "Integrate firmware" if one decides to 
make such tool auto-downloading resources.


I think this is an acceptable compromise allowing users access the 
firmware, control on the media they have, and don't complicate matters 
relating to DFSG and other unwritten policies of Debian.


This approach also has the potential to make Debian more accessible by 
providing a valuable tool for Debian ecosystem.


As a user of Debian for over 15 years, I think DFSG, and current status 
quo is an important force for moving free software forward, and holding 
this line is important while giving the users choice and living up to 
name "Universal Operating System".


Best Regards,

Hakan Bayindir


[0]: https://www.debian.org/CD/http-ftp/#firmware
--
*Hakan BAYINDIR, Ph.D.*
Başuzman Araştırmacı
Ağ Teknolojileri Birimi
TÜBİTAK ULAKBİM - ATB
ODTÜ MODSİMMER
Üniversiteler Mahallesi, Dumlupınar Bulvarı
No:1
06800 Çankaya, ANKARA
T +90 312 298 9373
www.ulakbim.gov.tr 
hakan.bayin...@tubitak.gov.tr




Sorumluluk Reddi 

Re: Firmware - what are we going to do about it?

[Mattias Wadenstein]

On Tue, 19 Apr 2022, Steve McIntyre wrote:


TL;DR: firmware support in Debian sucks, and we need to change this. See the
"My preference, and rationale" Section below.


Agree.


In times past, all necessary firmware would normally be included directly in
devices / expansion cards by their vendors. Over time, however, it has become
more and more attractive (and therefore more common) for device manufacturers
to not include complete firmware on all devices. Instead, some devices just
embed a very simple set of firmware that allows for upload of a more complete
firmware "blob" into memory. Device drivers are then expected to provide that
blob during device initialisation.


For free software reasons, I believe that Debian should encourage this 
method of distribution too, because it opens up the option for free 
firmware to be developed as replacement for the non-free ones (or 
encouraging vendors to (eventually) release their firmware under a free 
licence). In the case of firwmare on the device, it is much harder to load 
a free one.


/Mattias Wadenstein

Re: Firmware - what are we going to do about it?

[Andrey Rahmatullin]

On Thu, Apr 21, 2022 at 10:57:47AM +0300, Hakan Bayındır wrote:
> > > As everybody knows, Debian is also releasing the said firmware as 
> > > compressed
> > > archives and these are visible in the download page [0], however usage and
> > > documentation is neither clearly documented, nor easy for the beginners or
> > > casual users.
> > (it's documented at https://www.debian.org/releases/stable/amd64/ch06s04
> > for a separate drive, there may be some documentation about putting the
> > files to the installation drive but at that point the user should just
> > burn the firmware ISO)
> 
> I know it's documented, but it's buried deep down. 
It's linked in the same yellow block on the page you linked as the archive
itself.
I mean, I agree it's not good but most of places on debian.org that are
related to downloading are not good. At least
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/
is now just two clicks away from the main page.

> In my ideal world (for newcomers), the link should produce the file
> directly, not the directory, or they get the tool, insert a USB drive, and
> viola.
They should just get the firmware ISO and burn it instead of fiddling with
all of that.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Hakan Bayındır]

Hi Andrey,

On 4/21/22 10:50, Andrey Rahmatullin wrote:

On Thu, Apr 21, 2022 at 09:57:36AM +0300, Hakan Bayındır wrote:

As everybody knows, Debian is also releasing the said firmware as compressed
archives and these are visible in the download page [0], however usage and
documentation is neither clearly documented, nor easy for the beginners or
casual users.

(it's documented at https://www.debian.org/releases/stable/amd64/ch06s04
for a separate drive, there may be some documentation about putting the
files to the installation drive but at that point the user should just
burn the firmware ISO)


I know it's documented, but it's buried deep down. I'm talking about 
reducing the so-called "click-depth" for getting the related tools and 
files.


In my ideal world (for newcomers), the link should produce the file 
directly, not the directory, or they get the tool, insert a USB drive, 
and viola.





The whole process can be simplified with a simple GUI/CLI tool akin to
GRML2USB which accepts the ISO file and burns (sic) it to a USB drive, and
simplifying the whole process a lot. The tool can accept the ZIP file, or
can have checkbox saying "Integrate firmware" if one decides to make such
tool auto-downloading resources.

Only as long as it's usable on Windows.


I'm aware, and yes, I mean the tool needs to support Windows. If 
Raspberry-Pi can have such a tool, Debian can/should have it too.


When someone knows Debian already, everything is easy, however one 
should avoid falling into this bias in my opinion. We all know our way 
around, but discussing this matter for the people who don't.


Cheers,

H.

Re: Firmware - what are we going to do about it?

[Andrey Rahmatullin]

On Thu, Apr 21, 2022 at 09:57:36AM +0300, Hakan Bayındır wrote:
> As everybody knows, Debian is also releasing the said firmware as compressed
> archives and these are visible in the download page [0], however usage and
> documentation is neither clearly documented, nor easy for the beginners or
> casual users.
(it's documented at https://www.debian.org/releases/stable/amd64/ch06s04
for a separate drive, there may be some documentation about putting the
files to the installation drive but at that point the user should just
burn the firmware ISO)

> The whole process can be simplified with a simple GUI/CLI tool akin to
> GRML2USB which accepts the ISO file and burns (sic) it to a USB drive, and
> simplifying the whole process a lot. The tool can accept the ZIP file, or
> can have checkbox saying "Integrate firmware" if one decides to make such
> tool auto-downloading resources.
Only as long as it's usable on Windows.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Thomas Goirand]

On 4/19/22 02:27, Steve McIntyre wrote:

TL;DR: firmware support in Debian sucks, and we need to change this. See the
"My preference, and rationale" Section below.


Hi Steve,

Thanks a lot for this proposal.

Like many, I agree with your option 5. In many installation (especially 
the so-many servers I setup every day at work), I've enabled non-free 
only to be able to reach the firmware I need. That's annoying, because I 
don't need anything else but firmware, and knowing all the rest is also 
available makes me feel uncomfortable.


So, definitively, having a new non-free-firmware section would be a very 
good thing and address the above concern. Having the ISO image including 
those being more visible would be great too.


Cheers,

Thomas Goirand (zigo)

Re: Firmware - what are we going to do about it?

[Hakan Bayındır]

Dear All and Steve,

I'm kinda late to the discussion, but upon reading the message, a 
possible solution has been popped into my mind.


As everybody knows, Debian is also releasing the said firmware as 
compressed archives and these are visible in the download page [0], 
however usage and documentation is neither clearly documented, nor easy 
for the beginners or casual users.


Considering most users are doing installs over USB, and official Debian 
ISOs are hybrid by default, how the following plan feels?


1) Document the use of ZIP files for firmware introduction during 
install more clearly and prominently,
2) Make these ZIP archives much more accessible via links and prominent 
placement,
3) Document creation of a USB drive which is both bootable and has 
writable space for extra files
4) Write another document detailing adding these ZIP files to the said 
media in 3,
5) Profit by allowing people to assemble their own installation media 
with firmware blobs if they see the need.


The whole process can be simplified with a simple GUI/CLI tool akin to 
GRML2USB which accepts the ISO file and burns (sic) it to a USB drive, 
and simplifying the whole process a lot. The tool can accept the ZIP 
file, or can have checkbox saying "Integrate firmware" if one decides to 
make such tool auto-downloading resources.


I think this is an acceptable compromise allowing users access the 
firmware, control on the media they have, and don't complicate matters 
relating to DFSG and other unwritten policies of Debian.


This approach also has the potential to make Debian more accessible by 
providing a valuable tool for Debian ecosystem.


As a user of Debian for over 15 years, I think DFSG, and current status 
quo is an important force for moving free software forward, and holding 
this line is important while giving the users choice and living up to 
name "Universal Operating System".


Best Regards,

Hakan Bayindir


[0]: https://www.debian.org/CD/http-ftp/#firmware
--
*Hakan BAYINDIR, Ph.D.*
Başuzman Araştırmacı
Ağ Teknolojileri Birimi
TÜBİTAK ULAKBİM - ATB
ODTÜ MODSİMMER
Üniversiteler Mahallesi, Dumlupınar Bulvarı
No:1
06800 Çankaya, ANKARA
T +90 312 298 9373
www.ulakbim.gov.tr 
hakan.bayin...@tubitak.gov.tr




Sorumluluk Reddi 

Re: Firmware - what are we going to do about it?

[Paul Wise]

On Wed, 2022-04-20 at 15:32 +0800, Paul Wise wrote:

> what other support Debian could give to libre/open firmware projects.

Some ideas for this:

We could package the libre/open firmware projects that are missing.

We could lobby hardware vendors to release their existing proprietary
firmware and hardware management software under libre licenses.

We could lobby hardware vendors to stop requiring signatures for the
existing libre/open firmware projects.

We could lobby hardware vendors to allow users to enrol their own keys
for verifying firmware.

We could use some of our money to fund new work on the existing
libre/open firmware projects.

We could initiate the creation of a new non-profit dedicated to the
reverse engineering and reimplementation of proprietary firmware.

Anything else?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Firmware - what are we going to do about it?

[Paul Wise]

On Tue, 2022-04-19 at 01:27 +0100, Steve McIntyre wrote:

> TL;DR: firmware support in Debian sucks, and we need to change this.

After some discussion on #debian-www with sney (author of the
current auto-download page) and larjona (web team), my preferred
solution to this issue looks somewhat like what is written below.

I believe this solution does not require a GR, as it balances the needs
of different segments of the Debian community and Debian's priciples.

Keep providing images without proprietary firmware, disable the
automatic download on the website download page, create a new download
page containing separate side-by-side panels catering to different
segments of the audience for installing Debian, ordered by the
sophistication of the audience and the amount of people in the
audience. Each of the panels should contain appropriate iconography and
minimal text to avoid overwhelming people; longer explanations could be
hidden behind links/dropdowns. Where the images containing proprietary
firmware images are mentioned, include an item pointing out the
non-free firmware and the limitations of Debian support for that
firmware. Some examples of the panels that could be included:

 * VMs; linking to the free images
 * libre hardware like RaptorCS's POWER9 computers; linking to the free
   images and explaining that we need help packaging the free firmware
   for those devices, since most of it isn't in Debian yet
 * desktops/laptops; linking to the non-free images
 * smartphones/tablets; linking to Mobian images
 * clouds; linking to the cloud images
 * servers; linking to the non-free images
 * Windows; linking to the Debian WSL app and win32-loader
 * SBCs; linking to some relevant info on the wiki
 * Raspberry Pi; linking to the RPi non-free images

If the Debian CD/live teams don't want to test the free images, then
those teams should feel free to stop testing them, and call for other
people to do that work.

If the Debian CD/live teams don't want to build the free images, then
that would pose a problem for people who don't want to download or
redistribute non-free firmware. I think there are enough of these
people that the opportunity to hand over building the free images to a
separate team would be needed.

I feel that the above is a good balance of preventing the problems
pointed out in your mail (along with some other ones), while not
completely fixing all of them due to the conflict with the needs of the
segment of Debian users who want to not have non-free firmware and then
mitigating that through the creation of a separate team for that. 

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Firmware - what are we going to do about it?

[Sam Hartman]

> "Russ" == Russ Allbery  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.

Re: Firmware - what are we going to do about it?

[nervuri]

The Debian Social Contract begins with "Debian will remain 100% free".
Changing that is a pretty big deal.  Debian's principled stance on free
software has been one of the main reasons I've been using it for almost
a decade.  I really appreciate the peace of mind of knowing that the
system is 100% free by default.  However, I do use specific non-free
firmware packages for certain devices and it is a pain to find and
install them (which I do by hand, after installing Debian from the
official ISO).

All in all, I'm on board with option 5.  By all means, create the
non-free-firmware archive and include it in the official media.  But
also make it clear to users why proprietary firmware ought to be
avoided.  Add a prompt during installation (similar to the software
selection prompt) and make the best of the educational opportunity that
it provides.  It can begin with a statement on why the Debian Project is
against non-free *ware and it can also mention the security benefits
(and potential pitfalls) of packages like intel-microcode.  Something
like:

```
The hardware devices listed below currently require non-free firmware to
function.  The Debian project advises against the installation of
non-free firmware [insert reasons here], while acknowledging that some
users may require such firmware to use certain devices or to receive
security updates from device vendors.

Select which devices you wish to install non-free firmware for:

  [ ] CPU (device name)
  [ ] Wi-Fi (device name)
  [ ] Bluetooth (device name)
  [ ] Fingerprint reader (device name)

You can change this selection at any time by running [command].  You can
also disable the use of all non-free firmware by selecting the [...]
boot option.
```

Something along these lines would be ideal, I think.

Re: Firmware - what are we going to do about it?

[Steve Langasek]

Thanks for starting this discussion, Steve, I appreciate the care you've put
into laying out the options.

On Tue, Apr 19, 2022 at 01:27:46AM +0100, Steve McIntyre wrote:

>  3. We could stop pretending that the non-free images are unofficial, and
> maybe move them alongside the normal free images so they're published
> together.  This would make them easier to find for people that need
> them, but is likely to cause users to question why we still make any
> images without firmware if they're otherwise identical.

>  4. The images team technically could simply include non-free into the 
> official
> images, and add firmware packages to the input lists for those images.
> However, that would still leave us with problem 3 from above (non-free
> generally enabled on most installations).

>  5. We could split out the non-free firmware packages into a new
> non-free-firmware component in the archive, and allow a specific exception
> only to allow inclusion of those packages on our official media. We would
> then generate only one set of official media, including those non-free
> firmware packages.

> (We've already seen various suggestions in recent years to split up the
> non-free component of the archive like this, for example into
> non-free-firmware, non-free-doc, non-free-drivers, etc. Disagreement
> (bike-shedding?) about the split caused us to not make any progress on
> this. I believe this project should be picked up and completed. We don't
> have to make a perfect solution here immediately, just something that 
> works
> well enough for our needs today. We can always tweak and improve the setup
> incrementally if that's needed.)

I am personally comfortable with your preferred option 5, for all the
described reasons (does not reduce user net freedom vs. status quo ante when
the firmware was both non-free and non-updatable, etc etc etc).

However, and I know that I'm suggesting work for other people here: one
thing that has surprised me over the years this question has been open is
that no one who has strong feelings about this issue has taken it upon
themselves to refactor the images so that the non-free firmware is
distributed as an add-on image that could be discovered by the installer at
runtime.  This would preserve the ability to have entirely-free media under
Debian's definition thereof, while also giving users a clearer path to
installing any necessary firmware without having to re-download a separate
image.

And sometimes having 2 separate USB sticks for an install is an
inconvenience, so perhaps someone wants to be particularly clever and give
the installer an appropriately-sized empty partition in the partition table
that the firmware bits could be blatted into.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Andrey Rahmatullin]

On Wed, Apr 20, 2022 at 12:53:46PM -0500, Devin Prater wrote:
> But back on topic, would the nonfree DVD ISO's have more firmware on them
> than the CD version? Or is that just for offline installs?
As far as I understand it there is just one set of non-free firmware for
including in the ISOs and separate drives, which consists of all non-free
firmware found in the archive.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Devin Prater]

Sorry, that was rather strongly worded. Although, I think if we just keep
accessibility in mind, from the desktop environment to the boot process,
Debian is already far beyond other distros. Arch comes close, but one has
to know when the boot process begins in order to press Down arrow then
Enter to begin the accessible installer, and then one has to install stuff
like alsa-utils and espeakup to have an accessible console and such, as of
like six months ago.

But back on topic, would the nonfree DVD ISO's have more firmware on them
than the CD version? Or is that just for offline installs?
Devin Prater
r.d.t.pra...@gmail.com




On Wed, Apr 20, 2022 at 11:39 AM Steve Langasek  wrote:

> On Wed, Apr 20, 2022 at 09:51:01AM -0500, Devin Prater wrote:
> > Anyways, if we want to gatekeep Debian, then fine.
>
> The person you're replying to is not a member of the Debian Project and
> does
> not speak for us.
>
> We are not all accessibility experts, but Debian as a community has always
> supported the efforts of those who are, to make Debian as usable as
> possible
> with accessibility technologies.
>
> Please don't assume the hostility of the previous messages is in any way
> representative of Debian.  (And, that being the case, I would suggest it's
> unnecessary to engage with.)
>
> > On Wed, Apr 20, 2022 at 8:08 AM Polyna-Maude Racicot-Summerside <
> > deb...@polynamaude.com> wrote:
> >
> > > Hi,
> > >
> > > On 2022-04-20 08:39, Samuel Thibault wrote:
> > > > Hello,
> > > >
> > > > Polyna-Maude Racicot-Summerside, le mer. 20 avril 2022 08:32:13
> -0400, a
> > > ecrit:
> > > >> Answer bellow this awful piece of text from someone who doesn't
> know how
> > > >> to make a space between line.
> > > >
> > > > For information, reading mails with a speech synthesis doesn't
> > > > necessarily render spaces between lines.
> > > >
> > > > So yes, people using them don't actually "see" the need for such
> > > > spacing.
> > > >
> > > When you talk or read a text out loud, you make pauses ?
> > > Why wouldn't they apply then you write a text ?
> > > Are we again in the world of "Everyone must adapt because I'm
> different" ?
> > >
> > > We ain't gonna go back to this WOKE thinking and "positive
> > > discrimination bullshit", please no !
> > > > Samuel
> > > >
> > >
> > > --
> > > Polyna-Maude R.-Summerside
> > > -Be smart, Be wise, Support opensource development
> > >
> > >
>
> --
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> Ubuntu Developer   https://www.debian.org/
> slanga...@ubuntu.com vor...@debian.org
>

Re: Firmware - what are we going to do about it?

[Russ Allbery]

Steve McIntyre  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 (r...@debian.org)  

Re: Firmware - what are we going to do about it?

[Andrey Rahmatullin]

On Wed, Apr 20, 2022 at 05:04:13AM -0500, Devin Prater wrote:
> So then, I found the Non-free section and got the CD version? I guess
> that's what I should have gotten? The DVD one is the live environment
> right? See how confusion this can be? 
Yes, the variety of our ISOs and the poor way they are presented to the
user is already a significant problem even before considering official and
non-free ones.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Steve McIntyre]

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.st...@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

Re: Firmware - what are we going to do about it?

[Steve Langasek]

On Wed, Apr 20, 2022 at 09:51:01AM -0500, Devin Prater wrote:
> Anyways, if we want to gatekeep Debian, then fine.

The person you're replying to is not a member of the Debian Project and does
not speak for us.

We are not all accessibility experts, but Debian as a community has always
supported the efforts of those who are, to make Debian as usable as possible
with accessibility technologies.

Please don't assume the hostility of the previous messages is in any way
representative of Debian.  (And, that being the case, I would suggest it's
unnecessary to engage with.)

> On Wed, Apr 20, 2022 at 8:08 AM Polyna-Maude Racicot-Summerside <
> deb...@polynamaude.com> wrote:
> 
> > Hi,
> >
> > On 2022-04-20 08:39, Samuel Thibault wrote:
> > > Hello,
> > >
> > > Polyna-Maude Racicot-Summerside, le mer. 20 avril 2022 08:32:13 -0400, a
> > ecrit:
> > >> Answer bellow this awful piece of text from someone who doesn't know how
> > >> to make a space between line.
> > >
> > > For information, reading mails with a speech synthesis doesn't
> > > necessarily render spaces between lines.
> > >
> > > So yes, people using them don't actually "see" the need for such
> > > spacing.
> > >
> > When you talk or read a text out loud, you make pauses ?
> > Why wouldn't they apply then you write a text ?
> > Are we again in the world of "Everyone must adapt because I'm different" ?
> >
> > We ain't gonna go back to this WOKE thinking and "positive
> > discrimination bullshit", please no !
> > > Samuel
> > >
> >
> > --
> > Polyna-Maude R.-Summerside
> > -Be smart, Be wise, Support opensource development
> >
> >

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Ansgar]

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

Re: Firmware - what are we going to do about it?

[Steve McIntyre]

Russ Allbery wrote:
>Jonas Smedegaard  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.st...@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

Re: Firmware - what are we going to do about it?

[Steve McIntyre]

Paul Wise wrote:
>
>On Tue, 2022-04-19 at 01:27 +0100, Steve McIntyre wrote:
>
>> There are a number of issues here that make developers and users unhappy:
>
>There are a couple more issues related to unredistributable firmware:

Oh, I'm quite sure there are more than that even! :-)

>Some firmware is only available in the operating system preinstalled on
>the device and needs to be manually extracted before d-i is run,
>potentially even only from processes running on the preinstalled
>operating system in cases where the storage must be wiped (such as
>Android devices) before an alternative OS like Debian can be installed.
>IIRC there is some laptop WiFi firmware that is like this.

Yup.

>Some firmware is not redistributable and is only available in
>proprietary drivers on websites and is hard to extract from those
>drivers. IIRC some of the proprietary nvidia firmware for use by the
>libre nouveau GPU driver is like this, both signed firmware for very
>new nvidia hardware and unsigned firmware for very old nvidia hardware,
>although the firmware for the old nvidia hardware has libre firmware in
>nouveau, but the libre firmware is/was buggier than the proprietary
>firmware. The tools for extracting the old firmware aren't in Debian. 

Yup.

I don't see us fixing *all* of these issues any time soon. But in
those cases where we *can* redistribute firmware we can make things
easier for users who need it.

And *then* we can explain to them why the non-free firmware is bad for
their freedom, with examples of what they can do to improve things.

-- 
Steve McIntyre, Cambridge, UK.st...@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

Re: Firmware - what are we going to do about it?

[Steve McIntyre]

Hi Polyna-Maude,

Polyna-Maude R.-Summerside wrote:
>bwt !
>1st I've always saw Debian having brltty support from the start
>2nd Just install the firmware instruction here and your problem will be
>solved.
>https://wiki.debian.org/Firmware
>
>Stop blaiming other people when the problem is a lack of research on
>your part and expectation all work "out of the box" in all situation.
>
>Take destiny into your own hand.

Please tone your argument down here.

As developers we're having a discussion about how to make things work
better and more easily for our users. Devin's description of the
troubles they had are entirely on-topic and useful in the context of
that discussion. Castigating them here is *not* helpful.

-- 
Steve McIntyre, Cambridge, UK.st...@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

Re: Firmware - what are we going to do about it?

[Steve McIntyre]

Jeremy Stanley wrote:
>On 2022-04-19 01:27:46 +0100 (+0100), Steve McIntyre wrote:
>[...]
>> Along with adding non-free firmware onto media, when the installer
>> (or live image) runs, we should make it clear exactly which
>> firmware packages have been used/installed to support detected
>> hardware. We could link to docs about each, and maybe also to
>> projects working on Free re-implementations.
>[...]
>
>It's probably what you meant, but just to be clear, as a user I'd
>also want to know which of the firmware packages used/installed were
>pulled from non-free and what devices prompted their addition.
>Something like "The following packages do not meet Debian Free
>Software Guidelines but were installed because they're necessary in
>order to enable or secure some of your hardware: foo(CPUX21
>processor microcode), bar(PM2743 power management controller),
>baz(RF17G wireless interface), ..."
>
>This would allow me to make better informed decisions, such as:
>
>1. Disable some of these devices if I don't actually use them.
>
>2. Seek out alternative open peripherals which do work without
>proprietary firmware.
>
>3. Reach out to the manufacturer of my device and extol the virtues
>of open firmware.
>
>4. Consider (as you mentioned) working on my own reimplementation.

Nod, that's exactly what I was suggesting. More information for users
here helps them to make decisions like this, absolutely.

-- 
Steve McIntyre, Cambridge, UK.st...@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

Re: Firmware - what are we going to do about it?

[Devin Prater]

Oh, so that's the kind of person you are. Good. I can dismiss your cranky
attitude then. Okay, so the common way of doing this *is* to put a blank
space between paragraphis then? I was told otherwise, but I'm so used to
working with Markdown that I still do it. I just thought I'd make things
look less Markdown-ish on a group full of sighted people that might see a
big blank space instead of a new paragraph.

Anyways, if we want to gatekeep Debian, then fine. Only advanced users will
read up on what firmware is supported, *buy* a laptop with those specs
(which will probably be online (not at Walmart and such)), and if they
don't have the money, figure out how to see or hear their computer long
enough to install needed packages. Great.

Devin Prater
r.d.t.pra...@gmail.com




On Wed, Apr 20, 2022 at 8:08 AM Polyna-Maude Racicot-Summerside <
deb...@polynamaude.com> wrote:

> Hi,
>
> On 2022-04-20 08:39, Samuel Thibault wrote:
> > Hello,
> >
> > Polyna-Maude Racicot-Summerside, le mer. 20 avril 2022 08:32:13 -0400, a
> ecrit:
> >> Answer bellow this awful piece of text from someone who doesn't know how
> >> to make a space between line.
> >
> > For information, reading mails with a speech synthesis doesn't
> > necessarily render spaces between lines.
> >
> > So yes, people using them don't actually "see" the need for such
> > spacing.
> >
> When you talk or read a text out loud, you make pauses ?
> Why wouldn't they apply then you write a text ?
> Are we again in the world of "Everyone must adapt because I'm different" ?
>
> We ain't gonna go back to this WOKE thinking and "positive
> discrimination bullshit", please no !
> > Samuel
> >
>
> --
> Polyna-Maude R.-Summerside
> -Be smart, Be wise, Support opensource development
>
>

Re: Firmware - what are we going to do about it?

[Jonathan Dowland]

On Wed, Apr 20, 2022 at 09:07:47AM -0400, Polyna-Maude Racicot-Summerside wrote:

When you talk or read a text out loud, you make pauses ?
Why wouldn't they apply then you write a text ?
Are we again in the world of "Everyone must adapt because I'm different" ?

We ain't gonna go back to this WOKE thinking and "positive
discrimination bullshit", please no !


Even IF it was your job to police other people's communication style on
Debian lists, you are really throwing stones in glass houses. Please,
refrain from complaining about someone's posting style ON LIST at least.

--
Please do not CC me for listmail.

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Re: Firmware - what are we going to do about it?

[Samuel Thibault]

Polyna-Maude Racicot-Summerside, le mer. 20 avril 2022 09:07:47 -0400, a ecrit:
> On 2022-04-20 08:39, Samuel Thibault wrote:
> > Polyna-Maude Racicot-Summerside, le mer. 20 avril 2022 08:32:13 -0400, a 
> > ecrit:
> >> Answer bellow this awful piece of text from someone who doesn't know how
> >> to make a space between line.
> > 
> > For information, reading mails with a speech synthesis doesn't
> > necessarily render spaces between lines.
> > 
> > So yes, people using them don't actually "see" the need for such
> > spacing.
> 
> When you talk or read a text out loud, you make pauses ?
> Why wouldn't they apply then you write a text ?

Because it's difficult for software to divine whether line breaks are
really meant to be flow break or not.

Help on this really welcome.  Bullshit words are not welcome.

Samuel

Re: Firmware - what are we going to do about it?

[Polyna-Maude Racicot-Summerside]

Hi,

On 2022-04-20 08:39, Samuel Thibault wrote:
> Hello,
> 
> Polyna-Maude Racicot-Summerside, le mer. 20 avril 2022 08:32:13 -0400, a 
> ecrit:
>> Answer bellow this awful piece of text from someone who doesn't know how
>> to make a space between line.
> 
> For information, reading mails with a speech synthesis doesn't
> necessarily render spaces between lines.
> 
> So yes, people using them don't actually "see" the need for such
> spacing.
> 
When you talk or read a text out loud, you make pauses ?
Why wouldn't they apply then you write a text ?
Are we again in the world of "Everyone must adapt because I'm different" ?

We ain't gonna go back to this WOKE thinking and "positive
discrimination bullshit", please no !
> Samuel
> 

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development

Re: Firmware - what are we going to do about it?

[Samuel Thibault]

Hello,

Polyna-Maude Racicot-Summerside, le mer. 20 avril 2022 08:32:13 -0400, a ecrit:
> Answer bellow this awful piece of text from someone who doesn't know how
> to make a space between line.

For information, reading mails with a speech synthesis doesn't
necessarily render spaces between lines.

So yes, people using them don't actually "see" the need for such
spacing.

Samuel

Re: Firmware - what are we going to do about it?

[Paul Wise]

On Tue, 2022-04-19 at 01:27 +0100, Steve McIntyre wrote:

> There are a number of issues here that make developers and users unhappy:

There are a couple more issues related to unredistributable firmware:

Some firmware is only available in the operating system preinstalled on
the device and needs to be manually extracted before d-i is run,
potentially even only from processes running on the preinstalled
operating system in cases where the storage must be wiped (such as
Android devices) before an alternative OS like Debian can be installed.
IIRC there is some laptop WiFi firmware that is like this.

Some firmware is not redistributable and is only available in
proprietary drivers on websites and is hard to extract from those
drivers. IIRC some of the proprietary nvidia firmware for use by the
libre nouveau GPU driver is like this, both signed firmware for very
new nvidia hardware and unsigned firmware for very old nvidia hardware,
although the firmware for the old nvidia hardware has libre firmware in
nouveau, but the libre firmware is/was buggier than the proprietary
firmware. The tools for extracting the old firmware aren't in Debian. 

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Firmware - what are we going to do about it?

[Polyna-Maude Racicot-Summerside]

bwt !
1st I've always saw Debian having brltty support from the start
2nd Just install the firmware instruction here and your problem will be
solved.
https://wiki.debian.org/Firmware

Stop blaiming other people when the problem is a lack of research on
your part and expectation all work "out of the box" in all situation.

Take destiny into your own hand.

On 2022-04-20 08:32, Polyna-Maude Racicot-Summerside wrote:
> Answer bellow this awful piece of text from someone who doesn't know how
> to make a space between line.
> 
> On 2022-04-20 06:04, Devin Prater wrote:
>> I recently tried to install Debian onto my new laptop. It's an HP
>> Pavilian (can't remember the exact model sorry) with an AMD Rizon 5500
>> processor with integrated Radion graphic. All seemed to work well, until
>> I came to the detecting Internet stage of the install. It couldn't
>> detect my Wi-fi card. So then, I found the Non-free section and got the
>> CD version? I guess that's what I should have gotten? The DVD one is the
>> live environment right? See how confusion this can be? Anyway, I booted
>> that up, pressed s then Enter cause I'm blind, then began the install
>> again. The same thing happened. So apparently even the non-free images
>> don't contain all of the drivers. I know a driver for my card exists,
>> since Fedora has it. So, since Debian "won't work" on my system (that's
>> what a user *will* think), I went back to Windows, where I have all the
>> few games blind people can play, the MUD clients with sound packs,
>> Twitter/Mastodon/Telegram clients that were made by the blind, for the
>> blind, a screen reader with wide community support, and a DE with
>> developers focusingon accessibility. Of course, that's just my use case
>> as a blind person. Others may focus on the graphics card, Wi-fi, sound
>> card, power management (My battery will never run out of power according
>> to acpi), or CPU management.
>> Ah well. Maybe Ubuntu will have the Wi-fi card. I mean they are a
>> company but when a group of regular people don't give something that I
>> can even install without plugging in my phone, finishing install,
>> somehow finding the right driver for my Wi-fi card, and then finally
>> being able to use it, then the first thing people will do is go find
>> something else. They'll say "Okay well Debian is just for servers and
>> 'FossBros'," shake their head, and move on.
>> This is from a user's perspective. It's hard enough to get them to want
>> to use Linux. A lot of people don't even know you can change the
>> operating system on your computer! So then for them to try Debian, which
>> is probably one of, if not the most, accessible of all distros thanks to
>> our few Debian Accessibility team, and then find that their network card
>> isn't going to work, they'll run back to Windows. And to be clear, for a
>> blind person, the only thing Linux has over Windows at this point is
>> that you can print text *and* images to a Braille printer. You can't do
>> that in Windows without expensive software. All the games, software for
>> the blind, Twitter/Mastodon/Telegram clients, all that is on Windows. So
>> for a blind person, switching from all that is gonna be even harder. So
>> the first sign of resistance will send them back.
>> Also, should we have to work for Debian? Shouldn't it make our computing
>> life easier by at least including the stuff we need to use all parts of
>> our computer? Besides that, with computers becoming even more "secure"
>> with Microsoft working on a chip, AMD and Intel having their stuff,
>> we'll *have* to include nonfree stuff in Debian eventually. Might as
>> well do it now to make users' lives a little easier for practice.
>> Another thing I just thought of, I wonder if, when we find hardware in
>> the installer that we don't have drivers for, if we can search for
>> drivers on apt, including the nonfree section, and ask if the user wants
>> to install them? The user would probably have to connect their phone for
>> the Wi-fi bit, but then all the stuff could easily be installed.
>> Devin Prater
>> r.d.t.pra...@gmail.com 
>>
>>
>>
>>
>> On Wed, Apr 20, 2022 at 2:49 AM Pirate Praveen > > wrote:
>>
>>
>>
>> 2022, ഏപ്രിൽ 19 5:57:46 AM IST, Steve McIntyre > >ൽ എഴുതി
>> >This tension extends to our installation and live media. As non-free is
>> >officially not considered part of Debian, our official media cannot
>> include
>> >anything from non-free. This has been a deliberate policy for many
>> years.
>> >Instead, we have for some time been building a limited parallel set of
>> >"unofficial non-free" images which include non-free firmware. These
>> non-free
>> >images are produced by the same software that we use for the
>> official images,
>> >and by the same team.
>> >
>> >There are a number of issues here that make developers and users
>>  

Re: Firmware - what are we going to do about it?

[Polyna-Maude Racicot-Summerside]

Answer bellow this awful piece of text from someone who doesn't know how
to make a space between line.

On 2022-04-20 06:04, Devin Prater wrote:
> I recently tried to install Debian onto my new laptop. It's an HP
> Pavilian (can't remember the exact model sorry) with an AMD Rizon 5500
> processor with integrated Radion graphic. All seemed to work well, until
> I came to the detecting Internet stage of the install. It couldn't
> detect my Wi-fi card. So then, I found the Non-free section and got the
> CD version? I guess that's what I should have gotten? The DVD one is the
> live environment right? See how confusion this can be? Anyway, I booted
> that up, pressed s then Enter cause I'm blind, then began the install
> again. The same thing happened. So apparently even the non-free images
> don't contain all of the drivers. I know a driver for my card exists,
> since Fedora has it. So, since Debian "won't work" on my system (that's
> what a user *will* think), I went back to Windows, where I have all the
> few games blind people can play, the MUD clients with sound packs,
> Twitter/Mastodon/Telegram clients that were made by the blind, for the
> blind, a screen reader with wide community support, and a DE with
> developers focusingon accessibility. Of course, that's just my use case
> as a blind person. Others may focus on the graphics card, Wi-fi, sound
> card, power management (My battery will never run out of power according
> to acpi), or CPU management.
> Ah well. Maybe Ubuntu will have the Wi-fi card. I mean they are a
> company but when a group of regular people don't give something that I
> can even install without plugging in my phone, finishing install,
> somehow finding the right driver for my Wi-fi card, and then finally
> being able to use it, then the first thing people will do is go find
> something else. They'll say "Okay well Debian is just for servers and
> 'FossBros'," shake their head, and move on.
> This is from a user's perspective. It's hard enough to get them to want
> to use Linux. A lot of people don't even know you can change the
> operating system on your computer! So then for them to try Debian, which
> is probably one of, if not the most, accessible of all distros thanks to
> our few Debian Accessibility team, and then find that their network card
> isn't going to work, they'll run back to Windows. And to be clear, for a
> blind person, the only thing Linux has over Windows at this point is
> that you can print text *and* images to a Braille printer. You can't do
> that in Windows without expensive software. All the games, software for
> the blind, Twitter/Mastodon/Telegram clients, all that is on Windows. So
> for a blind person, switching from all that is gonna be even harder. So
> the first sign of resistance will send them back.
> Also, should we have to work for Debian? Shouldn't it make our computing
> life easier by at least including the stuff we need to use all parts of
> our computer? Besides that, with computers becoming even more "secure"
> with Microsoft working on a chip, AMD and Intel having their stuff,
> we'll *have* to include nonfree stuff in Debian eventually. Might as
> well do it now to make users' lives a little easier for practice.
> Another thing I just thought of, I wonder if, when we find hardware in
> the installer that we don't have drivers for, if we can search for
> drivers on apt, including the nonfree section, and ask if the user wants
> to install them? The user would probably have to connect their phone for
> the Wi-fi bit, but then all the stuff could easily be installed.
> Devin Prater
> r.d.t.pra...@gmail.com 
> 
> 
> 
> 
> On Wed, Apr 20, 2022 at 2:49 AM Pirate Praveen  > wrote:
> 
> 
> 
> 2022, ഏപ്രിൽ 19 5:57:46 AM IST, Steve McIntyre  >ൽ എഴുതി
> >This tension extends to our installation and live media. As non-free is
> >officially not considered part of Debian, our official media cannot
> include
> >anything from non-free. This has been a deliberate policy for many
> years.
> >Instead, we have for some time been building a limited parallel set of
> >"unofficial non-free" images which include non-free firmware. These
> non-free
> >images are produced by the same software that we use for the
> official images,
> >and by the same team.
> >
> >There are a number of issues here that make developers and users
> unhappy:
> >
> > 1. Building, testing and publishing two sets of images takes more
> effort.
> 
> Can we reduce the tests? Do we really need to test both images for
> all cases?
> 
> > 2. We don't really want to be providing non-free images at all, from a
> >    philosophy point of view. So we mainly promote and advertise
> the preferred
> >    official free images. That can be a cause of confusion for
> users. We do
> >    link to the 

Re: Firmware - what are we going to do about it?

[Russell Stuart]

On 19/4/22 10:27, Steve McIntyre wrote:

  5. We could split out the non-free firmware packages into a new
 non-free-firmware component in the archive, and allow a specific exception
 only to allow inclusion of those packages on our official media. We would
 then generate only one set of official media, including those non-free
 firmware packages.


The motivation here for splitting non-free firmware into a separate 
component is so we can install Debian on modern hardware.  That's a good 
reason, but I've always thought there was at least one other good reason.


It doesn't belong in Debian.

Unlike everything else, we usually don't have the source, which neuters 
many of the nice security properties inherent with open source.  We 
don't compile it, because even if we did have the source it's probably 
for a CPU & silicon we don't support.  Ergo reproducible builds are out 
of the question: it could literally contain, copy or do anything the 
hardware allows and none of us would be the wiser.  Peculiarly, we don't 
care about the licence, beyond being allowed to distribute it in the 
first place.


One of Debian's foundations is the DFSG but when it comes to this stuff, 
freedoms?  We don't even have the freedom to avoid it.  I'm genuinely 
surprised the project has managed to be in denial and pretend it had a 
choice for this long.


In short non-free packages we have the source for is one thing.  These 
binary opaque blobs are quite another.  They should be in a different 
component.  Non-free-firmware sounds far too innocent to me.  How about 
"not-debian", or "under-sufference".


OpenPGP_0xF5231C62E7843A8C.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Firmware - what are we going to do about it?

[Jonathan Dowland]

Hi Steve,

Thank you for raising this issue and writing about it so clearly.

On Tue, Apr 19, 2022 at 01:27:46AM +0100, Steve McIntyre wrote:

5. We could split out the non-free firmware packages into a new
   non-free-firmware component in the archive, and allow a specific
   exception only to allow inclusion of those packages on our official
   media. We would then generate only one set of official media,
   including those non-free firmware packages.


My preference is a variation on Option 5: Effectively, a two-phase
version of it. I think we should produce installer media including
the non-free firmware and for that to be the media that people are
directed to, in the most part, via the normal routes (default path
on website, etc.¹)

However I think we should continue to produce install media without
non-free components, at least for a period of time after making the
switch (as another reply said, perhaps 1-2 releases and review). It
feels like me too big a step to take to stop producing DFSG-compliant
media.  From simply a principle perspective, that's the "pure" aim
of the project. If we continue to provide it but not on the default
path then we might be able to gather some information on how popular
or useful it is (how many downloads it attracts; or what kind of
hardware configurations it can actually be used on; perhaps cross-
referencing it with popcon or installation-report data)

I'd also like to see us put a bit more effort into tools like vrms²
so we can make it easier for folks to gauge how much non-free stuff
they are relying upon and maybe even work towards offering tailored
alternatives. (For example I've currently got an Nvidia GPU and the
binary blob drivers installed, for the first time in over a decade,
and I could do with some hand-holding to identify an alternative
which would not require non-free drivers and/or firmware.)


¹ I agree with another person in this thread that the current behaviour
  of auto-downloading an ISO after visiting /download is wrong and
  should be changed, but, that is orthogonal to what you have raised
  and should be addressed separately.

² perhaps starting with renaming it…


--
Please do not CC me for listmail.

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Re: Firmware - what are we going to do about it?

[Jonathan Dowland]

On Tue, Apr 19, 2022 at 01:43:39PM +0200, Christian Kastner wrote:

In case my own wasn't clear, what I meant was: (a) all of the x86_64
hosts in our infrastructure use CPUs that utilize non-free microcode,
and (b) unless we're crazy, those hosts also use the non-free
intel-microcode or amd64-microcode packages to get security fixes.


I hadn't even noticed that there was an amd64-microcode package.
Although I see that it is older than my CPU (3945WX), so I'm not sure
that it is (yet) a problem (for me). That said…


Here's an even more radical thought: shipping any x86_64 installer CD
without amd64-microcode and intel-microcode installed by default is a
disservice to our users. There's no ideological "Win" when you're paying
for it with the user's security, especially when they might be unaware
of the problem.


I can agree with that, but I think that's a bridge to cross *after* the
change proposed by Steve.


--
Please do not CC me for listmail.

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Re: Firmware - what are we going to do about it?

[Devin Prater]

I recently tried to install Debian onto my new laptop. It's an HP
Pavilian (can't remember the exact model sorry) with an AMD Rizon 5500
processor with integrated Radion graphic. All seemed to work well, until I
came to the detecting Internet stage of the install. It couldn't detect my
Wi-fi card. So then, I found the Non-free section and got the CD version? I
guess that's what I should have gotten? The DVD one is the live environment
right? See how confusion this can be? Anyway, I booted that up, pressed s
then Enter cause I'm blind, then began the install again. The same thing
happened. So apparently even the non-free images don't contain all of the
drivers. I know a driver for my card exists, since Fedora has it. So, since
Debian "won't work" on my system (that's what a user *will* think), I went
back to Windows, where I have all the few games blind people can play, the
MUD clients with sound packs, Twitter/Mastodon/Telegram clients that were
made by the blind, for the blind, a screen reader with wide community
support, and a DE with developers focusingon accessibility. Of course,
that's just my use case as a blind person. Others may focus on the graphics
card, Wi-fi, sound card, power management (My battery will never run out of
power according to acpi), or CPU management.
Ah well. Maybe Ubuntu will have the Wi-fi card. I mean they are a company
but when a group of regular people don't give something that I can even
install without plugging in my phone, finishing install, somehow finding
the right driver for my Wi-fi card, and then finally being able to use it,
then the first thing people will do is go find something else. They'll say
"Okay well Debian is just for servers and 'FossBros'," shake their head,
and move on.
This is from a user's perspective. It's hard enough to get them to want to
use Linux. A lot of people don't even know you can change the operating
system on your computer! So then for them to try Debian, which is probably
one of, if not the most, accessible of all distros thanks to our few Debian
Accessibility team, and then find that their network card isn't going to
work, they'll run back to Windows. And to be clear, for a blind person, the
only thing Linux has over Windows at this point is that you can print text
*and* images to a Braille printer. You can't do that in Windows without
expensive software. All the games, software for the blind,
Twitter/Mastodon/Telegram clients, all that is on Windows. So for a blind
person, switching from all that is gonna be even harder. So the first sign
of resistance will send them back.
Also, should we have to work for Debian? Shouldn't it make our computing
life easier by at least including the stuff we need to use all parts of our
computer? Besides that, with computers becoming even more "secure" with
Microsoft working on a chip, AMD and Intel having their stuff, we'll *have*
to include nonfree stuff in Debian eventually. Might as well do it now to
make users' lives a little easier for practice.
Another thing I just thought of, I wonder if, when we find hardware in the
installer that we don't have drivers for, if we can search for drivers on
apt, including the nonfree section, and ask if the user wants to install
them? The user would probably have to connect their phone for the Wi-fi
bit, but then all the stuff could easily be installed.
Devin Prater
r.d.t.pra...@gmail.com




On Wed, Apr 20, 2022 at 2:49 AM Pirate Praveen 
wrote:

>
>
> 2022, ഏപ്രിൽ 19 5:57:46 AM IST, Steve McIntyre ൽ എഴുതി
> >This tension extends to our installation and live media. As non-free is
> >officially not considered part of Debian, our official media cannot
> include
> >anything from non-free. This has been a deliberate policy for many years.
> >Instead, we have for some time been building a limited parallel set of
> >"unofficial non-free" images which include non-free firmware. These
> non-free
> >images are produced by the same software that we use for the official
> images,
> >and by the same team.
> >
> >There are a number of issues here that make developers and users unhappy:
> >
> > 1. Building, testing and publishing two sets of images takes more effort.
>
> Can we reduce the tests? Do we really need to test both images for all
> cases?
>
> > 2. We don't really want to be providing non-free images at all, from a
> >philosophy point of view. So we mainly promote and advertise the
> preferred
> >official free images. That can be a cause of confusion for users. We
> do
> >link to the non-free images in various places, but they're not so
> easy to
> >find.
>
> I'm fine making it easier to find.
>
> > 3. Using non-free installation media will cause more installations to use
> >non-free software by default. That's not a great story for us, and we
> may
> >end up with more of our users using non-free software and believing
> that
> >it's all part of Debian.
>
> So a separate non-free firmware section as you proposed could work.
>
> > 4. A 

Re: Firmware - what are we going to do about it?

[Jonas Smedegaard]

Quoting Russ Allbery (2022-04-19 23:57:21)
> Jonas Smedegaard  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

signature.asc
Description: signature

Re: Firmware - what are we going to do about it?

[Pirate Praveen]

2022, ഏപ്രിൽ 19 5:57:46 AM IST, Steve McIntyre ൽ എഴുതി
>This tension extends to our installation and live media. As non-free is
>officially not considered part of Debian, our official media cannot include
>anything from non-free. This has been a deliberate policy for many years.
>Instead, we have for some time been building a limited parallel set of
>"unofficial non-free" images which include non-free firmware. These non-free
>images are produced by the same software that we use for the official images,
>and by the same team.
>
>There are a number of issues here that make developers and users unhappy:
>
> 1. Building, testing and publishing two sets of images takes more effort.

Can we reduce the tests? Do we really need to test both images for all cases?

> 2. We don't really want to be providing non-free images at all, from a
>philosophy point of view. So we mainly promote and advertise the preferred
>official free images. That can be a cause of confusion for users. We do
>link to the non-free images in various places, but they're not so easy to
>find.

I'm fine making it easier to find.

> 3. Using non-free installation media will cause more installations to use
>non-free software by default. That's not a great story for us, and we may
>end up with more of our users using non-free software and believing that
>it's all part of Debian.

So a separate non-free firmware section as you proposed could work.

> 4. A number of users and developers complain that we're wasting their time by
>publishing official images that are just not useful for a lot (a majority?)
>of users.

Isn't voluntary work being able to work on things you care and not necessarily 
what majority wants?

I can understand if the current volunteers that produce and test fully free 
images don't want to continue and no one else step up. Shouldn't this be a call 
for volunteers ?

May be more people step in to maintain the free images if there is a call for 
volunteers.

>We should do better than this.
>
>Options
>===
>
>The status quo is a mess, and I believe we can and should do things
>differently.
>
>I see several possible options that the images team can choose from here.
>However, several of these options could undermine the principles of Debian. We
>don't want to make fundamental changes like that without the clear backing of
>the wider project. That's why I'm writing this...
>
> 1. Keep the existing setup. It's horrible, but maybe it's the best we can do?
>(I hope not!)
>

As I said earlier, making non-free more prominent and more volunteers to 
maintain fully free images could work to reduce load on existing volunteers.

> 2. We could just stop providing the non-free unofficial images altogether.
>That's not really a promising route to follow - we'd be making it even
>harder for users to install our software. While ideologically pure, it's
>not going to advance the cause of Free Software.

I think we should continue creating non-free images.

> 3. We could stop pretending that the non-free images are unofficial, and maybe
>move them alongside the normal free images so they're published together.
>This would make them easier to find for people that need them, but is
>likely to cause users to question why we still make any images without
>firmware if they're otherwise identical.

This should be fine. This could be used as an opportunity to educate users and 
recommending to choose hardware which works with free images. We can highlight 
h-node.org here.

> 4. The images team technically could simply include non-free into the official
>images, and add firmware packages to the input lists for those images.
>However, that would still leave us with problem 3 from above (non-free
>generally enabled on most installations).

I don't think we should do this.

> 5. We could split out the non-free firmware packages into a new
>non-free-firmware component in the archive, and allow a specific exception
>only to allow inclusion of those packages on our official media. We would
>then generate only one set of official media, including those non-free
>firmware packages.

I'm okay with it only if we don't get enough volunteers to maintain two images.

>(We've already seen various suggestions in recent years to split up the
>non-free component of the archive like this, for example into
>non-free-firmware, non-free-doc, non-free-drivers, etc. Disagreement
>(bike-shedding?) about the split caused us to not make any progress on
>this. I believe this project should be picked up and completed. We don't
>have to make a perfect solution here immediately, just something that works
>well enough for our needs today. We can always tweak and improve the setup
>incrementally if that's needed.)
>
>These are the most likely possible options, in my opinion. If you have a better
>suggestion, please let us know!

As mentioned earlier, 

Re: Firmware - what are we going to do about it?

[Paul Wise]

On Tue, 2022-04-19 at 01:27 +0100, Steve McIntyre wrote:

> We have a small set of Free firmware binaries included in Debian main, and
> these are included on our installation and live media. This is great - we all
> love Free Software and this works.

There is a list of libre firmware projects on this page:

https://wiki.debian.org/Firmware/Open

We are missing several notable libre firmware projects, it would be
great if Debian could package them. I wonder what other support Debian
could give to libre/open firmware projects.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Firmware - what are we going to do about it?

[Paul Wise]

On Tue, 2022-04-19 at 11:33 +0200, Christian Kastner wrote:

> Here's a somewhat radical idea: I propose that we make option (1) and
> (2) conditional on all Debian infra switching to hardware entirely free
> of binary firmware/microcode blobs.
> 
> Because if *we* can't do it, then imposing this stringency on our users
> is outright idealist hypocrisy.

Even before we get to being able to run Debian infra using free
firmware, lots of the x86 servers that make up the Debian infra require
proprietary software running on the CPU, mostly for managing the
hardware; sensors, RAID, BMCs, fault detection and other things.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Firmware - what are we going to do about it?

[Andrey Rahmatullin]

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.14819384411900940...@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


signature.asc
Description: PGP signature