Clément DOUIN
Clément DOUIN
Interesting, thanks for the precision. What do you advise then?
Requires #220 for the CI not to complain about dual keystores.
> At an intermediate level, this feels like it should be structured as a separate credential store module (and feature) that relies on (and requires) both secret-service and keyutils. Rather...
After all, both ideas can be complementary, as they serve different purposes: - A dedicated store for secret service + keyutils makes sense if you want to have a solid,...
Maybe `linux-native` makes even more sense than `linux-native-persistent`: it aligns with other `apple-native` and `windows-native` (providing a persistent store). `keyutils` and `{sync,async}-secret-service` could still be used independently if needed. Let...
I had hard time to deal with this new keystore with the actual cargo features management. As I expected, it became a mess of conditions in order to make default...
> 3. I don't see any reason to support both sync and async secret-service usage in this brand new keystore. Just supporting the dbus-secret-service will provide a lot of advantages:...
I just pushed changes. Somehow, by keeping the `secret-service` feature guard it makes conditions lighter. Plus it enables the ability to use both keyutils with zbus secret service (which is...
The cargo feature condition you were proposing did not work, so I adjusted them. Ready for the next review!
> I am happy to do copy editing in a review Sure, maybe it is better this way as I may not word properly things. You can also push a...