User Tools

Site Tools


content:activity:naf5

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
content:activity:naf5 [01/12/2013 19:59]
Andrew Bettison [Implementation] add completion dates to tasks
content:activity:naf5 [01/12/2013 20:20] (current)
Andrew Bettison [Technical notes] refer to N5 from within N6
Line 10: Line 10:
   * <BOOKMARK:R4>**R4**. Implement ''servald id relinquish pin <PIN|SID>'', which releases the specified identities, and removes those identities from the local routing table.   * <BOOKMARK:R4>**R4**. Implement ''servald id relinquish pin <PIN|SID>'', which releases the specified identities, and removes those identities from the local routing table.
   * <BOOKMARK:R5>**R5**. Add ability to store tags (which could be IEMI/IMSIs) in keyring entries.    * <BOOKMARK:R5>**R5**. Add ability to store tags (which could be IEMI/IMSIs) in keyring entries. 
-  * <BOOKMARK:R6>**R6**. Implement ''servald id list [<TAG|SID>]'' that lists all unlocked identities, or only those unlocked identities with a supplied SID or tag (which could be the IEMI/IMSI).+  * <BOOKMARK:R6>**R6**. Implement ''servald id list [<TAG>|<SID>]'' that lists all unlocked identities, or only those unlocked identities with a supplied SID or tag (which could be the IEMI/IMSI).
   * <BOOKMARK:R7>**R7**. Extend test suite to cover the above.   * <BOOKMARK:R7>**R7**. Extend test suite to cover the above.
  
Line 30: Line 30:
     * thus, if two daemons are started with the same initially-unlocked identities in their keyrings, there will be a routing conflict on those identities;     * thus, if two daemons are started with the same initially-unlocked identities in their keyrings, there will be a routing conflict on those identities;
   * <BOOKMARK:N4>**N4**. Identity hand-over is not performed opportunistically (eg, at regular intervals), so a network merge between subnets which each had the same identity present will produce a routing conflict on that identity.   * <BOOKMARK:N4>**N4**. Identity hand-over is not performed opportunistically (eg, at regular intervals), so a network merge between subnets which each had the same identity present will produce a routing conflict on that identity.
-  * <BOOKMARK:N5>**N5**. The [[https://github.com/servalproject/serval-dna/blob/21b123212c42c5b2ec94da07ca298b00d3f3d0a9/keyring.c|keyring.c]] code uses the unlocked keyring entries as a positive cache to avoid redundant work+  * <BOOKMARK:N5>**N5**. The existing [[https://github.com/servalproject/serval-dna/blob/21b123212c42c5b2ec94da07ca298b00d3f3d0a9/keyring.c|keyring.c]] code has a few flaws that were not remedied by this contract: 
-    * when unlocking with an entry PIN, the code first checks whether there are already any unlocked entries with the same PIN, and if so, does not perform an unlock scan through the keyring file +    - unlocked keyring entries are used as a positive cache to avoid redundant unlocks
-    * that technique has only ever had a single flaw: +      * when unlocking with an entry PIN, the code first checks whether there are already any unlocked entries with the same PIN, and if so, does not perform an unlock scan through the keyring file 
-      * if a PIN unlocks no entries, then re-trying the same PIN repeats the unlock scan (ie, there is no negative caching of PIN attempts) +      * however, if a PIN unlocks no entries, then re-trying the same PIN repeats the unlock scan (ie, there is no negative caching of PIN attempts) -- functionally this is of no consequence, its only impact is on CPU use and hence potentially on battery life 
-      * functionally this is of no consequence, its only impact is on CPU use and hence potentially on battery life +    - the running Serval DNA daemon does not re-load keyring entries from the keyring file while running, which leads to "stale cache" types of problems: 
-    * the ''id relinquish <PIN>'' command introduces a functional flaw that is revealed by the following sequence of operations:+      if another process modifies the keyring file (eg, runs a ''servald keyring add'' command), the running daemon will not be aware of the change until re-started 
 +      * the long-term objective is to re-implement all keyring operations as requests to the daemon process, which will resolve all "stale cache" and race condition bugs in one go 
 +      * however, in the meantime, the current implementation has some functional limitations ("bugs") of which developers must be aware 
 +  * <BOOKMARK:N6>**N6**.  The ''id relinquish sid'' command introduces a new functional flaw into keyring operations that is revealed by the following sequence of operations:
       * one //enter PIN// command unlocks two more identities       * one //enter PIN// command unlocks two more identities
       * a //relinquish SID// command then locks one of these identities       * a //relinquish SID// command then locks one of these identities
-      * a subsequent //enter PIN// command will not re-unlock that identity, because the positive caching will detect that there are still identities bearing that PIN+      * a subsequent //enter PIN// command will not re-unlock that identity, because the positive caching (see **[[#N5]]**) will detect that there are still identities bearing that PIN
     * hence, in order for //enter PIN// to work as expected, ALL identities already unlocked with that PIN must be relinquished first     * hence, in order for //enter PIN// to work as expected, ALL identities already unlocked with that PIN must be relinquished first
     * for this reason, if the //relinquish SID// command is ever used, then for safety every //enter PIN// command should be immediately preceded by a matching //relinquish PIN// command     * for this reason, if the //relinquish SID// command is ever used, then for safety every //enter PIN// command should be immediately preceded by a matching //relinquish PIN// command
Line 62: Line 65:
 **[[#R4]]** -- **''servald id relinquish pin <PIN|SID>''** (completed 14 October) **[[#R4]]** -- **''servald id relinquish pin <PIN|SID>''** (completed 14 October)
   * commit [[https://github.com/servalproject/serval-dna/commit/ef7351bddc0088f30386efd2c9ebf91ba4ee3fe2|ef7351b]] either:   * commit [[https://github.com/servalproject/serval-dna/commit/ef7351bddc0088f30386efd2c9ebf91ba4ee3fe2|ef7351b]] either:
-    * relinquishes (locks) a single identity specified by its SID (see **[[#N5]]**), or+    * relinquishes (locks) a single identity specified by its SID (see **[[#N6]]**), or
     * locks all identities that were unlocked with a given entry PIN (see **[[#N2]]**)     * locks all identities that were unlocked with a given entry PIN (see **[[#N2]]**)
   * commit [[https://github.com/servalproject/serval-dna/commit/d5d5737f1cc74c639782a4111dc158d8b0307b02|d5d5737]] renamed the ''id revoke pin'' command to ''id relinquish pin'' to conform to contract   * commit [[https://github.com/servalproject/serval-dna/commit/d5d5737f1cc74c639782a4111dc158d8b0307b02|d5d5737]] renamed the ''id revoke pin'' command to ''id relinquish pin'' to conform to contract
  
 **[[#R5]]** -- keyring entry tags (completed 12 November) **[[#R5]]** -- keyring entry tags (completed 12 November)
-  * commit [[https://github.com/servalproject/serval-dna/commit/9680b24f231bb8f8c2dfdfb3c38ef86091318bb6|9680b24]] adds commands to read, write, and search a new key type for storing name/value pairs ("tags"):+  * commit [[https://github.com/servalproject/serval-dna/commit/9680b24f231bb8f8c2dfdfb3c38ef86091318bb6|9680b24]] adds commands to read, write, and search a new key type for storing name/value pairs ("tags"), subject to the limitations described in **[[#N5]]**:
     * the new ''keyring set tag <SID> <tag> <value>'' command sets the value of a given tag on a given identity (which must be unlocked by the supplied PIN options)     * the new ''keyring set tag <SID> <tag> <value>'' command sets the value of a given tag on a given identity (which must be unlocked by the supplied PIN options)
     * the ''keyring set did'' command and the new ''keyring set tag'' command both list all DIDs and tags of the affected identity (after applying the modification)     * the ''keyring set did'' command and the new ''keyring set tag'' command both list all DIDs and tags of the affected identity (after applying the modification)
content/activity/naf5.1385956773.txt.gz · Last modified: 01/12/2013 19:59 by Andrew Bettison