hughsient

> since they have a low quality default conf file without commented out defaults

Try `man fwupd.conf` for all the options.

You're going to have to be more specific on why a failing HSI attribute contributes to the undoing of your privacy? You're aware the security attributes are each based on mitigating actual real-world attacks, right?

> it devolved into a rabbit hole of turning on all the privacy bugs

What does that mean? We've got a very comprehensive privacy policy... https://lvfs.readthedocs.io/en/latest/privacy.html

Yes, mostly that. Depending on local policy, it might be possible to upgrade [only] signed firmware from the correct vendor without authenticating. Downgrade always requires authentication for obvious reasons. Most firmware requires you to be root (some even CAP_SYS_ADMIN) to just enumerate the hardware and read the firmware version.

The other main reasons is that some hardware is really, really slow (like 8 seconds to query a dock PD version, or 12 seconds to query a thunderbolt retimer version) and you can't really build a GUI that can do firmware update operations with potentially minutes of delay for each action. Also, cache invalidation is hard if you can't see the device uevents and usb hotplug events.

blush -- my blog is https://blogs.gnome.org/hughsie/ for the important stuff, and https://mastodon.social/@hughsie is for the inane stuff.

> this is probably leaking information thru its comm channel

It's really not. The fwupd process doesn't have any internet access at all -- all communication is done through a socket over DBus. All the telemetry is done with the user explicitly opting in -- we even show the JSON in the terminal that is going to be sent.

> Does anyone know why this is running 24/7

We auto-quit on idle or for low memory conditions -- unless you have hardware that's expensive (either in terms of power, or time) like thunderbolt and synaptics MST. The resident RSS is tiny as we mmap all the data files which can be paged out by the kernel -- we can even run fwupd on the tiny BMC processor as well. I'd be interested in what OpenSnitch says, but the D-Bus interface is the only way in and out. Interesting, the daemon doesn't actually do any policy actions itself; all actions have to be initiated by the front end -- which includes downloading new firmware metadata.

Can you open up a discussion on the fwupd GitHub project please, and maybe we can make things better.

Is Slackware a major Linux distribution? There's nothing wrong with Slackware, and no reason why fwupd wouldn't work on that distro -- but it's not one that most people would considered "major" IMHO. There are no GNOME deps on fwupd, although there are a couple of GNOME frontends available -- as there is also a CLI and KDE frontend.

Samsung actually upload firmware to the LVFS on behalf of a few different OEMs, so they certainly know how. It's a policy decision, not a technical or legal one.

Make sure you open a support ticket asking for LVFS updates -- it's easy to ignore one person, but much harder to ignore hundreds of people asking for the same thing.

Is afuefi now open source?

The ColorHug is a colorimeter designed to calibrate screens with an approximately-sRGB gamut. If you're trying to calibrate a wide-gamut screen with a ColorHug it isn't going to work very well. If you need to do anything other than consumer hardware you need to use a spectrophotometer (that can do spectral profiling) rather than a colorimter that's calibrated to different primaries than what it's trying to measure. A spectro is going to cost you at least $300, and a good one is going to cost you somewhat more.

Source: Person that designed the ColorHug hardware.

Apply hasn't cared about ColorSync for years. Every release they break something.

It's barely more than the device costs to make. It turns out making batches of 50 at a time is an order of magnitude more expensive than building them 50,000 at a time.

Source: Am the person that sits in a shed and builds each ColorHug.

Not an easy thing. The ICC-in-X specification specifies the index as the Xinerama screen number, which has no meaning with XRANDR-on-XOrg, and even less meaning on Wayland. There's nothing in the protocol to tie the ID to a monitor, or even a predictable hotplug order. This is why the device-id in colord exists.

Source: colord author.

True, Red Hat have been awesome with my time. Lots of donors are sponsoring the hosting; including Amazon for the bandwidth. There's a link on the lvfs page if you'd like to throw some money in the hat, so to speak. Long term this hopefully gets transferred to the Linux Foundation, although we're still working on the legal niggles. More to share when I know more myself.

True, I have. I've sent many hundreds of emails, but also some companies have reached out to me proactively. We're getting there, but it's going to be a slow burn.

It doesn't look like any work at all is actually being done on fwupd from my point of view. I've basically given up hope at this point that System76 is going to do the right thing.

Source: Am the LVFS and fwupd maintainer.

It's disappointing System76 can't just use LVFS and fwupd like all the other vendors: https://fwupd.org/lvfs/vendorlist