Some LVFS ideas

[Mario.Li...@dell.com]

Hi All,

 

After some successful feedback on Thunderbolt updates for the XPS 9360 I promoted it to stable.

I don’t have feedback on any of the others I uploaded before the holiday so they’re still in testing.

 

Of course a few days after doing that I got feedback of an issue where the update wasn’t installing.

 

I’m working through that issue with the reporter (https://github.com/dell/thunderbolt-nvm-linux/issues/8 if anyone is curious),

but it really has me thinking about two things missing from the LVFS.

 

1. A way to pull updates back to “testing” without deleting.  Once promoted to stable the only option is to delete and then re-upload to testing.

I think it would be useful in instances like a software problem being found to be able to pull back, sort that issue in the distro etc and re-promote.

 

2. Anonymous telemetry

I know there are all the privacy concerns associated with it, but it would really be great to be able to tell when failures are happening so they can be further investigated.

I don’t care about identifying a particular user, but this is what I think is important:

• Since the last metadata refresh I’ve updated X times from this remote successfully.
  • The successful updates were com.$vendor.$item
  • My distro is $lsb_release -a
  • My fwupd version is $version
• Since the last metadata refresh I’ve updated Y times from this remote unsuccessfully. 
  • The failed updates were com.$vendor.$item
  • My distro is $lsb_release -a
  • My fwupd version is $version
• Exclude any items that were not part of the remote (local install or a different remote).
• Allow users to turn off the feature in the remote conf file (but opt-out to make it useful)

 

So conceptually I see this as an extension to the remote in addition to the HTTP get of the metadata, do an HTTP POST with that information.

 

Thoughts?

[Richard Hughes]

On 5 January 2018 at 16:27, <Mario.Li...@dell.com> wrote:
> A way to pull updates back to “testing” without deleting. Once promoted to
> stable the only option is to delete and then re-upload to testing.

I think you can only demote when non-stable.

> I think it would be useful in instances like a software problem being found
> to be able to pull back, sort that issue in the distro etc and re-promote.

So, that's not really demoting to testing, that's more of a "move back
to private/embargo" surely? Maybe demotion from stable does makes
sense with a warning. If you file it against lvfs-website, I'll fix
it.

> I know there are all the privacy concerns associated with it, but it would
> really be great to be able to tell when failures are happening so they can
> be further investigated.

Winding things back a bit here. I think what you're really asking for
is a way for the client to post some data back to the LVFS about the
update it just tried to apply. From that we can drill down into the
user-agent string and also make some pretty graphs.

> Allow users to turn off the feature in the remote conf file (but opt-out to
> make it useful)

Right.

> Thoughts?

I think a different request on reboot is a much easier thing to audit
than potentially sensitive data. The slight tricky thing doing it
server-side is that we need a way to identify the machine, more than
just an IP address (NAT etc) -- For the ODRS we use a salted hash of
the machine ID, which is probably preferable to anything else. I don't
think that belongs in the user-agent, so that kinda-implies a forceful
opt-in after-download but before flashing.

It's a good idea, and I think it's on the right side of "making things
work reliably" and the users privacy.

Richard

[Mario.Li...@dell.com]

> -----Original Message-----
> From: fw...@googlegroups.com [mailto:fw...@googlegroups.com] On Behalf Of
> Richard Hughes
> Sent: Friday, January 5, 2018 11:10 AM
> To: Limonciello, Mario <Mario_Li...@Dell.com>
> Cc: fwupd <fw...@googlegroups.com>
> Subject: Re: [fwupd] Some LVFS ideas
>
> On 5 January 2018 at 16:27, <Mario.Li...@dell.com> wrote:
> > A way to pull updates back to “testing” without deleting. Once promoted to
> > stable the only option is to delete and then re-upload to testing.
>
> I think you can only demote when non-stable.
>
> > I think it would be useful in instances like a software problem being found
> > to be able to pull back, sort that issue in the distro etc and re-promote.
>
> So, that's not really demoting to testing, that's more of a "move back
> to private/embargo" surely? Maybe demotion from stable does makes
> sense with a warning. If you file it against lvfs-website, I'll fix
> it.

If it was an issue with the firmware - yes. But if it's an issue with fwupd
or one of it's dependencies then I think it makes sense to demote the
firmware from testing but not take it away from the general public.

Here you go:
https://github.com/hughsie/lvfs-website/issues/16

>
> > I know there are all the privacy concerns associated with it, but it would
> > really be great to be able to tell when failures are happening so they can
> > be further investigated.
>
> Winding things back a bit here. I think what you're really asking for
> is a way for the client to post some data back to the LVFS about the
> update it just tried to apply. From that we can drill down into the
> user-agent string and also make some pretty graphs.

Originally I was thinking something similar to the Fedora ABRT tracker or
Ubuntu crash tracker, but it's useful to be able to apply statistical percentages
of successful versus failed updates too.

My thought about doing it on the refresh cycle was mostly tied to server load.

>
> > Allow users to turn off the feature in the remote conf file (but opt-out to
> > make it useful)
>
> Right.
>
> > Thoughts?
>
> I think a different request on reboot is a much easier thing to audit
> than potentially sensitive data. The slight tricky thing doing it
> server-side is that we need a way to identify the machine, more than
> just an IP address (NAT etc) -- For the ODRS we use a salted hash of
> the machine ID, which is probably preferable to anything else. I don't
> think that belongs in the user-agent, so that kinda-implies a forceful
> opt-in after-download but before flashing.

But why do you need to identify the machine?
I think if you could send the relevant non-identifying information with
the status of the update counts should be enough. If a user keeps getting
the same failure daily then that still means there is a problem affecting
the correct statistical "number of installation attempts".

I'm really hoping that we can come up with a solution that doesn't need to be
opt-in.

>
> It's a good idea, and I think it's on the right side of "making things
> work reliably" and the users privacy.
>
> Richard
>

> --
> You received this message because you are subscribed to the Google Groups
> "fwupd" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> fwupd+un...@googlegroups.com.
> To post to this group, send an email to fw...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/fwupd/CAD2FfiHOHddmw7%3DOkG%3DMCj
> KGjwquZQf3nhMeZw8udBz4ZV3Kiw%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.