meejah and I devchatted: * Talked about Tahoe-LAFS release process. How can we make more progress on it? Jean-Paul has PyPI access now. How are releases signed?
- * With "Tahoe-LAFS Release-Signing Key (https://tahoe-lafs.org)" apparently (BDE0D31D68666A7A) - * How does Brian feel about someone else doing a release and signing it? - * Does it make sense for Brian to share this key with someone else so they can sign a release? - * Talked about new HTTP protocol (spec under development <https://github.com/LeastAuthority/tahoe-lafs/blob/4ad5b5ab461752317429d81a7575f4a33ff6c1f6/docs/proposed/http-storage-node-protocol.rst> ) - * What do we do with storage fURLs? - * Perhaps keep them as-is but apply a different interpretation to them in the client. - * Keep security properties the same as Foolscap by keeping the implementation as close as possible - * Parse location hints and tubID from the fURL, connect to location, check public key, if it matches tubID, connection is okay - - * How does new system get exposed? - * Add a new key to storage server announcements. - * Old clients will ignore it - * New clients will notice it and use new protocol - * New announcement information will include storage server public key. - * New clients will check public key of server they reach and verify it is the expected value (like the tubID check in foolscap) - - * Do we need to handle mutable and immutable differently at the level of buckets? * Don't bother with subjectAltName etc * Non-goal: Making clients easier to implement by removing the need to check certificate fingerprint * Goal: Making servers easier to implement by removing the need to implement Foolscap * Talked about the future of introducers - * There isn't necessarily much of one - * See the grid manager proposal -
_______________________________________________ tahoe-dev mailing list [email protected] https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
