[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,