{"push_id":2479301224,"size":1,"distinct_size":1,"ref":"refs/heads/removebkdb","head":"977d75af9b19e8c2223adf4911a831f7e86f2727","before":"bbdc89761bacabcc52a975da2700a9efb34929a2","commits":[{"sha":"977d75af9b19e8c2223adf4911a831f7e86f2727","author":{"name":"Chris Adams","email":"c70a9ce81e2a2845c7de39e473936954532fd1e5@jollamobile.com"},"message":"Replace master bookkeeping database with per-plugin metadata dbs\n\nOMP recently gave requirement that we must support importing keys from\nplugins.  Plugins can ship with different collections and keys already\ndefined.\n\nGiven that some plugins (e.g. backed by USB tokens) might define\nidentical and specific collection names, we cannot adequately ensure\nthat secretName+collectionName pairs are unique without \"breaking\"\nthe behaviour the plugin would document for its clients.\n\nFurthermore, some plugins might source data from elsewhere (e.g.\nin the case of gpgme, database entries might come from other processes,\nor in the case of some online-backed store, from the online service).\n\nFinally, some plugins might not (or might not be able to) export any\ninformation about available collections/keys on the device until the\ndevice has been unlocked via an asynchronous user prompt, which\nprovides opportunity for a collection with a conflicting name to be\nadded into a separate plugin prior to unlock occuring.\n\nTo resolve these issues, we now require a secret (or key) to be\nidentified by a tuple of secretName+collectionName+storagePluginName.\nMetadata for each plugin is stored in per-plugin databases, which\nallows transactions to be used to ensure metadata and plugin-stored\ndata are modified atomically, and all on the same thread, to avoid\nmultithreading issues (e.g. metadata modification interleaves) and to\nmitigate abrupt power loss failures.","distinct":true,"url":"https://api.github.com/repos/sailfishos/sailfish-secrets/commits/977d75af9b19e8c2223adf4911a831f7e86f2727"}]}
{"actor":{"display_login":"chriadam"}}