I found some highly suspicious files:

$ pacman -Q -l  fwupd | grep -i lvfs
fwupd /etc/fwupd/remotes.d/lvfs-testing.conf
fwupd /etc/fwupd/remotes.d/lvfs.conf
[...]
$ cat /etc/fwupd/remotes.d/lvfs.conf
[fwupd Remote]

# this remote provides metadata and firmware marked as 'stable' from the LVFS
Enabled=true
Title=Linux Vendor Firmware Service
Keyring=gpg
MetadataURI=https://cdn.fwupd.org/downloads/firmware.xml.gz
ReportURI=https://fwupd.org/lvfs/firmware/report
OrderBefore=fwupd

https://cdn.fwupd.org/downloads/firmware.xml.gz seem to contain references to many nonfree firmwares.

GNUtoo -

i notice that you do not fill in the descriptions for new
tickets that you open; but instead add a secondary comment
with the details later - the initial ticket form should have
a text field for the description - i wonder is the interface
broken for you maybe

this is also peculiar, because some people are not allowed to
submit the ticket if the description field is empty - redmine
normally rejects the post, with an error message: "description
can not be empty" - i have not investigated that, but i assumed
it was a global behavior

i notice that you do not fill in the descriptions for new
tickets that you open; but instead add a secondary comment
with the details later - the initial ticket form should have
a text field for the description - i wonder is the interface
broken for you maybe

• The first description cannot be edited later on
• I often make mistakes also because I've no preview without JavaScript¹.

¹ JavaScript isn't bad per-se but here it acts as arbitrary execution of code, can be viewed as as a security issue, depending on your threat model. It is a good practice to not tie the security of one's computer to the computer(s) serving serving the JavaScript code and all the infrastructure in between (SSL PKI).

ok, understood - the description can be edited; but it does
require javascript to expose the form

this is the HTML element definition:

<span id="issue_description_and_toolbar" style="display:none">

you could probably do some magic by injecting some CSS with some
styling tool, to make the form always exposed

#issue_description_and_toolbar { display: block ; }

or with local javascript/greasemonkey:

document.getElementById('issue_description_and_toolbar').show()

a better solution would be to prevent redmine from hiding it for
admins and the OP - im sure thats a simple change

Do we really want this? this issue is similar to the ones of third party package managers (pip, npm, flatpak) which offer both free and non-free software. However, the big difference here is that fwupd manages firmware updates, which are a critical component. I think it should not be blacklisted, specially because it provides updates for coreboot devices (e.g. System76)

However, the big difference here is that fwupd manages firmware updates, which are a critical component.

Firmware is indeed critical, so maybe we should not allow the manufacturer to introduce backdoors or shady stuff in further versions.

I think it should not be blacklisted, specially because it provides updates for coreboot devices (e.g. System76)

I don't think that's relevant at all. FSDG doesn't care about how important it is for you to update your blob-infested System76 laptop, but rather about shipping a system that is as free as possible, which blacklisting fwupd would help achieve.

Do we really want this? this issue is similar to the ones of third party package managers (pip, npm, flatpak) which offer both free and non-free software.

Well, seeing it from that perspective, then yeah, maybe fwupd shouldn't be blacklisted, it's just that maybe most firmware is proprietary. I don't know, avoiding proprietary firmware feels like one of the main reasons things like Parabola and Linux-libre exist, so it doesn't feel right to have a tool like this.

Let me know what y'all think.

See also #3000.
As mentioned there, we can either:
1. Blacklist entirely
2. Blacklist and replace with libre version which patches out references to LVFS
3. Number 2 but also add references to an LVFS replacement repo which only hosts libre firmware

As 3 is not yet possible due to no such repo existing and 2 would incur a maintenance overhead for a package that doesn't do much in the free world because no FSDG-compliant repo exists to use it with, 1 is the only option we have at the moment.

Please add any other options if you think of one.