When verifying a signature the valid results are ordered by timestamp. The
CHECKSUM results have a zero timestamp and should have been ordered last.
The sorting callback was wrong, which explains the odd result where we could
downgrade Jcat signatures before we fixed 64ebf9, and nicely explains why we
ignored a timestamp of zero in the first place.
When getting the timestamp, ensure we actually get the newest _signature_ not
just the newest result in case checksums start having timestamps in the future
for some reason. Use new API from libjcat where available, else fall back to
sneaking it out using GObject properties and magic values.
As both hub devices share a FuVliUsbhubDeviceClass instance we cannot 'hijack'
the vfuncs depending on object type. This allows the downstream hub to proxy to
the upstream hub where a GPIOB reset can be performed.
We can have multiple FuVliPdDevice objects registered with the daemon, but they
will all share the FuVliPdDeviceClass instance. If one device requries a
silicon workaround, do not 'hijack' the vfunc for all devices of this type.
This means we do the right thing when updating both the one that requires the
workaround, and the 'normal' one.
Introducing newer gusb caused these builds to run gusb as a subproject
and hence the introspection binaries were looked for.
Fixes: cd65ae ("Require libgusb 0.3.3")
Although this is something that we have always done on the LVFS, corporate
deployments that resign the firmware or metadata might not be signing the files
in the same way.
Always require a timestamp to prevent allowing an inadvertent rollback attack.
Provide the following metadata:
"Dirty firmware" bit
Protocol version
Header type
Maximum PDU Size
Flash protection status
Raw version string
Key Version
Minimum rollback
This should do the bulk transfers using protocol 6.
The output here is now equivalent to the output of
usb_updater2 -d 18d1:501a -f
fwupdtool --plugin-whitelist cros_ec get-devices --verbose
Servo Micro
DeviceId: 84d0e3f2a0f8b2328f7995767b23ebb40494723f
Guid: 8e2f7625-a164-55d7-8f09-f193c8ec33f1 <- USB\VID_18D1&PID_501A&REV_0100
Guid: 13564257-c649-586d-b4e4-4f048d480f36 <- USB\VID_18D1&PID_501A
Serial: CMO653-00166-040491U00771
Summary: Servo Micro (aka "uServo") Debug Board
Plugin: cros_ec_usb
Flags: registered
Vendor: Google Inc.
VendorId: USB:0x18D1
Version: servo_micro_v2.4.17-df61092c3
VersionFormat: plain
Created: 2020-05-20
PhysicalId: usb:03:00:02
Although they normally work, some failures have been reported in the field
related to the MST hub not responding in the MST plugin.
When these failures have occurred the dell_dock plugin also fails to
enumerate.
So rather than allow some people who don't have dell_dock compiled to
update their MST hub using synaptics_mst, perform ALL updates for
mst hub via dell_dock.
```
18:06:24:0324 FuPluginSynapticsMST no device found on drm_dp_aux1: VMM5331 inside Dell dock is only supported by dell_dock
```
In f430da0 we added code that was supposed to copy the verfmt from the component
to the device. We accidentally overwrote the component-provided <name> because
the device had _MD_SET_NAME set.
Use the specific function to just set the verfmt like we intended.
See also: https://github.com/fwupd/fwupd/issues/2119
Reported-by: Anton Farygin <rider@altlinux.org>
Based on a patch by Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
Fixes cross compilation for arm with clang which provides cpuid.h
but helpfully has this error:
```
#if !(__x86_64__ || __i386__)
#error this header is for x86 only
#endif
```
Fixes: #2131
One vendor is shipping a cab archive with two metadata files, both referencing
the same GUID. The 'correct' metainfo description is selected using a GUID
'other device' requirement. This works fine when installing, but breaks when
double clicking on the .cab file as both components are valid, and thus get
returned.
In this case, return the component that matches the requirement 'first' so that
it gets chosen by gnome-software as the default.
This allows the client to easily query metadata to upload with the report,
without exporting rarely used attributes as D-Bus properties on the interface.
It also allows us to add extra metadata values in the future without changing
the public API.
