1. Create hsi_history table to store the security attributes.
2. Convert all security entities to a json string and write to database.
Signed-off-by: Kate Hsuan <hpa@redhat.com>
Changes in v1:
1. Fixed typo: "his_history" to "hsi_history"
2. g_autofree all gchar pointer.
3. Removed unnecessary g_warning messages.
4. Moved the json format comment to Document comment.
5. Add an error handling for json converter.
Changes in v2:
1. Declare all pointers using g_auto_ptr.
2. The warning messages of JSON conversion and DB writing errors were added.
3. "Since: 1.7.0" was added to the document comment.
Changes in v3:
1. Fix variable declaration.
2. Remove unecessary data type casting.
Changes in v4:
1. Fix migration schema.
Changes in v5:
1. Fix hsi_history column name declaration.
Changes in v6:
Column name was modified from last to timestamp.
The end year is legally and functionally redundant, and more importantly causes
cherry-pick conflicts when trying to maintain old branches. Use git for history.
The root of this problem is that we were trying to use pending.db as both a
pending report store and also a record of history, so you could see updates for
device foo 1.2.3->1.2.4 and then 1.2.4->1.2.5.
This sort-of half worked, but it meant in some cases we matched on the old
device version, sometimes on the new release version and sometimes matching on
either.
The problem was that in various places we were using the device ID as *the*
primary key, and so we had various functions like fu_history_get_device_by_id()
that expected to return just one device, not several.
The device ID also changes if the device is moved from USB plug to another, and
so it got even more complicated again trying to de-dupe the devices.
The sanest thing to do is to decide that pending.db only contains the latest
attempt to go from one version to another using device-id as the primary key.
This makes reporting work reliably now, although has the effect you can't
report a 1.2.3->1.2.4 and 1.2.4->1.2.5 at the same time. Note, if you tried to
do the latter before, the update-error (if set) would be wrong on the second
report...
For the 1.3.3 release make it all simpler and so the reporting works reliably.
Longer term we can design a better database schema that uses unique ID to
represent the *transaction* itself, that isn't tied to the device ID in any way.
This might mean extending the DBus API to cope with multiple devices being
returned with the same device-id set.
If this happens:
1.2.3 -> 1.2.4 = failure
1.2.3 -> 1.2.5 = success
...we want to preserve both in the history database so they can both be shared
with the LVFS. Use the device ID and the new and old firmware versions when
modifying and deleting entries.
This fix is made slightly more tricky as we have to drop the PRIMARY KEY
attribute on the device_id, and due to a limitation in SQLite, it means copying
the old history into a new table.
Rename FuPending to FuHistory to better represent what the object is now doing.
Also, while we're here, switch to using SQLite prepared statements to avoid a
possible invalid read on i386 hardware.
