Project

General

Profile

Freedom Issue #3000

[fwupd]: is an auto-updater , may also download proprietary firmware

gap - 29 days ago - . Updated 16 days ago.

Status:
unconfirmed
Priority:
freedom issue
Assignee:
-
% Done:

0%


Description

I believe this program automatically downloads proprietary firmware, but I obviously don't want to test and find out.

The database it connects to hosts proprietary firmware.


Related issues

Related to Packages - Freedom Issue #1035: [your-system-sanity]: Non-Free Software From Third-party Package Managersin progress

Actions

History

#1

Updated by gap 29 days ago

Removing this package would also break [gnome-firmware].

#2

Updated by gap 18 days ago

fwupd is also a TPPM.

#3

Updated by bill-auger 18 days ago

this is just a guess, but it is likely that linux-libre would not load any of these firmwares - if they are kernel modules, then the package is harmless and useless

#4

Updated by gap 18 days ago

flashrom is a dependency and the database it connects to hosts all kinds of propritary firmware so I suspect it will try to flash BIOS and EEPROM firmware, hence linux-libre could not stop it.

#5

Updated by bill-auger 18 days ago

  • Priority changed from bug to freedom issue
  • Subject changed from [fwupd] Downloads proprietary firmware to [fwupd]: is an auto-updater , may also download proprietary firmware

ok i see that now - it is an auto-updater - normally, we would not want this package, for that reason alone; but this is not installing anything that would corrupt the system - surely, it does not flash the device without the user initiating the job?

im hesitant to mark this as 'confirmed' yet, without proof that it downloads anything non-free - it may be good to add a new class of bug and blacklist reason, like [system-sanity] for similar auto-updaters; but this one probably does not fit that shoe, unless it does flash the firmware without asking

#6

Updated by gap 18 days ago

The fwupd repo <https://github.com/fwupd/fwupd> states "This project is configured by default to download firmware from the Linux Vendor Firmware Service (LVFS) <https://fwupd.org/> ."

Checking out that site shows the latest firmware uploaded to it is proprietary <https://fwupd.org/lvfs/devices/com.intel.INTEL-670P-670PSSDPEKNU010TZNVME1TB.7XX1> .

I suspect this service is little more than a convenient way to install proprietary firmware not usually packaged by distros.

There may be some libre firmware on there also.

I'd say it's a TPPM for your-system-sanity, and it's technically free, but downloads proprietary firmware automatically as a daemon.

#7

Updated by lukeshu 18 days ago

fwupd largely deals with the firmwares on peripheral devices. That's code that distros traditionally don't deal with. USB devices. Laptop components with their own flash chip that stores the firmware. The Linux kernel and linux-firmware deal with things that receive their firmware from the CPU at boot-time; fwupd deals with devices that store their own firmware, devices that 90% of the time you can pretend are block boxes that have their software burned in to ROM so that for FSDG purposes you can pretend aren't software.

AFAICT, LVFS doesn't really track if firmwares are FOSS or not. Vendors upload a zip file of the binary firmwares and call it a day.

That's a very real FSDG concern. And I'm not sure what to do about it. Lots of the firmwares are free software, and to remove fwupd and and the LVFS library of firmwares would be a huge disservice and anti-feature to free-systems users. That problem's been eating at me for a few years.

I mean the "big picture" answer would be to build a FOSS-oriented alternative service to LVFS. But (IMO) that's beyond the manpower of Parabola. Should FSDG distros band together to create that? Should we propose that to the FSF as a high-priority project? IMO, we can get everyone and their dog to say it's important, but without actually getting a group of people to actually do it, it won't happen.

So I'm not sure what to do.

#8

Updated by lukeshu 18 days ago

Not that I've been terribly active in Parabola for the last couple of years, but:

Empirically, my answer has been to look the other way; because IMO fwupd/LVFS is more [helpful to users of purely-FSDG-software] than it is [facilitating of using non-FSDG software]. That view might not be entirely compliant with the FSDG, but IMO it's the view that results in the best outcome for users who want to use entirely free software.

To remove fwupd because it can install non-free firmware doesn't remove the non-free firmware; that firmware is still on a flash chip on the device; it just removes your ability to modify that firmware. It's sticking your head in the sand and pretending the firmware is hardware. As long as you have that hardware, you'll have the non-free firmware, whether or not Parabola ships fwupd. (Unless someone reverse-engineers the hardware and provides a free firmware for it--and guess what, you'll need fwupd to update to that firmware.)

fwupd/LVFS might be technically in violation of the FSDG, but (IMO) fwupd's removal would be strictly harmful to user freedom, as its removal WOULD NOT help users avoid non-free firmware. That isn't to say that things can't be improved. But the way to improve things isn't to remove fwupd.

#9

Updated by gap 18 days ago

lukeshu, there's no need to keep things to yourself which make you upset; I'm sure we'd love to discuss any issues on the forums. I just worry that you may be sitting on other instances of proprietary software in unaudited packages in the Parabola repos that you aren't willing to share because you disagree with the FSDG, although I assume good faith.

As controversial as this issue of firmware seems to be in the free software community, I presume Parabola wants to remain FSDG compliant.

My answer is to see it for what it is: a proprietary software downloader.

If you have a ROM then it's technically crossed the realm from software to hardware. I know that's a bit of a cop out but it's true. If nobody can change it, then nobody has power over the users aside from whatever is burnt into it before it is shipped from the factory. It would be better if it were an EEPROM with libre firmware, but this is a compromise.

If you have an EEPROM then it's software because it's just the same as any other storage medium.

I think we have to remove fwupd to remain FSDG compliant.

I also suspect the "LVFS" is 99% proprietary, although a patched fwupd in the [libre] repo which uses a forked Parabola repo (eg. fwupd-firmware) would be an ideal solution.

#10

Updated by gap 18 days ago

Also, "FOSS" is listed as a word to avoid or use with care in the so-named GNU article.

#11

Updated by bill-auger 18 days ago

lukeshu - this would be a great discussion for the FSDG mailing list - i dont like the idea of each distro freely re-interpreting the FSDG

i think that WRT the FSDG, this reduces to the CPU microcodes issue, and those are generally consider to be prohibited - if the user can compile and replace it, then it is software by any definition; and if the user had the source code, it can be replaced with a modified version - so, parabola should require them to be freely licensed with source code available - everyone knows that a lot of hardware is not going to work with a libre distro; and that users can get blobs from arch if they really need them

to argue that point to the FSDG, is effectively an argument for allowing microcode updates too

#12

Updated by bill-auger 18 days ago

  • Related to Freedom Issue #1035: [your-system-sanity]: Non-Free Software From Third-party Package Managers added
#13

Updated by bill-auger 18 days ago

i forgot to mention that there is a long standing discussion about how to treat TPPMs generally - gap was suggesting that this package should be considered as another TPPM (if we keep it) - it doesnt need to be a FSF high priority - RMS has already suggested years ago, that GNU would host libre repos for any TPPM - o/c people need to volunteer to curate them - that is a lot of work o/c; so we have also suggested some simpler alteratives, such as moving them to a non-standard repo

https://labs.parabola.nu/issues/1035

#14

Updated by bill-auger 18 days ago

we'd love to discuss any issues on the forums

it is best to discuss development issues on the dev mailing list - i am probably the only team member who reads the forum regularly

#15

Updated by lukeshu 18 days ago

gap wrote:

lukeshu, there's no need to keep things to yourself which make you upset; I'm sure we'd love to discuss any issues on the forums. I just worry that you may be sitting on other instances of proprietary software in unaudited packages in the Parabola repos that you aren't willing to share because you disagree with the FSDG, although I assume good faith.

To be clear: I'm not keeping things to myself because I don't want to talk about them or to slide things through. To the degree that I'm keeping things to myself, it's because I lack the energy/time to deal with them. fwupd came on to my radar about the time that my involvement in Parabola dropped off.

#16

Updated by lukeshu 18 days ago

gap wrote:

Also, "FOSS" is listed as a word to avoid or use with care in the so-named GNU article.

I used "FOSS" because: It's my understanding that LVFS is a Linux Foundation project. The Linux Foundation uses the OSI's definitions and licenses; any tracking of licenses that they do will be oriented around "open source", not around "free". Of course, we care about "free". So both "open source" and "free" are in play here, so that's why I used the term "FOSS".

I was using it with care, but it wasn't clear that I was using it with care. For that, I apologize.

#17

Updated by lukeshu 18 days ago

I'm sorry, I'm not familiar with the term "TPPM".

#18

Updated by lukeshu 18 days ago

bill-auger wrote:

to argue that point to the FSDG, is effectively an argument for allowing microcode updates too

The type of firmwares that fwupd deals with are different than microcode updates. If you don't load a microcode update at boot-time, then it just falls back to what's implemented in hardware. If you don't use fwupd to update the firmware, it falls back to the most recently flashed firmware. Not loading a microcode update removes the code; not running fwupd doesn't remove the code.

gap wrote:

If you have a ROM then it's technically crossed the realm from software to hardware. I know that's a bit of a cop out but it's true. If nobody can change it, then nobody has power over the users aside from whatever is burnt into it before it is shipped from the factory. It would be better if it were an EEPROM with libre firmware, but this is a compromise.

If you have an EEPROM then it's software because it's just the same as any other storage medium.

Right. What I'm saying is that removing fwupd doesn't remove the software on the EEPROM, which is the real issue. Pretending that removing fwupd resolves the issue is to pretend that the EEPROM is a ROM; which it isn't.

Again, I'm not saying that it's OK that LVFS serving non-free firmwares is OK, I'm saying that removing fwupd isn't the answer.

#19

Updated by lukeshu 18 days ago

gap wrote:

I also suspect the "LVFS" is 99% proprietary, although a patched fwupd in the [libre] repo which uses a forked Parabola repo (eg. fwupd-firmware) would be an ideal solution.

Looking through the LVFS, damn near everything is mislabeled. I see a few firmwares that I know to be Free marked as "proprietary", and a few marked as having a Free licenses, but are actually proprietary.

#20

Updated by lukeshu 18 days ago

This discussion has motivated my drunk-at-3am-on-a-Friday-night self to want to create an FSDG alternative to LVFS. We'll see if my sober-on-a-Saturday self follows through. I've messaged Andrew at the FSF about using firmware.libre.dev for this purpose, so that it can be shared between distros. (the FSF owns libre.dev, but doesn't seem to be using it for anything real ATM. If they didn't already own it, I'd have registered it.)

#21

Updated by bill-auger 18 days ago

On Sat, 03 Apr 2021 10:09:24 +0000 wrote:

I'm sorry, I'm not familiar with the term "TPPM".

"third-party package manager" - we coined that, because ...
we got tired of typing it

pip, rubygems, npm, guix, etc - any program which indexes and
downloads software from a third-party repository - most of them
do not indicate licenses, and most have no licensing standards,
so they are all problematic for the FSDG - (almost all), haskell
cabal is the only one i found, that has FSDG-fit licensing standards

also, they can be dangerous - for example, i triaged an obscure
bug, reported by a user, one day "octopi is broken" - i
eventually asked: "what happens if you open a terminal and type
`/usr/bin/pacman` - the user responded that it launched a pacman
video game - the user then remembered running `sudo pip install
pacman` - obviously, that user had to bootstrap, in order to
re-install the real pacman, because it was clobbered

#22

Updated by bill-auger 18 days ago

Not loading a microcode update removes the code; not running fwupd doesn't remove the code.

i think the important factor, is that although the non-free firmware is on the device, parabola did not put it there - it was effectively user-installed, same as if the user got the firmware update from arch

#23

Updated by lukeshu 16 days ago

I think the short-term solution might to be to stick rm -f "$pkgdir"/etc/fwupd/remotes.d/lvfs* at the end of the package().

Also available in: Atom PDF