lvfs-announce.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
* [Lvfs-announce] New functionality for managing ODM and OEM relationships
@ 2019-09-10 10:23 Richard Hughes
  0 siblings, 0 replies; only message in thread
From: Richard Hughes @ 2019-09-10 10:23 UTC (permalink / raw)
  To: lvfs-announce

Hi all,

The LVFS previously had lots of hardcoded assumptions that the ODM
uploads the firmware, performs some testing in embargo and then
transfers ownership to the OEM which add update details, and moved the
firmware to testing and stable. This doesn’t match reality for a
number of large vendors on the LVFS (for example, where the ODM
manages all parts of the update flow), and so we need to provide
something more flexible. There is also the problem where sometimes the
ODM was being “credited” with the firmware upload, when we really
don’t want to leak out the ODM→OEM relationship even accidentally.

To do this I’ve changed slightly how we assign the firmware on upload.
Each OEM has a set of AppStream prefixes that match the <id> values
uploaded to the LVFS. The idea is that, for instance, Compal would
never own firmware with com.dell.* and only the Dell account can do
that. This would stop the ODM accidentally owning firmware that should
be credited to the OEM.

The user who uploaded the firmware is part of a vendor group, and this
is how we get the ODM vendor information. If an affiliation has been
defined between the OEM and ODM then the ODM can manage the firmware
on the LVFS. We can now define what “manage” means, with the most
simple permissions being “just view” and the most complete permissions
being “view, modify, delete, move to testing, move to stable, etc”.

For all the vendors on the LVFS I have assigned vendor prefixes based
upon existing values uploaded, and for vendors with no uploaded
firmware a prefixed based on the reverse DNS of the OEM homepage has
been used. For instance, the Dell account now has ‘com.dell’ assigned.
OEMs can have multiple vendor prefixes assigned where required, and
the vendor prefix doesn’t have to match the domain name in every case.

There are a lot of existing ODM<->OEM vendor relationships on the
LVFS. I’ve converted the existing relationships to be a safe subset of
the existing permissions on the affiliate relationship. For vendors
who are currently managing the end-to-end flow the OEM vendor manager
will need to add extra allowed actions for the ODM. You may need to
ask your OEM vendor manager to do this, or me.

I’m aware this subtly changes the way some ODMs are using the LVFS
right now, and I’m happy to help both OEMs and ODMs choose actions
that reflect the current business relationship. There might be
firmware files that I’ve not fixed, or where affiliations need to be
added or modified, and please email me if you’re suddenly unable to do
an action that you expected to be able to do. I think I've chosen the
right settings for each existing affiliate.

Existing firmware in testing and stable isn’t affected by the new
rules, and this will only affect new firmware. I have changed the
assigned vendor for firmware currently in the stable remotes to become
the OEM vendor. I’m confident the new functionality will allow us to
grow the LVFS even further and be more flexible as new OEMs and ODMs
join.

Richard.

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2019-09-10 10:23 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-10 10:23 [Lvfs-announce] New functionality for managing ODM and OEM relationships Richard Hughes

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).