I urge Debian to rethink its decision to officially include non-free
firmware and correct the social contract. Instead of making non-free
firmware the default, Debian should ensure that users consciously
choose to install it while being made aware of the implications.
Le Fri, Mar 07, 2025 at 07:33:53PM +0100, Simon Josefsson a �crit :
[email protected] writes:
I urge Debian to rethink its decision to officially include non-free
firmware and correct the social contract. Instead of making non-free
firmware the default, Debian should ensure that users consciously
choose to install it while being made aware of the implications.
I agree and would personally come back to use Debian on some of my
laptops if there was a supported way to install Debian from official
installer images that did not promote non-free software by including
firmware on them.
The recent AMD Microcode vulnerability is a good case-study on the
dangers of permitting non-free code to run on your CPU:
https://bughunters.google.com/blog/5424842357473280/zen-and-the-art-of-microcode-hacking
Do not fall for the marketing. What was broken was the DRM which
forbid you to fix the firmware on your own CPU. This is no more a vulnerability than letting you boot your own OS.
Having source code for the
microcode would help gain confidence in it, and is the reasonable
request. If the request is denied, I would consider the vendor not >trustworthy and look into options.
My point was that there is no reasonable way to gain confidence about security properties of any piece of non-free microcode. Everyone can now produce AMD microcode that corrupts your machine in advanced ways that evade detection, but we don't know if such malicious corruption is included in the official microcode. Having source code for the microcode would help gain confidence in it, and is the reasonable request. If the request is denied, I would consider the vendor not trustworthy and look into options.
Hi,
Quoting Simon Josefsson (2025-03-08 13:43:26)
My point was that there is no reasonable way to gain confidence about
security properties of any piece of non-free microcode. Everyone can now
produce AMD microcode that corrupts your machine in advanced ways that evade >> detection, but we don't know if such malicious corruption is included in the >> official microcode. Having source code for the microcode would help gain
confidence in it, and is the reasonable request. If the request is denied, I
would consider the vendor not trustworthy and look into options.
I do not understand something about this argument.
If you don't trust the vendor, then it makes no difference whether or not new official firmware/microcode can be uploaded/flashed or not. If you don't trust
the vendor, then the initial microcode that came with your device might already
be doing things that go against your interests.
Of course we cannot have much confidence in a piece of microcode of which we do
not have the source code. But we also cannot have much confidence in a piece of
hardware with non-flashable firmware of which we don't have the vhdl/verilog sources. So what is the difference?
If I don't trust vendor X, then I cannot buy hardware from them independent of
whether or not the vendor allows me to flash proprietary binary blobs from them. If I do trust vendor X, then why would I not trust their proprietary binary blobs?
I do not think you will find many on this list who will disagree with the sentiment that it would be great if we had sources, schematics etc for many more things. On the other hand, I don't think you can currently buy a device that is capable to run, for example, a modern web browser and is fully open. This is why I voted in the last GR as I did. I'm typing this on an MNT Reform which is probably among the most open computers you can buy today but the chips
in it are *not* open silicon. Yes, it would be great if they were and it would
be great if the firmware blobs I need would not be proprietary. But I already chose to trust the manufacturers of the chips in my laptop or otherwise I would
not be typing these lines. Why would I trust the silicone from vendor X and distrust the firmware/microcode from vendor X? Having non-free-firmware enabled
by default in the Debian installer just continues pursuing a trust relationship
you already decided on entering when you bought the hardware, no?
True, but the GR does not prevent Debian of providing a second set of installer images. What is required is someone to do the work, as usual.
I read this outcome as fairly clear message that, no, Debian does not
want to provide a second set of installer images, and is not interested
in contributions to make them.
Le 8 mars 2025 21:09:00 GMT+01:00, Simon Josefsson <[email protected]> a écrit :
I read this outcome as fairly clear message that, no, Debian does not
want to provide a second set of installer images, and is not interested
in contributions to make them.
Your positions in this thread try to make it sound much more black and
white than it needs to be, than the GR text is written and than my
reading of the current consensus in Debian.
Like others have said you can start working on alternate fully free
images. We've seen in the thread that there's interest in it. (I would
use them. I did like the fully free images although I would knowingly
install firmware on top of them.)
What the GR says is that you cannot dump that work on the shoulders of
the people currently maintaining the installer, coordinating the
releases…
That you're trying to impose so many preconditions before even
starting the work is OTOH an indication to me that you're not really interested in doing it in the context of Debian.
Please feel free to pick up the code and generate the second set of installer images, maintaining the code to exclude non-free-firmware.
On 08.03.25 21:09, Simon Josefsson wrote:
I read this outcome as fairly clear message that, no, Debian does not
want to provide a second set of installer images, and is not interested
in contributions to make them.
Another way to look at this outcome, and the one I personally prefer
by a wide margin, is that it'd be very cool to have them, but at this
time their utility is … questionable, given that I personally own zero
(out of umpteen) computers that would work with such an image.
Not my NAS, not my router, not my laptop, not the Raspberry Pi that's controlling my home's heating system. Or the other Pi behind the TV;
said TV is a far worse problem from a free software PoV than a few
blobs of firmware, but I digress.
So why should a GR compel us to build a second set of images which
most people cannot use anyway?
On the other hand, if you want to spend some time building those
images, fine, go ahead; if and when those images are actually usable
for a relevant subset of machines out there, *then* we can might want
to revise our decision.
Hi,
On Sun, 2025-03-09 at 14:19 +0100, Simon Josefsson wrote:
Our experience seems to differ, I now run Trisquel and Guix on many of
my home and machines and servers. For my uses they all work without
non-free firmware. You have to be careful about what hardware you buy,
and chose your use-cases. And, yes, I use modern hardware -- i9-14900K
on desktop, i7 1260P and Ultra 155H in my two most used laptops,
ARS-111M-NR and Talos II on the server side, as well as a bunch of aging
Dell R630's.
This class of hardware *requires* non-free firmware. Lots of it, at
every system layer.
On Sun, Mar 09, 2025 at 03:58:59PM +0100, Simon Josefsson wrote:
Agreed. However none of that hardware require me to load non-free
firmware from my operating system, which is my point. That situation is
sufficient for me to accept to use the hardware and install an operating
system built without non-free software on it.
Simon,
Installing using the Debian installer doesn't *require* you to carry on
with the firmware. You can readily remove it - especially if you use the expert install - you are not required to enable the repository in your /etc/apt/sources.list and so on. The installer does list the firmware suggested for install to enable all devices - you don't have to take
that suggestion.
So - if you don't *see* the need for firmware expressed and firmware is already in the machine you install on, that's fine?
Hi,
On Sun, 2025-03-09 at 15:58 +0100, Simon Josefsson wrote:
Ansgar 🙀 <[email protected]> writes:
Hi,
On Sun, 2025-03-09 at 14:19 +0100, Simon Josefsson wrote:
Our experience seems to differ, I now run Trisquel and Guix on many of >> > > my home and machines and servers. For my uses they all work without
non-free firmware. You have to be careful about what hardware you buy, >> > > and chose your use-cases. And, yes, I use modern hardware -- i9-14900K >> > > on desktop, i7 1260P and Ultra 155H in my two most used laptops,
ARS-111M-NR and Talos II on the server side, as well as a bunch of aging >> > > Dell R630's.
This class of hardware *requires* non-free firmware. Lots of it, at
every system layer.
Agreed.
So we agree that pretty much all hardware requires non-free firmware
these days.
However none of that hardware require me to load non-free
firmware from my operating system, which is my point. That situation is
sufficient for me to accept to use the hardware and install an operating
system built without non-free software on it.
What is the point of this then?
While this may be fine to you it is not fine to me, and it is fine to disagree on that.
Hi Simon,
Simon Josefsson <[email protected]> writes:
While this may be fine to you it is not fine to me, and it is fine to
disagree on that.
If there were a method of building images that did not touch the
non-free components, I presume that would satisfy you.
Let's say that we could make that image bit-for-bit reproducible with an image that was produced by taking the normal with-nonfree-firmware
image, and filtering it somehow (e.g. overwriting the non-free bits with zeros, say).
Would you object if the normal way of generating the image was to apply
the filter, rather than build it in parallel?
If that would be OK, then one could have something that applied the
filter to our normal images to provide people with the images you want,
while not require duplication of building and storage.
People could always confirm that they were getting the same result as building without the nonfree firmware by doing it themselves, and
checking things matched.
Is that something that would work for you?
I still haven't heard arguments why people refuse to use an installer
that comes with non-free firmware, asks whether this firmware should
be used, and if answered "no", none of this non-free firmware ends up
in the installed system. The resulting system is free regardless
whether there was non-free firmware on the installation images.
On Mon, Mar 10, 2025 at 09:33:55PM +0900, Simon Richter wrote:
We've reached the point where people are shitting on nV for the
quality of their drivers, and a kernel that has closed-source drivers >loaded is "tainted", and the last release in which we shipped
ndiswrapper was buster.
That happened because those solutions were all incredibly painful,
depending on the kernel version in use, losing compatibly during every second kernel upgrade, and didn't work cross-architecture. Users hated
that.
non-free firmware is silent and painless. Users don't care.
tl;dr: The situation is totally different, we should not compare apples
and peaches here.
Philip Hands <[email protected]> writes:
Let's say that we could make that image bit-for-bit reproducible with an
image that was produced by taking the normal with-nonfree-firmware
image, and filtering it somehow (e.g. overwriting the non-free bits with
zeros, say).
Would you object if the normal way of generating the image was to apply
the filter, rather than build it in parallel?
If that would be OK, then one could have something that applied the
filter to our normal images to provide people with the images you want,
while not require duplication of building and storage.
People could always confirm that they were getting the same result as
building without the nonfree firmware by doing it themselves, and
checking things matched.
Is that something that would work for you?
I don't think the above fully resolve my concerns though. The mere
presence of official documented hooks to load non-free software is >problematic from a freedom perspective. They are the enabler of the
slippery slope that leads to including non-free software by default.
Meanwhile I looked into the debian-cd project to experiment with
building images myself. Why aren't the images built in a Salsa
pipeline? Yes I understand that 20 years ago the resources required to
build the images were large. But today people build large projects in
GitHub Actions. What artifact size are we talking about? Looking at
the summary of official images at https://www.debian.org/CD/http-ftp/ it >seems like around 50GB?
What is the build time on a powerful machine?
I would start to worry about the design feasability of running this in a >pipeline when the total size of artifacts from a single build is larger
than 4TB or if a single serialized job would have to run for more than a >couple of days. I'm probably missing some combinatorical explosion of >varaints that increase the total size, but there is also no requirement
that all images are built like this. I would be satisfied if the
"netinst" variant for all architectures could be reproduced from purely
free software, in a Salsa pipeline, and that seems to be a 5-10GB
artifact unless my math is off.
I worry that the builds require other non-reproducible/free steps
though. A signed boot shim where the private key is not replaceable by
a user-controlled key is equally problematic as non-free firmware.
Trisquel and Guix avoids these, and I recall seeing stuff like that in
Debian -- https://tracker.debian.org/pkg/shim-signed -- but it is good
to know that we have more things to work.
their questionable choices in buying hardware that ships with non-free firmware
https://www.gnu.org/distros/optionally-free-not-enough.html
https://www.gnu.org/philosophy/install-fest-devil.html
We're not obligated to validate their questionable choices in buying
hardware that ships with non-free firmware
There are a lot of competing priorities here, and it's the height of
arrogance to be so certain that one's own opinion is best as to try to
prevent other people from making their own decisions by hiding even the
existence of a mechanism to install debian on their machine.
Simon,
Do know that is OK that there are differences in view, opinion,
standpoint, approaches, ideas and whatever.
Le 10 mars 2025 11:56:28 GMT+01:00, Simon Josefsson <[email protected]> a écrit :
https://www.gnu.org/distros/optionally-free-not-enough.html
https://www.gnu.org/philosophy/install-fest-devil.html
… of course … that's where the core of the disagreement lies !
We're not a religion, we're just building a distro.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 716 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 51:23:47 |
| Calls: | 12,115 |
| Calls today: | 6 |
| Files: | 15,010 |
| Messages: | 6,518,566 |
| Posted today: | 1 |