ExternalVendorCode/serval-dna
1
0
Fork 0
mirror of https://github.com/servalproject/serval-dna.git synced 2024-12-30 18:07:01 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Issue #17, improve "rhizome extract manifest" logic

Browse Source 
Do not store negatives in the MANIFESTS 'author' column, just positives, so
that newly-unlocked identities are still checked.

Comment in rhizome_database.c about the semantics of the MANIFESTS.author
column.
This commit is contained in:
Andrew Bettison 2012-10-15 18:08:31 +10:30
parent c43a7ba8e6
commit f6d9e6cb0e
1 changed files with 25 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
rhizome_database.c
View File

@ -152,6 +152,30 @@ debugflags_t sqlite_set_debugmask(debugflags_t newmask)
return oldmask; return oldmask;
} }
/*
* The MANIFESTS table 'author' column records the cryptographically verified SID of the author
* that has write permission on the bundle, ie, possesses the Rhizome secret key that generated the
* BID, and hence can derive the Bundle Secret from the bundle's BK field:
* - The MANIFESTS table 'author' column is set to the author SID when a bundle is created
* locally bu a non-secret identity, so no verification need ever be performed for one's own
* bundles while they remain in the Rhizome store.
* - When a bundle is imported, the 'author' column is set to NULL to indicate that no
* verification has passed yet. This includes one's own bundles that have been purged from
* the local Rhizome store then recovered from a remote Rhizome node.
* - When a manifest with NULL 'author' is examined closely, ie extracted, not merely
* listed, the keyring is searched for an identity that is the author. If an author is
* found, the MANIFESTS table 'author' column is updated. This allows one to regain the
* ability to overwrite one's own bundles that have been lost but recovered from an exterior
* Rhizome node.
* - The above check automates the "own bundle recovery" mechanism at the expense of a CPU-heavy
* cryptographic check every time a foreign bundle is examined, but at least listing is fast.
* This will not scale as many identities are added to the keyring. It will eventually have to be
* replaced with a means to cache positive and negative verifications in the Rhizome db for local,
* non-secret identities.
*
* -- Andrew Bettison <andrew@servalproject.com>, October 2012
*/
int rhizome_opendb() int rhizome_opendb()
{ {
if (rhizome_db) return 0; if (rhizome_db) return 0;
@ -1412,10 +1436,9 @@ int rhizome_retrieve_manifest(const char *manifestid, rhizome_manifest **mp)
WHY("Error updating MANIFESTS author column"); WHY("Error updating MANIFESTS author column");
break; break;
} }
} else if (strcmp(q_author, "unknown") == 0) {
q_author = NULL; // don't output the ".author" field
} else if (stowSid(m->author, 0, q_author) == -1) { } else if (stowSid(m->author, 0, q_author) == -1) {
WARNF("MANIFESTS row id=%s contains invalid author=%s -- ignored", q_manifestid, alloca_str_toprint(q_author)); WARNF("MANIFESTS row id=%s contains invalid author=%s -- ignored", q_manifestid, alloca_str_toprint(q_author));
q_author = NULL; // don't output the ".author" field
} else { } else {
// If the AUTHOR column contains a valid SID, then it means that author verification has // If the AUTHOR column contains a valid SID, then it means that author verification has
// already been done (either implicitly when the bundle was added locally, or explicitly // already been done (either implicitly when the bundle was added locally, or explicitly