From dfa81ad1a0f008160f145e8465d90b5323512cc6 Mon Sep 17 00:00:00 2001 From: Deniz Mert Edincik Date: Wed, 13 Sep 2023 13:10:31 +0200 Subject: [PATCH 1/7] FLIP 196: Restrict Capabilities Publish --- .../20230913-restrict-capabilities-publish.md | 46 +++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 cadence/20230913-restrict-capabilities-publish.md diff --git a/cadence/20230913-restrict-capabilities-publish.md b/cadence/20230913-restrict-capabilities-publish.md new file mode 100644 index 00000000..3854570e --- /dev/null +++ b/cadence/20230913-restrict-capabilities-publish.md @@ -0,0 +1,46 @@ +--- +status: draft +flip: 196 +authors: Deniz Mert Edincik (deniz@edincik.com) +updated: 2023-09-13 +--- + +# FLIP 196: Restrict capabilities.publish to account's own capabilities + +## Objective + +With current controller capabilities, it is possible to re-publish someone else's public capability; as this shift in behavior can cause problems, this FLIP strives to address this issue with minimal disruption. + +## Motivation + +Before the introduction of new capabilities API, public capabilities were guaranteed to point to storage at the same address. However, with the introduction of this API, it is now possible to obtain another account's public capability and republish it as one's own, while still maintaining the link to the other account's storage. + +A lot of scenarios such as voting and gating using the proof of Non-Fungible Token (NFT) ownership, usually involve checking if an account owns a certain balance or resource by verifying the public path capability. Now, the responsibility of protection falls on the developers, which is an extra burden and holds the potential of introducing errors. + +The current suggested method of defence against this issue is always checking for the `address` of the capability or the `owner` of the resource after borrowing. Unfortunately, this is an error-prone approach that developers can easily forget. + +## User Benefit + +This proposal aims to add certain restrictions in order to decrease developer burden. + +## Design Proposal + +I suggest adding a restriction to the capability API, permitting only capabilities from the same account address to be published via `capabilities.publish`. + +### Drawbacks + +There may be existing capabilities that use the new API to access other accounts' storage, however I don't believe this will be a significant issue, given its relative newness. + +### Performance Implications + +I don't think there will be any performance implications. + +### Engineering Impact + +There is already a Draft PR implementation by Bastian (https://github.com/onflow/cadence/pull/2782) + +### Compatibility + +As this is an additional restriction, it is backwards compatible with the API. + + From fac9cb10fa0644afe7d4c4eb72976cf4b47767bc Mon Sep 17 00:00:00 2001 From: Deniz Mert Edincik Date: Wed, 13 Sep 2023 19:24:00 +0200 Subject: [PATCH 2/7] Update cadence/20230913-restrict-capabilities-publish.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Bastian Müller --- cadence/20230913-restrict-capabilities-publish.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/cadence/20230913-restrict-capabilities-publish.md b/cadence/20230913-restrict-capabilities-publish.md index 3854570e..71795367 100644 --- a/cadence/20230913-restrict-capabilities-publish.md +++ b/cadence/20230913-restrict-capabilities-publish.md @@ -9,7 +9,11 @@ updated: 2023-09-13 ## Objective -With current controller capabilities, it is possible to re-publish someone else's public capability; as this shift in behavior can cause problems, this FLIP strives to address this issue with minimal disruption. +With the new controller-based capability API, introduced in [FLIP 798](https://github.com/onflow/flips/blob/main/cadence/20220203-capability-controllers.md), it is possible to re-publish someone else's capability (with `Account.capabilities.publish`). + +This was not possible in the previous/currently available linking-based capability API, the function `AuthAccount.link` does not allow targeting another account. + +As this shift in behavior can cause problems, this FLIP strives to address this issue with minimal disruption. ## Motivation From 23af9480a508675a7f09481f0d6b748aa63e0146 Mon Sep 17 00:00:00 2001 From: Deniz Mert Edincik Date: Wed, 13 Sep 2023 19:24:13 +0200 Subject: [PATCH 3/7] Update cadence/20230913-restrict-capabilities-publish.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Bastian Müller --- cadence/20230913-restrict-capabilities-publish.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cadence/20230913-restrict-capabilities-publish.md b/cadence/20230913-restrict-capabilities-publish.md index 71795367..daff4244 100644 --- a/cadence/20230913-restrict-capabilities-publish.md +++ b/cadence/20230913-restrict-capabilities-publish.md @@ -17,7 +17,7 @@ As this shift in behavior can cause problems, this FLIP strives to address this ## Motivation -Before the introduction of new capabilities API, public capabilities were guaranteed to point to storage at the same address. However, with the introduction of this API, it is now possible to obtain another account's public capability and republish it as one's own, while still maintaining the link to the other account's storage. +Before the introduction of the new controller-based capabilities API, public capabilities were guaranteed to point to storage at the same address. However, with the introduction of the API, it is now possible to obtain another account's public capability and republish it as one's own, while still maintaining the link to the other account's storage. A lot of scenarios such as voting and gating using the proof of Non-Fungible Token (NFT) ownership, usually involve checking if an account owns a certain balance or resource by verifying the public path capability. Now, the responsibility of protection falls on the developers, which is an extra burden and holds the potential of introducing errors. From 71d880af4c48b27d557d0f9a82eb3d4f66b38e51 Mon Sep 17 00:00:00 2001 From: Deniz Mert Edincik Date: Wed, 13 Sep 2023 19:24:20 +0200 Subject: [PATCH 4/7] Update cadence/20230913-restrict-capabilities-publish.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Bastian Müller --- cadence/20230913-restrict-capabilities-publish.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cadence/20230913-restrict-capabilities-publish.md b/cadence/20230913-restrict-capabilities-publish.md index daff4244..5ad5029f 100644 --- a/cadence/20230913-restrict-capabilities-publish.md +++ b/cadence/20230913-restrict-capabilities-publish.md @@ -19,7 +19,7 @@ As this shift in behavior can cause problems, this FLIP strives to address this Before the introduction of the new controller-based capabilities API, public capabilities were guaranteed to point to storage at the same address. However, with the introduction of the API, it is now possible to obtain another account's public capability and republish it as one's own, while still maintaining the link to the other account's storage. -A lot of scenarios such as voting and gating using the proof of Non-Fungible Token (NFT) ownership, usually involve checking if an account owns a certain balance or resource by verifying the public path capability. Now, the responsibility of protection falls on the developers, which is an extra burden and holds the potential of introducing errors. +A lot of scenarios, such as voting and gating using the proof of Non-Fungible Token (NFT) ownership, usually involve checking if an account owns a certain balance or resource by verifying the public path capability. Now, the responsibility of protection falls on the developers, which is an extra burden and holds the potential of introducing bugs and security issues. The current suggested method of defence against this issue is always checking for the `address` of the capability or the `owner` of the resource after borrowing. Unfortunately, this is an error-prone approach that developers can easily forget. From cb5593b37aabe3f8aabcf829078aa321f52d025f Mon Sep 17 00:00:00 2001 From: Deniz Mert Edincik Date: Wed, 13 Sep 2023 19:24:27 +0200 Subject: [PATCH 5/7] Update cadence/20230913-restrict-capabilities-publish.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Bastian Müller --- cadence/20230913-restrict-capabilities-publish.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/cadence/20230913-restrict-capabilities-publish.md b/cadence/20230913-restrict-capabilities-publish.md index 5ad5029f..8ed25a97 100644 --- a/cadence/20230913-restrict-capabilities-publish.md +++ b/cadence/20230913-restrict-capabilities-publish.md @@ -21,7 +21,10 @@ Before the introduction of the new controller-based capabilities API, public cap A lot of scenarios, such as voting and gating using the proof of Non-Fungible Token (NFT) ownership, usually involve checking if an account owns a certain balance or resource by verifying the public path capability. Now, the responsibility of protection falls on the developers, which is an extra burden and holds the potential of introducing bugs and security issues. -The current suggested method of defence against this issue is always checking for the `address` of the capability or the `owner` of the resource after borrowing. Unfortunately, this is an error-prone approach that developers can easily forget. +The current suggested method of defence against this issue is always checking for the `address` of the capability or the `owner` of the resource after borrowing. +Unfortunately, this is an error-prone approach that developers can easily forget. +In addition, the new `capabilities.borrow` convenience function gets the capability and borrows it in one call. +Developers will likely forget to still `get` and check the address of the capability, when needed. ## User Benefit From 02a1d1de812c0e77afcafcf9f65d8a82ea26a00f Mon Sep 17 00:00:00 2001 From: Deniz Mert Edincik Date: Wed, 13 Sep 2023 19:24:33 +0200 Subject: [PATCH 6/7] Update cadence/20230913-restrict-capabilities-publish.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Bastian Müller --- cadence/20230913-restrict-capabilities-publish.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/cadence/20230913-restrict-capabilities-publish.md b/cadence/20230913-restrict-capabilities-publish.md index 8ed25a97..24740c63 100644 --- a/cadence/20230913-restrict-capabilities-publish.md +++ b/cadence/20230913-restrict-capabilities-publish.md @@ -28,7 +28,8 @@ Developers will likely forget to still `get` and check the address of the capabi ## User Benefit -This proposal aims to add certain restrictions in order to decrease developer burden. +This proposal aims to add a restriction, in order to decrease developer burden and decrease the risk of bugs and security issues. +The restriction already exists in the currently available linking-based capability API, so this proposal simply proposes to keep the existing restriction, and prevent a regression in the API in terms of safety and usability. ## Design Proposal From 580e15a3bd04556661537987a9c1475f366a32f6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bastian=20M=C3=BCller?= Date: Tue, 24 Oct 2023 11:58:48 -0700 Subject: [PATCH 7/7] Update cadence/20230913-restrict-capabilities-publish.md --- cadence/20230913-restrict-capabilities-publish.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/cadence/20230913-restrict-capabilities-publish.md b/cadence/20230913-restrict-capabilities-publish.md index 24740c63..748b5769 100644 --- a/cadence/20230913-restrict-capabilities-publish.md +++ b/cadence/20230913-restrict-capabilities-publish.md @@ -1,8 +1,9 @@ --- -status: draft +status: accepted flip: 196 authors: Deniz Mert Edincik (deniz@edincik.com) -updated: 2023-09-13 +sponsors: Bastian Mueller (bastian@dapperlabs.com) +updated: 2023-10-24 --- # FLIP 196: Restrict capabilities.publish to account's own capabilities