[Lvfs-announce] Migrating legacy groups to vendor-id restricted

Richard Hughes <[email protected]> Sat, 5 Sep 2020 12:42:50 +0100
Newsgroups dev.linux.lists.lvfs-announce
Message-ID <CAD2FfiH3v-58TCZ7wNYJCMsBSNdKrpW3E1T7NYOu=QW2kiDTfQ@mail.gmail.com>
Hi all,

Some of the original LVFS groups are currently set up with no vendor
ID restrictions, probably because they were created long before the
vendor_id feature ever existed. I've already sent email to affected
vendor-managers about this a few days ago.

I=E2=80=99d like to migrate all LVFS groups to be vendor-id restricted. Thi=
s
limits the vendor to only being able to deploy firmware for their own
devices e.g. Dell can't deploy onto Lenovo etc. With the recent growth
of the LVFS, this is something that I think we should enforce.
Limiting the firmware that can be uploaded by a vendor means that an
accidental leak of a user password (or an attack on the LVFS itself)
limits the damage an attacker could do. Just to clarify, there has
been no attack or leak and this is all proactive as result of an
external audit.

I've asked many of you for a list of vendor_id=E2=80=99s for your hardware =
and
many thanks for those that have replied already. As a reminder, you
can get this using "fwupdmgr get-devices" =E2=80=93 for instance:

=E2=94=9C=E2=94=80THNSN5512GPU7:
=E2=94=82 Vendor: Toshiba Corporation (NVME:0x1179)

In this case the vendor ID is the value inside the brackets. You might
need to use a non-obsolete version of fwupd if the vendor ID values
are not visible; using a Fedora 32 LiveCD is a really easy way to use
a new version of fwupd. We can include as many vendor IDs as you need,
of any NVME/ATA/DMI etc prefix.

To speed up adoption a bit, on Monday I will change the vendor embargo
remotes to require vendor_ids. Obviously I don't want to break
anything for stable firmware. If you have an unrestricted account then
testing and stable will continue to be generated with no changes (so
nothing will change for end users). If you're using a embargo remote
for testing you might now get an error like:

Not compatible with vendor: failed predicate:
[XXX:NEVER_GOING_TO_MATCH eq ATA:0x14A4]

...or really, any string that mentions XXX:NEVER_GOING_TO_MATCH. If
you see this please send me an email with the error string and I'll
add the vendor_id straight away and regenerate the metadata; I can add
a vendor ID on the admin panel with one click which applies instantly.

Many thanks,