Qubesdb with commit

[hannesm]

Hello,

we extended the Qubes.DB module to provide two new functions:

• got_new_commit : t -> string -> map Lwt.t
• values : t -> string -> map Lwt.t

The first resolves once the provided key is written to with an empty string (this is used in Qubes to signal a commit). It provides a partial map, where only keys with key as prefix are contained. The function values does the latter.

The reason for these functions is to properly react to QubesDB updates (in our case, firewall updates), and not using a QubesDB where firewall rules are only partially written. This cannot be implemented with just the provided after.

[talex5]

got_new_commit looks racy to me. If events are signalled for two keys in quick succession, we might only see one of them (and ignore it, if we're waiting for the other one).

I think it would also be safer to take the old value as an input, so we can return immediately if the caller is already out-of-date. Otherwise, the caller has to call values immediately after starting the got_new_commit operation, and it would be easy to get that wrong.

[hannesm]

Hi @talex5, thanks for your review.

In 02da172 we addressed the race conditions (see comments at the end of dB.ml). Do you think this covers all cases of the racy behaviour.

[hannesm]

@talex5 we pushed an updated, (hopefully) race-free version for got_new_commit (a bit complicated since multiple "transactions" may be in progress, thus a "commit" (empty write) only updates the key it commited). Its implementation was guided after the usages of the qubes-firewall and the firewall rules.