TODO.txt 5.4 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115
  1. # Format: - <task ID>, <task points>, <created by user>, <created on commit>, <finished by user>, <finished on commit>
  2. !- 0, 3, mdcarr941@gmail.com, 2ebb8a
  3. Fix bug where writing to a block that already has a Writecap in its header using the creds of
  4. a different node produces an invalid signature (a signature using the creds of the other node).
  5. !- 1
  6. Fix BufSectored so it doesn't have to write to the first sector every flush.
  7. - 2
  8. Track position and dirty-ness in Trailered.
  9. - 4
  10. Remove TryCompose?
  11. !- 5, 1, mdcarr941@gmail.com, bd6904, mdcarr941@gmail.com, bd6904
  12. Move crypto::{encrypt, decrypt} into corresponding {EncrypterExt, DecrypterExt}.
  13. !- 7, 2, mdcarr941@gmail.com, ?, mdcarr941@gmail.com, fd4356
  14. Add a ser_sign_into method to SignerExt which serializes a value into a provided Vec<u8> and returns
  15. a signature over this data. Update BlockStream::flush_integ to use this method.
  16. !- 8
  17. Convert all sector sizes to u32 for portability.
  18. (I ended up using u64 but keeping usize as the return type for Sectored::sector_sz)
  19. - 9
  20. Create an extension trait for u64 with a method for adding an i64 to it. Use this in
  21. SecretStream::seek, Trailered::seek and SectoredBuf::seek.
  22. !- 10, 5, mdcarr941@gmail.com, ?, mdcarr941@gmail.com, fd4356
  23. Create a struct which digests data written to it before passing it to an underlying Write.
  24. !- 11, 3, mdcarr941@gmail.com, bd6904, mdcarr941@gmail.com, bd6904
  25. Create a struct called WritecapBody to contain the fields of Writecap which go into the signature
  26. calculation so that WritecapSigInput is no longer required.
  27. !- 12, 8, mdcarr941@gmail.com, 2ebb8a,
  28. Create a struct for managing the directory used to store blocks in the file system. Design and
  29. implement an API for creating, opening, moving, copying, deleting and linking blocks. This API must
  30. be codified by a trait to allow the implementation to be changed in the future.
  31. !- 13, 5, mdcarr941@gmail.com, ?, mdcarr941@gmail.com, fd4356
  32. Change the Hash enum so it contains structs for each hash type. Unify these structs with the node
  33. structs used in the VecMerkleTree.
  34. !- 14, 13, mdcarr941@gmail.com, bd6904
  35. Refactor btlib so that most of the types are in their own modules. This is
  36. needed to encourage modularity and weak coupling, as it reduces the amount of code that fields
  37. and helper functions are visible to.
  38. !- 15, 13, mdcarr941@gmail.com, 58d1f6,
  39. Create a new crate which implements a FUSE daemon.
  40. !- 16, 5, mdcarr941@gmail.com, 866533,
  41. Add the inherit field, which contains the crypto link from the parent block key to the current
  42. block key, to the block metadata.
  43. - 17, 13, mdcarr941@gmail.com, 8665339,
  44. SECURITY: Design and implement a mechanism to protect the keys in block's metadata dictionary from
  45. being correlated with one another. This mechanism must allow a principal with a readcap to be able
  46. to find their readcap and to rotate the block and create new readcaps for each of the principals in
  47. the dictionary, but prevent an attacker from being able to identify when two blocks contain
  48. readcaps for the same principal.
  49. !- 18, 3, mdcarr941@gmail.com, 8665339, ???
  50. SECURITY: Remove the path field from BlockMeta. It isn't needed as the block path should be
  51. independently know by any verified. This will ensure that path names are not stored in cleartext.
  52. - 19, 21, mdcarr941@gmail.com, 8665339,
  53. Integrate with tokio and add async methods to all of the stream types.
  54. - 20, 5, mdcarr941@gmail.com, ef1d43,
  55. Rewrite BlockPath to be more efficient by ensuring that all characters in a path are contiguous
  56. in memory.
  57. !- 22, 8, mdcarr941@gmail.com, fe2ffc, mdcarr941@gmail.com, fe2ffc
  58. Add a new fields to BlockMeta which stores data encrypted using the block key. This information must
  59. include:
  60. * mode bits as u32
  61. * Unix timestamps
  62. * owner UID and GID
  63. * size of block data in bytes as u64
  64. * number of hardlinks to the block
  65. Also include a dictionary for user data, which is indexed using a String and whose values are
  66. Vec<u8> structs.
  67. - 23, 5, mdcarr941@gmail.com, 7f33fa,
  68. Manually implement the Serialize trait for BlockMetaBody so that the secrets field can be lazily
  69. updated upon serialization if the secrets_struct field has been modified. In order to detect
  70. modifications, a new field with the serde(skip) attribute needs to be added to BlockMetaBody to
  71. store the hash of BlockMetaSecrets that was computed just after decryption.
  72. - 24, 3, mdcarr941@gmail.com, 7dbb358,
  73. Move `BlockRecord.frags` into `BlockMetaSecrets`.
  74. - 25, 2, mdcarr941@gmail.com, 02d8cb,
  75. Implement `Blocktree::batch_forget`.
  76. - 26, 13, mdcarr941@gmail.com, 44a6ef,
  77. Implement a timeout mechanism in LocalFs which will purge handles and locks that have not been
  78. accessed for a configured period of time.
  79. - 27, 8, mdcarr941@gmail.com, 1c59d92
  80. SECURITY: Reusing the IV for every sector in a block is a security risk. This is equivalent to using
  81. ECB mode with a cipher whose block size equals the sector size, meaning that patterns in the cipher
  82. text will be clearly visible. Design a method to avoid reusing the same IV for every sector.
  83. (Maybe use the sector index as the IV? That's kind of like CTR mode. Ah, I could hash the IV with
  84. the sector index, then use that as the IV for the sector.)
  85. - 27, 3, mdcarr941@gmail.com, 1c59d92
  86. SECURITY: Inode numbers a currently being exposed as the name of the file a block is stored in. This
  87. should be avoided by hashing the inodes along with a salt. Because this salt needs to be accessible
  88. even before we've decrypted any data in the filesystem, we need to use data from the credentials.
  89. (Perhaps the path in the writecap?)