Opened 16 years ago
Last modified 9 years ago
#126 closed defect
Allow application code to decide whether or not to accept a gift — at Version 2
| Reported by: | ivank | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | 0.9.0 |
| Component: | introduction | Version: | 0.3.0 |
| Keywords: | gift gifting security | Cc: | dawuud |
Description (last modified by )
"[In the future] there might even be an option to turn off introductions altogether." (using-foolscap.html)
It would be nice if incoming/pending gifts could pass through a Tub-level (?) application-defined function that decides whether or not to accept the gift. This would allow the application to do interesting things, including restrictions by gifter, destination address, or general throttling.
Change History (2)
comment:1 Changed 16 years ago by
| Component: | unknown → introduction |
|---|
comment:2 Changed 9 years ago by
| Cc: | dawuud added |
|---|---|
| Description: | modified (diff) |
| Milestone: | undecided → 0.9.0 |
Note: See
TracTickets for help on using
tickets.
Bumping this one: while describing Foolscap's "gift" mechanism to daira and dawuud (in the context of adding Tor support), both were rather surprised that a Tub could be caused to connect to arbitrary IP addresses. They understood that this was a necessary property of a system that could transparently handle references to arbitrary objects (living on arbitrary remote Tubs), but felt that Tahoe doesn't have a need for this feature right now (cross-server share transfer might be the most likely use case, but even that doesn't involve passing a Gift into a *client*), so they'd feel more comfortable if clients could just turn this feature off altogether.