mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.1.6 2023-06-07T18:37:04Z 2023-06-07T18:37:04Z Nick Mathewson nickm@torproject.org 2023-06-07T18:36:46Z urn:sha1:999f914e030e77d9439f0cb6910af10def33d518 2023-06-05T18:45:42Z Nick Mathewson nickm@torproject.org 2023-05-25T18:39:56Z urn:sha1:d6944bf0038543065b6112aa1620471ce0db3f10 2023-05-24T14:53:29Z Nick Mathewson nickm@torproject.org 2023-05-24T14:53:29Z urn:sha1:3d4b9aa1b731f85279291ea5c1057bb6a348a729 rpc: authentication and basic handle manipulation See merge request tpo/core/arti!1200 2023-05-24T14:15:56Z Nick Mathewson nickm@torproject.org 2023-05-23T14:41:56Z urn:sha1:9713e8d3054aafe3f19afd55693bc3159712e595 I've made doing some design choices here: * Reserving "rpc" as a prefix for post-authentication functionality that is not arti-specific. * Declaring these to be methods on the session rather than methods on the objects themselves. There's a problem with defining an API to drop a weak reference; see comment in code. 2023-05-23T17:58:08Z Nick Mathewson nickm@torproject.org 2023-05-23T17:55:23Z urn:sha1:45b4845f3ab792a4293f2d6a6adaf856d27bb3f1 Now that generation-arena has merged [@diziet's patch] to clarify their license, we no longer need to disable it. [@diziet's patch]: https://github.com/fitzgen/generational-arena/pull/56 2023-05-16T13:08:25Z Nick Mathewson nickm@torproject.org 2023-05-15T19:55:28Z urn:sha1:1ed2da523a97845ab379bd8712dc2b8786e73aa3 This lets us simplify our logic a bit for strong references. 2023-05-15T19:59:58Z Nick Mathewson nickm@torproject.org 2023-05-15T19:21:49Z urn:sha1:2e1115acc317fbe4b2ad549dfd03c2c2dd83dd59 We want each ID to have a unique form every time it is given out, so that you can't use ID==ID to check whether Object==Object. (See discussions leading to #848.) We'd also like the form of object IDs to be a little annoying to analyze, to discourage people from writing programs that depends on their particular format. (We are reserving the right to change the format whenever we want.) We _don't_ want to use any cryptography here (yet), lest somebody think that this is an actual security mechanism. (This isn't for security; it's for encouraging developers to treat IDs as opaque.) With that in mind, we now lightly obfuscate our generational indices before returning them. 2023-05-15T19:26:58Z Nick Mathewson nickm@torproject.org 2023-05-15T18:14:03Z urn:sha1:8531ed2dad6c151c64bde5dc2ac165b0d33d28e3 These are about to become nondeterministic-ish and probably shouldn't use the Into/TryFrom traits. 2023-05-15T19:26:53Z Nick Mathewson nickm@torproject.org 2023-05-15T18:07:12Z urn:sha1:0d207028ceb2bdc9c39cab21e8f3e8d119353e79 Per discussion referenced at #848, we want each operation that returns a strong object ID to return a new, distinct strong ID. Note that we no longer need to put strong and weak references in the same arena; we can clean this code up a lot down the road. 2023-05-15T17:48:47Z Nick Mathewson nickm@torproject.org 2023-05-15T17:48:47Z urn:sha1:c9819455e10563355d589e16f73384b3d68ff299 Now we generate object IDs that we can parse. This is about to be obsolete once we change how we generate objects and their IDs for #848, but we may as well start from a working state.