docs: rfc-1101 tapplet #137
Conversation
|
|
||
| ### Motivation | ||
|
|
||
| The **Tapplet** is dedicated type of applet for the Tari blockchain and the fundamental part of the Tari Universe described in [RFC-1100](https://github.com/tari-project/rfcs/pull/134). The idea behind registered tapplets is to solve the class of vulnerabilities of the Dapp model known as supply chain attacks. This covers a wide range of attacks like: injecting malware code, XSS, stealing domains, social engineering attacks, etc. |
There was a problem hiding this comment.
Todo - update link after RFC 1100 is merged.
| ### Motivation | ||
|
|
||
| The **Tapplet** is dedicated type of applet for the Tari blockchain and the fundamental part of the Tari Universe described in [RFC-1100](https://github.com/tari-project/rfcs/pull/134). The idea behind registered tapplets is to solve the class of vulnerabilities of the Dapp model known as supply chain attacks. This covers a wide range of attacks like: injecting malware code, XSS, stealing domains, social engineering attacks, etc. | ||
| The solution proposed by Tari uses the tapplets Registry (another RFC will describe it) to register hashes of zip bundles of applications and sign them using the private key associated with Yat. The actual zip bundle can be hosted by https, but thanks to the registry commitment, the client can verify that the bundle hasn’t been tampered with. |
There was a problem hiding this comment.
TODO the tapplets Registry (another RFC will describe it) => [Tapplets Registry](link/to/rfc/)
|
|
||
| ### Tapplets | ||
|
|
||
| At first, it is proposed that tapplets are npm packages published to the public npm registry, but in the future it may be extended also to other package managers. Npm is the first choice because it is widely used, so publishing a new Tapplet is as simple as publishing an npm package. |
There was a problem hiding this comment.
Can we think of an alternative? You points are fair, but npm has such a dismal security record that it might hurt the perceived integrity of the product.
Off the top of my head, I can't think of an alternative, besides IPFS, obviously.
Otherwsie maybe we can add armour to the npm packages, e.g. by utilitsing elements of https://theupdateframework.com ?
There was a problem hiding this comment.
npm has such a dismal security record
Could you please elaborate on what you mean by that?
This is really good point and I'm gonna include this in the RFC, just need more context to compare with (if any) alternatives.
npm is as secure as IPFS at this point, because the idea of the registry based on checking the checksum of each version and only the codeowner of the tapplet can register the new version. Thus each version is stored separately in the registry.
TUF might be the way to go!
src/RFC-1101_Tapplet.md
Outdated
| Tapplets are separate packages and the file structure depends on its authors, however every package should contain a helpful readme file and must contain a manifest json file with Tapplet data. | ||
| The following details are specific to tapplets: | ||
|
|
||
| - The *version* string field in `package.json` and `tapplet.manifest.json` should match. |
There was a problem hiding this comment.
Name of, and
Public key of publisher?
There was a problem hiding this comment.
You mean this should be included in the tapplet manifest? I didn't add it because I guess npm package source could be enough, but definitely it's worth considering! Also I'll add it to RFC.
| } | ||
|
|
||
| ``` | ||
|
|
There was a problem hiding this comment.
Some questions that arise that aren't clear from the current text:
- How do you propose managing upgrades? It's a complex topic on it's own to be sure.
- Where does the manifest live / Are there commitments to it anywhere?
- The manifest is mutable. How do you handle attempts to change the content hash (to point to a malicious app) without changing the version? (If it's meant to be immutable, the status field isn't useful.)
There was a problem hiding this comment.
These are really good points! I'll described them detailed in the RFC document, here just briefly.
- Each version of a tapplet needs to be registered separately. Once registered and listed in Tapplets Registry (ofc with checksum and so on) it is not planned to changed any data and upgrade is done within new PR to the Tapplet Registry. Only codeowner of a specific version can do it.
- Tapplet's manifest,
tapplet.manifest.json, is placed in the tapplet package (I'll add sample tapplet package structure to visualize it) - Before adding a tapplet to the Registry, CI will check if proposed package has correct structure, valid checksum etc. If does - next CI will generate
tappletsRegistry.manifest.jsonfile. So the contect hash can't be updated without checking an app before. Next version can be added with a new PR to the Tapplets Registry repo only by the codeowner.
karczuRF
force-pushed
the
feat/rfc-tapplet
branch
from
4970d0e to
b1b362c
Compare
| ### Motivation | ||
|
|
||
| The **Tapplet** is dedicated type of applet for the Tari blockchain and the fundamental part of the Tari Universe described in [RFC-1100](https://github.com/tari-project/rfcs/pull/134). The idea behind registered tapplets is to solve the class of vulnerabilities of the Dapp model known as supply chain attacks. This covers a wide range of attacks like: injecting malware code, XSS, stealing domains, social engineering attacks, etc. | ||
| The solution proposed by Tari uses the tapplets Registry (another RFC will describe it) to register hashes of zip bundles of applications and sign them using the private key associated with Yat. The actual zip bundle can be hosted by https, but thanks to the registry commitment, the client can verify that the bundle hasn’t been tampered with. |
There was a problem hiding this comment.
Can you explain why a Yat is needed. IMO yats should not be involved
There was a problem hiding this comment.
Thanks for that question. Basically Yat integration was just an idea, because as I know the Tari Aurora app already has Yat support, so it could be used as part of the Tari. But it's ok to skip it and not involve Yat at all.
The aim of this Request for Comment (RFC) is to propose the Tapplet concept. Tapplets are dedicated Tari's applets registered on the L1 to ensure a superior level of security for network users.