F39 Change Proposal: Enable fwupd-refresh.timer by default on IoT, CoreOS & Server Editions (Self-Contained)

[Aoife Moloney]

https://fedoraproject.org/wiki/Changes/EnableFwupdRefreshByDefault

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


== Summary ==
fwupd-refresh systemd service unit & timer are designed to regularly
refresh the fwupd metadata and update the MOTD when new firmware
updates can be applied on a system. We want to enable the
fwupd-refresh.timer by default on IoT, CoreOS & Server editions so
that users get reminded about firmware updates.

On desktops, firmware updates are generally coordinated by graphical
applications such as GNOME Software or Plasma Discover so we will not
enable it on those editions.

== Owner ==
* Name:[[User:Siosm| Timothée Ravier]], [[User:ravanelli| Renata Ravanelli]]
* Email: travier(a)redhat.com, rravanel(a)redhat.com


== Detailed Description ==

Firmware for hardware devices can have bugs and firmware updates
generally help address those. Firmware updates might however need
manual interaction, a reboot or device unplug/re-plug so we can not
enable firmware update by default.

This change thus only enable notifying about new firmware updates, not
installing them.

With this change, Fedora installations will contact the Linux Vendor
Firmware Service CDN (LVFS, https://cdn.fwupd.org/) to get the updated
metadata but will not send any information about the hardware without
user interaction.

See the LVFS privacy policy at
https://lvfs.readthedocs.io/en/latest/privacy.html.


== Feedback ==

Discussion for each impacted edition:

* CoreOS: https://github.com/coreos/fedora-coreos-tracker/issues/1512 (Accepted)
* IoT: https://pagure.io/fedora-iot/issue/52 (Accepted)
* Server: https://pagure.io/fedora-server/issue/115 (Accepted)

== Benefit to Fedora ==
Knowing when firmware updates can be applied on a system would make
systems more reliable.

== Scope ==
* Proposal owners: Do the change required to enable
fwupd-refresh.timer by default

* Other developers: N/A

* Release engineering: N/A [https://pagure.io/releng/issues #Releng
issue number]

* Policies and guidelines: N/A (not needed for this Change)

* Trademark approval: N/A (not needed for this Change)

* Alignment with Community Initiatives: N/A


== Upgrade/compatibility impact ==
No impact, it is just a refresh to check about new firmware updates.
It will be enabled for existing and new systems.


== How To Test ==
Install a system on hardware that has an old firmware and check if you
get a notification about a new firmware update on login in the MOTD.

== User Experience ==
User will still have to manually update their firmware.

== Dependencies ==
There are no dependencies

== Contingency Plan ==
* Contingency mechanism: Continue to ship things the way we ship them today
* Contingency deadline: N/A
* Blocks release? N/A

== Documentation ==

N/A (not a System Wide Change)

== Release Notes ==


-- 
Aoife Moloney

Product Owner

Community Platform Engineering Team

Red Hat EMEA

Communications House

Cork Road

Waterford

[Dan Čermák]

Hi,

Aoife Moloney <amoloney(a)redhat.com&gt; writes:

>  https://fedoraproject.org/wiki/Changes/EnableFwupdRefreshByDefault
>  
*snip*
>  == Detailed Description ==
>
>  Firmware for hardware devices can have bugs and firmware updates
>  generally help address those. Firmware updates might however need
>  manual interaction, a reboot or device unplug/re-plug so we can not
>  enable firmware update by default.
>
>  This change thus only enable notifying about new firmware updates, not
>  installing them.
>
>  With this change, Fedora installations will contact the Linux Vendor
>  Firmware Service CDN (LVFS, https://cdn.fwupd.org/) to get the updated
>  metadata but will not send any information about the hardware without
>  user interaction.
>
>  See the LVFS privacy policy at
>  https://lvfs.readthedocs.io/en/latest/privacy.html.
>  
I like this, it's a very unobtrusive change and will point some admins
to apply firmware updates. Thanks for this idea!


Cheers,

Dan

[Neal Gompa]

On Sat, Jul 22, 2023 at 3:32 PM Dan Čermák
<dan.cermak(a)cgc-instruments.com&gt; wrote:
>  Hi,
>
>  Aoife Moloney <amoloney(a)redhat.com&gt; writes:
>
>  > https://fedoraproject.org/wiki/Changes/EnableFwupdRefreshByDefault
>  >
>  *snip*
>  >
>  > == Detailed Description ==
>  >
>  > Firmware for hardware devices can have bugs and firmware updates
>  > generally help address those. Firmware updates might however need
>  > manual interaction, a reboot or device unplug/re-plug so we can not
>  > enable firmware update by default.
>  >
>  > This change thus only enable notifying about new firmware updates, not
>  > installing them.
>  >
>  > With this change, Fedora installations will contact the Linux Vendor
>  > Firmware Service CDN (LVFS, https://cdn.fwupd.org/) to get the updated
>  > metadata but will not send any information about the hardware without
>  > user interaction.
>  >
>  > See the LVFS privacy policy at
>  > https://lvfs.readthedocs.io/en/latest/privacy.html.
>  >
>
>  I like this, it's a very unobtrusive change and will point some admins
>  to apply firmware updates. Thanks for this idea!
>  
Actually, why wouldn't this be used everywhere? I could see this be
useful when people remote into workstations and apply updates. I know
of plenty of people that split their desktops between local and remote
access/administration.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Timothée Ravier]

>  Actually, why wouldn't this be used everywhere? I could see this
> be
>  useful when people remote into workstations and apply updates. I know
>  of plenty of people that split their desktops between local and remote
>  access/administration. 
We could enable it everywhere but we've not reached out to desktop editions for
comments.

Process wise, that could potentially move this Change from Self Contained to System Wide.

[Neal Gompa]

On Tue, Jul 25, 2023 at 8:52 AM Timothée Ravier <siosm(a)fedoraproject.org&gt; wrote:
>  > Actually, why wouldn't this be used everywhere? I could see this be
>  > useful when people remote into workstations and apply updates. I know
>  > of plenty of people that split their desktops between local and remote
>  > access/administration.
>
>  We could enable it everywhere but we've not reached out to desktop editions for
> comments.
>
>  Process wise, that could potentially move this Change from Self Contained to System Wide.
Sure, but it's simple enough that I wouldn't worry about that. There's
also the fact that outside of the GNOME and KDE variants, nobody has a
graphical firmware update management tool. So what are they supposed
to do or use?

Would these messages show up, for example, if they opened the terminal app?




--
真実はいつも一つ！/ Always, there's only one truth!

[Timothée Ravier]

>  Would these messages show up, for example, if they opened the
> terminal app? 
They only show up on the console / ssh login prompt if I'm not mistaken:
https://github.com/fwupd/fwupd/tree/main/data/motd

[Stephen Gallagher]

On Tue, Jul 25, 2023 at 10:39 AM Timothée Ravier
<siosm(a)fedoraproject.org&gt; wrote:
>  > Would these messages show up, for example, if they opened the terminal app?
>
>  They only show up on the console / ssh login prompt if I'm not mistaken:
> https://github.com/fwupd/fwupd/tree/main/data/motd 
That means they will show up anywhere that pam_motd is in the session
stack. Currently, that's only sshd logins, but that's a discussion we
could have.

[Ralf Corsépius]

Am 23.07.23 um 00:39 schrieb Neal Gompa:
>  Actually, why wouldn't this be used everywhere? 
Because fwupd only works on a small set of machines?

Ralf

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 26 July 2023 at 06:23, Ralf Corsépius wrote:
>  Am 23.07.23 um 00:39 schrieb Neal Gompa:
>  > Actually, why wouldn't this be used everywhere?
>  
>  Because fwupd only works on a small set of machines? 
Define small. :)

It works, for example, on any machine that has a Logitech Unifying/
Lightspeed/Nano Receiver. I used it to upgrade firmware on the three
or four dongles that I have around with a security fix (that would
require finding a Windows box and plugging them in there otherwise).

Also, UEFI dbx updates are available through fwupdmgr, which I think
affects a large set of machines (all UEFI).

Regards,
Dominik
-- 
Fedora   https://fedoraproject.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
        -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

[Ralf Corsépius]

Am 26.07.23 um 08:48 schrieb Dominik 'Rathann' Mierzejewski:
>  On Wednesday, 26 July 2023 at 06:23, Ralf Corsépius wrote:
> > Am 23.07.23 um 00:39 schrieb Neal Gompa:
> >> Actually, why wouldn't this be used everywhere?
> >
> > Because fwupd only works on a small set of machines?
>  
>  Define small. :) 
Almost none?

It could be "my bubble", but for me, in all these fwupd is around, it 
has never, ever worked on any piece of HW for me.

Ralf

[Tomasz Torcz]

On Wed, Jul 26, 2023 at 09:45:13AM +0200, Ralf Corsépius wrote:
>  
>  
>  Am 26.07.23 um 08:48 schrieb Dominik 'Rathann' Mierzejewski:
>  > On Wednesday, 26 July 2023 at 06:23, Ralf Corsépius wrote:
>  > > Am 23.07.23 um 00:39 schrieb Neal Gompa:
>  > > > Actually, why wouldn't this be used everywhere?
>  > > 
>  > > Because fwupd only works on a small set of machines?
>  > 
>  > Define small. :)
>  
>  Almost none?
>  
>  It could be "my bubble", but for me, in all these fwupd is around, it has
>  never, ever worked on any piece of HW for me. 
  I had fwupdmgr successfuly update firmware on:
  - few ThinkPad laptops
  - ThinkStation desktop PC
  - Logi wireless mouse dongle
  - Lenovo USB-C docking station
  - Samsung NVMe drive

 fwupdmgr also have opt-in reporting
(https://lvfs.readthedocs.io/en/latest/telemetry.html),
but I'm not aware if update success/failure statistics are reported anywhere.

-- 
Tomasz Torcz                        To co nierealne – tutaj jest normalne.
tomek(a)pipebreaker.pl              Ziomale na życie mają tu patenty specjalne.

[Solomon Peachy]

On Wed, Jul 26, 2023 at 09:45:13AM +0200, Ralf Corsépius wrote:
>  It could be "my bubble", but for me, in all these fwupd is
> around, it has
>  never, ever worked on any piece of HW for me. 
Most of the stuff I have that is updated through fwupd are peripherals 
[1] that are independent of the system vendor.

That said, my two primary systems are a Lenovo laptop and an HP 
workstation that are fully supported by fwupd/lvfs, and the UEFI dbx 
stuff works on all of the remaining physical systems (including servers) 
I still have deployed.  Things will only get better from here.

[1] Off the top of my head: Logitech wireless stuff, Jabra conference 
    speaker, synaptics fingerprint sensor, (Samsung?) NVME storage, and 
    probably more..

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
Dowling Park, FL                      speachy (libra.chat)

[Ralf Corsépius]

Am 26.07.23 um 15:55 schrieb Solomon Peachy via devel:
>  On Wed, Jul 26, 2023 at 09:45:13AM +0200, Ralf Corsépius wrote:
> > It could be "my bubble", but for me, in all these fwupd is around, it has
> > never, ever worked on any piece of HW for me.
>  
>  Most of the stuff I have that is updated through fwupd are peripherals
>  [1] that are independent of the system vendor.
>  
>  That said, my two primary systems are a Lenovo laptop and an HP
>  workstation that are fully supported by fwupd/lvfs, 
My (older) lenovo laptop and my HPE Micro-Server are obviously not.

>  and the UEFI dbx
>  stuff works on all of the remaining physical systems (including servers) 
To my big
surprise, for the first time ever, today fwupd installed a dbx 
update on one of my machine - Now, I am still wondering why it didn't do 
so on another, similar machine ;)

>  [1] Off the top of my head: Logitech wireless stuff, Jabra
> conference
>       speaker, synaptics fingerprint sensor, (Samsung?) NVME storage, and 
This is
the second time, somebody mentions Samsung NVMEs were supported. 
Well, what shall I say.

I have several of them (and Samsung SATA SSDs), but so far, I always had 
to resort to other means of updating their firmware (Windows+Magician or 
iso-images), because fwupd would not want to update.

Ralf

[Solomon Peachy]

On Wed, Jul 26, 2023 at 04:36:13PM +0200, Ralf Corsépius wrote:
>  My (older) lenovo laptop and my HPE Micro-Server are obviously not.
The laptop is a T495 (introduced late 2019), but the workstation is an 
older HP Z440 (introduced in late 2014!)

>  This is the second time, somebody mentions Samsung NVMEs were
> supported.
>  Well, what shall I say. 
I wouldn't go so far as to say _all_ Samsung NVMEs are supported, but 
the unit in my laptop had an update published, though it appears that 
Lenovo was the one that submitted it.

>  I have several of them (and Samsung SATA SSDs), but so far, I always
> had to
>  resort to other means of updating their firmware (Windows+Magician or
>  iso-images), because fwupd would not want to update. 
None of the other SSDs I have deployed (Samsung and Crucual SATA) are 
updatable via LVFS, unfortunately.  But, hilariously, both Samsung and 
Crucial's official updaters appear to be self-contained linux ISOs.  So 
clearly the technical capability is there...

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
Dowling Park, FL                      speachy (libra.chat)

[Chris Adams]

Once upon a time, Solomon Peachy <pizza(a)shaftnet.org&gt; said:
>  None of the other SSDs I have deployed (Samsung and Crucual SATA) are
>
>  updatable via LVFS, unfortunately.  But, hilariously, both Samsung and 
>  Crucial's official updaters appear to be self-contained linux ISOs.  So 
>  clearly the technical capability is there... 
The difference is often the update method.  fwupd supports a specific
standard way of applying firmware updates, but often things use very
proprietary methods.  Some storage may not support applying updates
while be accessed for example (so have to boot from ISO/etc. to apply
while unmounted).

While there's a standard for updating UEFI firmware, lots of
motherboards still use older custom methods.  Also, many are unable to
carry over config properly, so they reset all settings on a firmware
update (which is problematic and arguably a reason for making it harder
to do).  I think most of the systems I've used that support fwupd UEFI
updates are able to do so without a config reset.

Which... having to have a config reset on a firmware update in this day
is so dumb.  Very rarely do config options change (and even then, it is
typically "new options added", not old options changed), so there's
really no excuse for not storing the config in a forward-compatible way
and restoring those settings after a firmware update.  Dell PowerEdge
servers have managed this for years, why can't they apply it to
everything?

And also, why can't Dell get PowerEdge updates into LVFS? :)

-- 
Chris Adams <linux(a)cmadams.net&gt;

[Leon Fauster]

Am 26.07.23 um 18:00 schrieb Chris Adams:
>  Once upon a time, Solomon Peachy <pizza(a)shaftnet.org&gt; said:
> > None of the other SSDs I have deployed (Samsung and Crucual SATA) are
> > updatable via LVFS, unfortunately.  But, hilariously, both Samsung and
> > Crucial's official updaters appear to be self-contained linux ISOs.  So
> > clearly the technical capability is there...
>  
>  The difference is often the update method.  fwupd supports a specific
>  standard way of applying firmware updates, but often things use very
>  proprietary methods.  Some storage may not support applying updates
>  while be accessed for example (so have to boot from ISO/etc. to apply
>  while unmounted).
>  
>  While there's a standard for updating UEFI firmware, lots of
>  motherboards still use older custom methods.  Also, many are unable to
>  carry over config properly, so they reset all settings on a firmware
>  update (which is problematic and arguably a reason for making it harder
>  to do).  I think most of the systems I've used that support fwupd UEFI
>  updates are able to do so without a config reset.
>  
>  Which... having to have a config reset on a firmware update in this day
>  is so dumb.  Very rarely do config options change (and even then, it is
>  typically "new options added", not old options changed), so there's
>  really no excuse for not storing the config in a forward-compatible way
>  and restoring those settings after a firmware update.  Dell PowerEdge
>  servers have managed this for years, why can't they apply it to
>  everything?
>  
>  And also, why can't Dell get PowerEdge updates into LVFS? :) 

While reading this discussion, I tried it on my local Dell XPS and
was surprised that LVFS suggests a firmware update (bios) for my
model (it says that I'm 4 versions behind), albeit on Dell's support
page such updates are not listed (here I would have already the latest).

Not sure about the integrity / quality of the uploads to LVFS??

Does anyone know how to compare the artifacts on LVFS (.cab) with
the ones on Dell's support page (.exe, .rcv)?


-- 
Leon

[Peter Robinson]

On Wed, Jul 26, 2023 at 3:37 PM Ralf Corsépius <rc040203(a)freenet.de&gt; wrote:
>  Am 26.07.23 um 15:55 schrieb Solomon Peachy via devel:
>  > On Wed, Jul 26, 2023 at 09:45:13AM +0200, Ralf Corsépius wrote:
>  >> It could be "my bubble", but for me, in all these fwupd is around, it
> has
>  >> never, ever worked on any piece of HW for me.
>  >
>  > Most of the stuff I have that is updated through fwupd are peripherals
>  > [1] that are independent of the system vendor.
>  >
>  > That said, my two primary systems are a Lenovo laptop and an HP
>  > workstation that are fully supported by fwupd/lvfs,
>
>  My (older) lenovo laptop and my HPE Micro-Server are obviously not.
>
>  > and the UEFI dbx
>  > stuff works on all of the remaining physical systems (including servers)
>  To my big surprise, for the first time ever, today fwupd installed a dbx
>  update on one of my machine - Now, I am still wondering why it didn't do
>  so on another, similar machine ;)
>
>  > [1] Off the top of my head: Logitech wireless stuff, Jabra conference
>  >      speaker, synaptics fingerprint sensor, (Samsung?) NVME storage, and
>  This is the second time, somebody mentions Samsung NVMEs were supported.
>  Well, what shall I say.
>
>  I have several of them (and Samsung SATA SSDs), but so far, I always had
>  to resort to other means of updating their firmware (Windows+Magician or
>  iso-images), because fwupd would not want to update. 
Ultimately being supported and the vendor actually bothering to
publish the firmware updates is two different things, I see this in
linux-firmware too WRT to in particular the various wireless driver
firmware.

From the NVME PoV the firmware update process is standardised as part
of the NVME spec, in most cases I have found, and I've tried a few
different vendors, you can use fwupdmgr to apply the updates from the
vendor's update zip file.

I blogged about it here:
https://nullr0ute.com/2022/06/using-fwupdmgr-to-update-nvme-firmware/

[Vitaly Zaitsev]

On 26/07/2023 08:48, Dominik 'Rathann' Mierzejewski wrote:
>  Define small. 😄 
Only Dell, HP and Lenovo laptops are fully supported:
https://fwupd.org/lvfs/devices/

fwupd is a great tool on laptops but completely useless on desktops 
since no motherboard vendors support it.

Maybe fwupd should start packaging UEFI BIOS images for desktop 
motherboards without vendor assistance? Images in BIN format can be 
easily downloaded from official websites or extracted from MS Windows 
packages.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Daniel P. Berrangé]

On Wed, Jul 26, 2023 at 09:59:26AM +0200, Vitaly Zaitsev via devel wrote:
>  On 26/07/2023 08:48, Dominik 'Rathann' Mierzejewski wrote:
>  > Define small. 😄
>  
>  Only Dell, HP and Lenovo laptops are fully supported:
>  https://fwupd.org/lvfs/devices/
>  
>  fwupd is a great tool on laptops but completely useless on desktops since no
>  motherboard vendors support it. 
Merely enabling the fwupd to check for available updates has negligible
downside for machines which can't be updated. It'll merely find no updates
available, so the cost is an extra service running periodically and its
network download data usage.

Those devices which do support fwupd have a large enough market share
that it is justifiable to enable it, even if there are many machines
which can't support it.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Vitaly Zaitsev]

On 26/07/2023 10:32, Daniel P. Berrangé wrote:
>  Those devices which do support fwupd have a large enough market
> share
>  that it is justifiable to enable it, even if there are many machines
>  which can't support it. 
Maybe Anaconda should only enable it if the device is supported?

This information can be easily extracted from "fwupdmgr get-devices 
--json" output.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 26 July 2023 at 10:49, Vitaly Zaitsev via devel wrote:
>  On 26/07/2023 10:32, Daniel P. Berrangé wrote:
>  > Those devices which do support fwupd have a large enough market share
>  > that it is justifiable to enable it, even if there are many machines
>  > which can't support it.
>  
>  Maybe Anaconda should only enable it if the device is supported?
>  
>  This information can be easily extracted from "fwupdmgr get-devices --json"
>  output. 
That only covers devices physically connected or otherwise available at
installation time. You could, for example, buy a supported Logitech
Receiver later and you wouldn't get firmware updates notification if
fwupdmgr-refresh was not enabled because no supported devices were found
at installation time.

Regards,
Dominik
-- 
Fedora   https://fedoraproject.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
        -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

[Vitaly Zaitsev]

On 26/07/2023 11:04, Dominik 'Rathann' Mierzejewski wrote:
>  You could, for example, buy a supported Logitech
>  Receiver 
I don't recommend anyone to buy this proprietary hardware:

>  The vulnerabilities allow attackers to sniff on keyboard traffic, but
> also inject keystrokes (even into dongles not connected to a wireless keyboard) and take
> over the computer to which a dongle has been connected.
https://www.zdnet.com/article/logitech-wireless-usb-dongles-vulnerable-to...

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Alexander Ploumistos]

On Wed, Jul 26, 2023 at 12:14 PM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  On 26/07/2023 11:04, Dominik 'Rathann' Mierzejewski wrote:
>  > You could, for example, buy a supported Logitech
>  > Receiver
>
>  I don't recommend anyone to buy this proprietary hardware:
>
>  > The vulnerabilities allow attackers to sniff on keyboard traffic, but also inject
> keystrokes (even into dongles not connected to a wireless keyboard) and take over the
> computer to which a dongle has been connected.
>
> https://www.zdnet.com/article/logitech-wireless-usb-dongles-vulnerable-to...
And thanks to fwupd and Logitech's embracing it, we had the fix in a
very short time.

What Dominik wrote would apply e.g. for an NVMe replacement drive from
Kingston or Samsung (proprietary hardware too, it's a shocker).

[Vitaly Zaitsev]

On 26/07/2023 11:24, Alexander Ploumistos wrote:
>  What Dominik wrote would apply e.g. for an NVMe replacement drive
> from
>  Kingston or Samsung (proprietary hardware too, it's a shocker). 
None of my 5 Samsung SSDs are supported (3 NVMe and 2 SATA). But they 
can be updated from MS Windows.

I guess only built-in Samsung OEM drives can be updated with fwupd.

>  And thanks to fwupd and Logitech's embracing it, we had the fix
> in a
>  very short time. 
It has only been partially fixed. A complete fix would require replacing 
all existing hardware:

>  Mengs says this vulnerability exists due to an incomplete fix for
> CVE-2016-10761, one of the infamous MouseJack vulnerabilities, and that Logitech has no
> plans on patching this new attack variation. 
-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Björn Persson]

Vitaly Zaitsev via devel wrote:
>  On 26/07/2023 11:04, Dominik 'Rathann' Mierzejewski wrote:
>  > You could, for example, buy a supported Logitech
>  > Receiver  
>  
>  I don't recommend anyone to buy this proprietary hardware: 
For years I tried to use Bluetooth mice, thinking a standard would be
preferable over a proprietary protocol. But Bluetooth never worked well
for me. It's not just mice. Everything I've tried to do with Bluetooth
has been unstable and unreliable. Eventually I gave up and concluded
that Bluetooth in Fedora is not a thing to rely on. The mice I've used
that connect to Logitech dongles have always been responsive and never
had any connection problems.

Mouse cables get in my way and disturb my work. As long as GUIs and web
programs require a mouse, I need a wireless mouse. Since Bluetooth is
out, Logitech is it.

I'd never use a wireless keyboard though. Whether Bluetooth or Logitech,
I'm not going to type passphrases over some iffy radio protocol using a
random number generator of unknown quality.

Alexander Ploumistos wrote:
>  And thanks to fwupd and Logitech's embracing it, we had the fix
> in a
>  very short time. 
I never knew about it until now, because nothing notified me that a
firmware update was available. I have now enabled fwupd-refresh.timer.
I seem to get notifications only in SSH, not on the console, but that's
something at least. If it had been on by default, then it would probably
have been less than four years before I found out about those
vulnerabilities.

If the firmware files are properly authenticated, then I think
notifications about firmware updates should be enabled on all
installations.

Björn Persson

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 26 July 2023 at 21:11, Björn Persson wrote:
>  Vitaly Zaitsev via devel wrote:
>  > On 26/07/2023 11:04, Dominik 'Rathann' Mierzejewski wrote:
>  > > You could, for example, buy a supported Logitech
>  > > Receiver  
>  > 
>  > I don't recommend anyone to buy this proprietary hardware:
>  
>  For years I tried to use Bluetooth mice, thinking a standard would be
>  preferable over a proprietary protocol. But Bluetooth never worked
>  well for me. It's not just mice. Everything I've tried to do with
>  Bluetooth has been unstable and unreliable. Eventually I gave up and
>  concluded that Bluetooth in Fedora is not a thing to rely on.
>  The mice I've used that connect to Logitech dongles have always been
>  responsive and never had any connection problems. 
I had issues with mouse cursor freezing or getting jumpy, because
Logitech wireless protocol still operates in the 2.4GHz band and is
still vulnerable to 2.4GHz Wi-Fi and Bluetooth interference. I had to
switch to 5GHz Wi-Fi on devices in the room or move away those that
didn't support 5GHz before my mouse became usable again.

Regards,
Dominik
-- 
Fedora   https://fedoraproject.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
        -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

[Vít Ondruch]

Dne 26. 07. 23 v 21:11 Björn Persson napsal(a):
>  Vitaly Zaitsev via devel wrote:
> > On 26/07/2023 11:04, Dominik 'Rathann' Mierzejewski wrote:
> >> You could, for example, buy a supported Logitech
> >> Receiver
> > I don't recommend anyone to buy this proprietary hardware:
>  For years I tried to use Bluetooth mice, thinking a standard would be
>  preferable over a proprietary protocol. But Bluetooth never worked well
>  for me.
>  

For years, I am using MS IntelliMouse Explorer for BT, which might be 
already ~15 years old and the only problem I remember is that once, I 
have forgotten that the mouse does not need to be paired so I struggled 
to install it. Other then that, no issues at all.


Vít


>    It's not just mice. Everything I've tried to do with
> Bluetooth
>  has been unstable and unreliable. Eventually I gave up and concluded
>  that Bluetooth in Fedora is not a thing to rely on. The mice I've used
>  that connect to Logitech dongles have always been responsive and never
>  had any connection problems.
>
>  Mouse cables get in my way and disturb my work. As long as GUIs and web
>  programs require a mouse, I need a wireless mouse. Since Bluetooth is
>  out, Logitech is it.
>
>  I'd never use a wireless keyboard though. Whether Bluetooth or Logitech,
>  I'm not going to type passphrases over some iffy radio protocol using a
>  random number generator of unknown quality.
>
>  Alexander Ploumistos wrote:
> > And thanks to fwupd and Logitech's embracing it, we had the fix in a
> > very short time.
>  I never knew about it until now, because nothing notified me that a
>  firmware update was available. I have now enabled fwupd-refresh.timer.
>  I seem to get notifications only in SSH, not on the console, but that's
>  something at least. If it had been on by default, then it would probably
>  have been less than four years before I found out about those
>  vulnerabilities.
>
>  If the firmware files are properly authenticated, then I think
>  notifications about firmware updates should be enabled on all
>  installations.
>
>  Björn Persson
>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>

[Alexander Ploumistos]

On Wed, Jul 26, 2023 at 10:59 AM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  Only Dell, HP and Lenovo laptops are fully supported:
>  https://fwupd.org/lvfs/devices/ 
Not just laptops, desktops/workstations too. In the last six years,
I've had five different models provided by my employers and they were
all fully supported through fwupd.


>  fwupd is a great tool on laptops but completely useless on desktops
>  since no motherboard vendors support it. 
While most custom-built computers don't get full UEFI/BIOS updates,
some hardware manufacturers provide firmware files for components used
by other vendors in their boards. It's a far cry from being on par
with windows, but calling it completely useless is not true either.


>  Maybe fwupd should start packaging UEFI BIOS images for desktop
>  motherboards without vendor assistance? Images in BIN format can be
>  easily downloaded from official websites or extracted from MS Windows
>  packages. 
That would require people volunteering to potentially brick their
machines in order to test the updates. If something goes wrong, the
equipment (and the knowledge) necessary to reprogram a chip is rather
scarce. I'm afraid the way forward is to _convince_ vendors to make
use of the service, starting with those who already have test
accounts.

[Solomon Peachy]

On Wed, Jul 26, 2023 at 11:48:36AM +0300, Alexander Ploumistos wrote:
>  That would require people volunteering to potentially brick their
>  machines in order to test the updates. If something goes wrong, the
>  equipment (and the knowledge) necessary to reprogram a chip is rather
>  scarce. I'm afraid the way forward is to _convince_ vendors to make
>  use of the service, starting with those who already have test
>  accounts. 
I've been debating contributing some code to fwupd to handle several 
different vendors' families of printers, but there's a snowball's chance 
in hell that said vendors will ever embrace lvfs given that they 
steadfastly refuse to publicly acknowledge that Linux exists, despite 
invariably selling a Linux-based print server appliance of some sort.

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
Dowling Park, FL                      speachy (libra.chat)

[Chris Adams]

Once upon a time, Vitaly Zaitsev <vitaly(a)easycoding.org&gt; said:
>  On 26/07/2023 08:48, Dominik 'Rathann' Mierzejewski wrote:
>  >Define small. 😄
>  
>  Only Dell, HP and Lenovo laptops are fully supported:
>  https://fwupd.org/lvfs/devices/
>  
>  fwupd is a great tool on laptops but completely useless on desktops
>  since no motherboard vendors support it. 
It also works on Dell and I think HP desktops... which represent a
significant chunk of the desktop PC market.
-- 
Chris Adams <linux(a)cmadams.net&gt;

[Neal Gompa]

On Wed, Jul 26, 2023 at 8:40 AM Chris Adams <linux(a)cmadams.net&gt; wrote:
>  Once upon a time, Vitaly Zaitsev <vitaly(a)easycoding.org&gt; said:
>  > On 26/07/2023 08:48, Dominik 'Rathann' Mierzejewski wrote:
>  > >Define small. 😄
>  >
>  > Only Dell, HP and Lenovo laptops are fully supported:
>  > https://fwupd.org/lvfs/devices/
>  >
>  > fwupd is a great tool on laptops but completely useless on desktops
>  > since no motherboard vendors support it.
>
>  It also works on Dell and I think HP desktops... which represent a
>  significant chunk of the desktop PC market. 
Framework is in the process of onboarding its firmware updates through
LVFS: https://community.frame.work/t/framework-firmware-on-the-lvfs/4466/14

Star Labs offers firmware through LVFS:
https://us.starlabs.systems/pages/why-choose-us

System76 offers firmware through LVFS: https://fwupd.org/lvfs/vendors/#system76

I don't know the state of TUXEDO Computers or SLIMBOOK for LVFS, but
both are listed as having test accounts on LVFS.

So there's a decent amount of adoption of LVFS even by Linux laptop vendors.



-- 
真実はいつも一つ！/ Always, there's only one truth!