Thank you for that constructive reply @moonlitOrca. I regretted the tone of my post almost instantly and are glad you are taking it the right way. I’ll try to moderate myself.
2 Likes
The Debian stakeholders are voting on what they are going to do with non-free firmware.
General Resolution: non-free firmware
It could make it less likely that people expect Debian to not include non-free-firmware and non-free-firmware sources.list.
This is the options which currently has the most votes.
We will include non-free firmware packages from the “non-free-firmware” section of the Debian archive on our official media (installer images and live images). The included firmware binaries will normally be enabled by default where the system determines that they are required, but where possible we will include ways for users to disable this at boot (boot menu option, kernel command line etc.).
When the installer/live system is running we will provide information to the user about what firmware has been loaded (both free and non-free), and we will also store that information on the target system such that users will be able to find it later. The target system will also be configured to use the non-free-firmware component by default in the apt sources.list file. Our users should receive security updates and important fixes to firmware binaries just like any other installed software.
We will publish these images as official Debian media, replacing the current media sets that do not include non-free firmware packages.
1 Like
Any one interested in the thought behind this GR should read the
long discussion I referenced at the start of this thread:
https://lists.debian.org/debian-devel/2022/04/msg00130.html
It will be interesting to see where that goes.
As for Qubes, whatever decision is made in Debian, I don’t think we
should change our current policy.
-
We have no idea why Qubes users might choose a Debian template.
(Debian doesn’t know why people choose Debian.) For some people, it may
be because of the commitment to libre. -
Adding non-free firmware or programs doesn’t stop it being Debian.
-
Many users wont understand a reference to “free software” as part of
the Qubes install.
And to anyone who says that they were misled, how did you not know? It’s
not been hidden in any way.
The question has come up a number of times before and has been answered
in exactly the same way. It’s plain on the face of the source code, and
in the templates themselves.
It looks as if you want the 4 freedoms without exercising them in any
way. Perhaps you should think about that.
And, as I’ve said, if you don’t like the current situation, fork the
project and produce libreQubes - it will be less secure, and even more
limited in scope than Qubes, but that isn’t the issue for you.
When I comment in the Forum or in the mailing lists I speak for myself.
Thank you, that is a very interesting read (not quite through yet). I do have one question for clarification, based on my own usage:
- debian-minimal has no non-free packages installed by default
- none of my templates except the one for sys-wifi contain non-free packages
Am I correct in assuming that my templates do not actually need Intel microcode updates as long as dom0 gets them?
I think having non-free enabled and common firmware installed by default is the sensible choice for our default/full templates to ease hardware support for unskilled users. I also don’t mind them being available by default in minimal. Just wondering if there is a security benefit in adding the intel-firmware package to my templates in general and for Ivy Bridge in particular?
1 Like
I’m sure this is right. The guests cant install microcode to the host CPU.
On the other hand I have an email from RedHat support that stated that
microcode ctl was required in VMs, without explanation.
I’m sure we could drop the amd64-microcode and intel-microcode packages,
as well as iucode-tool. But we aren’t specifically choosing to install
them - they aren’t, for example, specified in the firmware target.
They are installed as “Recommends” of the firmware-linux package.
1 Like
I thought I already explained this:
What do you expect the users would do? Read every closed issue at Github? I ready them almost every day, and even I missed this one. Check every config file, including /etc/apt/sources? I didn’t, because the documentation was saying it was plain Debian and that Qubes wasn’t FSF-certified “because Debian was not certified”. The docs even said that Qubes was free software. There are already too many things to learn about Qubes even for me right now as a user. It’s impossible to verify every single detail. Maybe I also do not value free software sufficiently, too, who knows 
The docs are sifnificantly improved now, thanks to @adw, but they still call the Debian template “Debian” without explaining how it was changed from the official ISO. On their official website, Debian put “free software” as the first reason to use Debian. I believe it goes against their values to do what Qubes project is doing here, unless the docs at least mention that non-free software is added to the template. Obviously I represent neither Qubes nor Debian and my opinion is just an opinion of a random Internet-poster. But it seems there are other people in the Qubes Community who agree with me.
Debian is a free OS, by definition. Qubes project is calling something non-free “Debian”, misleading its users. Yes, some users do not care about freedom. But you should not change the definitions of the underlying operating systems without telling it, if you want to earn trust of the users.
Note that it’s not about my preferences. I personally can easily remove all components which I do not like. But new users will read “Debian” and expect “Debian”, but get “Debian Unofficial” instead. It already mislead a few users (which is why this topic exists!).
I guess it was supposed to be a joke, but AFAIK my laptop can run “Libre Qubes” securely. As I said above, the microcode updates are included into the coreboot, and no proprietary firmware is required in the kernel to run my device.
Rant about "Libre Qubes"
I wish Qubes projejct would not be as hostile to Purism as r/purism subreddit and maybe even actually create Libre Qubes together with them, which would runs on Librem devices. It would probably be a great advertisement for the Qubes project. I don’t even expect it would take any serious effort, although I might be mistaken here. Man can dream. 
How is Qubes security improved by adding non-free software to the Debian template?
Thank you very much for this. I think this resolves many inconsistencies and is well worded (although I am not an expert on licensing, too). One minor thing I would suggest: Put sentence
"Qubes OS is provided at no cost (gratis), though donations are greatly appreciated"
to the end of the answer, otherwise it makes the impression that “free” in the question is mainly about cost, whereas the main meaning accepted by the Community is about freedom.
Debian are using their own definition and link to the FSF definition, too.
This is where we disagree, and it seems I’m not the only one who expects that “Debian” means “Debian official”. However, I did not find a clear wording about it on the Debian website, except about labeling CDs.
Off-topic discussion about Wikipedia
When I say that it’s not a source, I mean this and this. As reliable sources, one should use the references instead, and I find them great on the discussed page.
This is exactly why I said unless the article is unfinished, or has edit wars. I did not imply any guarantee of correctness in a general case.
I only said that the specific Wikipedia page is a representative sample of the Community’s opinion, because I read a few Community websites for other distros and found no contradictions. The links were also well compiled. If you have evidence that it’s not the case, I would be interested to see it. I did not generalize here, although if you rely on the references, not text, Wikipedia pages are often quite good.
From your quote, it’s unclear to me which statement you mean. (But I don’t think it’s sufficiently important for you to spend your time on explanaitions.)
By allowing the OEM of your WiFi, Sound, USB, NIC, whatever to fix the bugs in their firmware … which you run regardless of whether those updates are applied or not.
We are only talking about firmware … that’s the only non-free packages installed.
Rejecting those is saying: I am contempt with DEFECT and/or VULNERABLE non-free firmware running on my computer. At the same time I refuse to apply (security) updates for ideological reasons that have NO impact on my freedom but have guaranteed NEGATIVE impact on my security.
That frankly stuns me. From a purist point of view how is non-free in coreboot any better than in the OS proper? You understand that firmware means it’s applied (loaded into another processor) that runs when your OS is running? Even in case of microcode and the main CPU?
- you have no choice or say in whether the non-free firmware runs
- you can choose whether you want the vulnerable version or the latest presumed “best” version to run
- what does it matter if coreboot or the OS does the updating?
If you rely on coreboot for microcode updates, what about all the other components firmware?
1 Like
Do you need to read every github post and config file to discover that the close source firmware is included, wouldn’t it be enough to open sources.list?
If all you need to do is read the sources, I don’t think it’s too much to ask.
I’ve updated the PR to attempt to clarify this.
It’s not clear what exactly you’re suggesting or requesting here. The person I was replying to suggested that we link to any “contentious terms or definitions.” I already link the term “free (libre) and open-source software (FOSS or FLOSS)” to FLOSS and FOSS - GNU Project - Free Software Foundation (which is one level deeper than your FSF link). What exactly is/are the other contentious term(s) and/or definition(s) that you think should be linked, and to what URL(s) do you think it/they should be linked?
1 Like
Based on some links shared above, it sounds like the Debian Project is currently in the process of an internal deliberation about whether to change this. Rather than try to update our documentation to hit a moving target, we should probably just wait and see where the dust settles first. Plus, the open PR does mention that non-free software is added to the standard templates.
2 Likes
Thank you for the clarification. So you are implying here that the hardware will still work, even if I provide no proprietary firmware. Fair enough, I see that @marmarek mentioned such possibility above. This however is not my experience: Usually, if proprietary firmware is needed, the hardware doesn’t work without it at all, which could be a good compromise for some people, and it doesn’t involve security.
Look, I’m not the hard free software ideologist like some people here seem to expect; I do not follow the strict free software practices and compromise my freedom for security and convenience, just like Qubes OS does. However, I understand why the FSF are doing that and I agree that they should, in order to demonstrate to others what the ideological purity could be and how far we are from it.
Of course, using non-free firmware does have an impact on your freedom and maybe even security. You now depend on a monopolistic company providing secret firmware which your devices must run. When they decide to add a vulnerability (or are forced to do it by someone), you have no recourse or even knowledge about it. Monopolies are a good target for all sorts of bad actors. If they decide to stop supporting your hardware, you are out of luck and have to throw it away. Here, you have a choice between fully trusting them and defending from the known vulnerabilities in your own ways (e.g. never use sound, or apply a Faraday cage, or exclusively run software you verified).
It isn’t. It still damages your freedom in the same way. However, having a fully free OS is a great advertisement and the FSF know this very well. If you run an FSF-endorsed distro, you still probably run some non-free firmware somewhere. But those OSes advertise freedom and your rights, thus promoting the FSF values. Devices which, according to the FSF, respect your freedom, still probably run some non-free software (which you shouldn’t update although nobody would stop you from doing this if you decide it). Existence of those devices makes people more aware of the problems with freedom in the modern world. This is exactly why I dream about actual Libre Qubes: It could make a great advertisement to both Qubes and freedom, while having no impact on security (if you run it on supported devices). Non-free microcode will of course still be there (in coreboot), harming your freedoms. I hope I clarified my position a little. Feel free to ask more questions if you like. I believe that the main problem of the FSF today is that too few people know how non-free software harms their freedom and how the world would look otherwise.
We are talking here about users, not developers. Some of them don’t even know what the sources.list is; others have not enough time to dig into it. Following your logic, free software needs no documentation, because everyone can just read the source code and config files, right? I had some trust in the Qubes project, which is why I decided that I would not spend my time to verify their words and use it to help them instead… The trust was larger than my worries about my freedom. Does it look wrong to you?
Sorry I was unclear. First, one could make links like this: “Free/Libre and Open Source Software”. Second, although Debian have a link to the FSF definition, they still have their own definition of free software:
The Debian Free Software Guidelines (DFSG)
*Free Redistribution
The license of a Debian component may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license may not require a royalty or other fee for such sale.
*Source Code
The program must include source code, and must allow distribution in source code as well as compiled form.
*Derived Works
The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
*Integrity of The Author’s Source Code
The license may restrict source-code from being distributed in modified form only if the license allows the distribution of “patch files” with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software. (This is a compromise. The Debian group encourages all authors not to restrict any files, source or binary, from being modified.)
*No Discrimination Against Persons or Groups
The license must not discriminate against any person or group of persons.
*No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
*Distribution of License
The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.
*License Must Not Be Specific to Debian
The rights attached to the program must not depend on the program’s being part of a Debian system. If the program is extracted from Debian and used or distributed without Debian but otherwise within the terms of the program’s license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the Debian system.
*License Must Not Contaminate Other Software
The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be free software.
I’m no expert on licensing, but there must be some reason they write it; probably they disagree with the FSF definition in something. I don’t know if mentioning Debian’s definition is important, but I wanted to point it out for you.
Thank you for your great PRs.
Fair enough. Although I still think that mentioning non-free packages on your Debian page would be helpful for users…
Of course it is. You are using an Intel CPU. 
… other examples are more than likely your USB, Bluetooth, SSD, maybe the firmware for your keyboard controller is free (maybe not), your trackpad… the list is very likely a lot longer than you expect.
No, and it has nothing to do with reading the source code, it’s a configuration file that doesn’t contain a single line of code. I was just pointing that you are wrong about someone would need to spend an excessive amount of reading github issues to be able to determine what sources are used.
The information is placed in the location where you would expect to find it, anyone with the most basic understand of apt would be able to do this.
I tried searching Google for “does my debian use non-free packages” the first hit explains how sources.list works, I don’t consider this rocket science that would be unreasonable for anyone but a developer to understand.
It sounds like you are assuming a false dichotomy of the following sort: “If a device requires proprietary firmware in order to work, and I don’t provide that device with proprietary firmware, then it won’t have the proprietary firmware it needs to work.”
The mistaken assumption is that the only way for any device to have the proprietary firmware it needs is by you providing that firmware.
In reality, as Marek explained above, many devices already have on-board copies of the proprietary firmware they need in their internal ROM. By providing proprietary firmware, you aren’t adding proprietary firmware to a situation where none previously existed. Rather, you’re simply providing a newer version of the same proprietary firmware that contains bug fixes that the old on-board proprietary firmware lacks. Either way, by using such a device, you are running proprietary firmware. The question is simply whether you will run outdated, vulnerable proprietary firmware or newer, patched proprietary firmware.
If we actually had “regular Qubes” and “Libre Qubes” this way, then, in practice, what would probably happen is that poor unsuspecting newbies would assume that “Libre Qubes” is just “regular Qubes but libre,” not understand that it should only be installed on very specific types of devices (in order to achieve the same results as regular Qubes), and end up severely harming their own security. It sounds like a UX landmine.
It also just seems outright deceptive to advertise “Libre Qubes on supported devices” as somehow “more libre,” when it’s effectively the same as “regular Qubes on regular devices.” You’re simply moving around where the proprietary firmware is, like a shell game.
To be fair, the Qubes OS Project has always been pretty big on “not BSing our users” (as Joanna would put it), which has probably cost us a lot of “good advertising opportunities” like this one.
Yeah, I’m not sure about that. I don’t really want this to become some master index of every project’s definition of freedom. Remember that every link we add is a potential maintenance burden down the line if that page moves or the link otherwise breaks.
Anyone interested in the result of the Debian GR should note that the
discussion period has been extended by 7 days to 9/14
As I have said, I do not believe that the result of that GR should
affect what Qubes does with the Debian templates.
The Debian GR is concluded
Option 5 was the winner, “Change SC for non-free firmware in installer, one installer”
We will include non-free firmware packages from the “non-free-firmware” section of the Debian archive on our official media (installer images and live images). The included firmware binaries will normally be enabled by default where the system determines that they are required, but where possible we will include ways for users to disable this at boot (boot menu option, kernel command line etc.).
When the installer/live system is running we will provide information to the user about what firmware has been loaded (both free and non-free), and we will also store that information on the target system such that users will be able to find it later. Where non-free firmware is found to be necessary, the target system will also be configured to use the non-free-firmware component by default in the apt sources.list file. Our users should receive security updates and important fixes to firmware binaries just like any other installed software.
We will publish these images as official Debian media, replacing the current media sets that do not include non-free firmware packages.
1 Like
This is, of course, as yet not official.
Option 5 required a super majority, which was, I think, reached.
The results are interesting.
Votes cast were 366, a relatively low proportion of voting developers,
which suggests that the issue wasn’t seen to be of huge importance to
DDs.(Not unusually low.)
The result, (assuming the result is endorsed by the secretary), is
broadly in line with the position taken by Qubes. It confirms that
official Debian installers will include non-free components, and
official Debian installs will therefore include non-free elements in
the sources.list, where necessary.
When I comment in the Forum or in the mailing lists I speak for myself.
1 Like
Broadly – yes. But stricly – no, because the Qubes user is not informed about the propretary firmware in Debian and has no option to cancel installation of it. For everyone using Fedora as sys-* qubes, it is relevant (and for those whose laptops need no non-free firmware of course).
2 Likes
Qubes doesn’t provide Debian installation media. It provides installed
templates, ready to be used by multiple users.
You can take it that Qubes will adopt whatever method Debian uses for
provision of non-free firmware, and will adapt whatever method is used
to inform users of non-free firmware. adapt not duplicate.
I’ve no interest in further discussion here until that becomes clear.
The “discussion” does not further Qubes, and is another case of “Could
you please make my preference the default?”,less politely put.
When I comment in the Forum or in the mailing lists I speak for myself.
1 Like