Giter Club home page Giter Club logo

ilp-plugin-xrp-asym-server's Introduction

Interledger.js Monorepo

status codecov

Packages

Payments

Name Version Description
@interledger/pay NPM Package Send payments over Interledger using STREAM
@interledger/stream-receiver NPM Package Simple & composable stateless STREAM receiver

Utilities

Name Version Description
ilp-logger NPM Package Debug logging utility for Interledger modules
ilp-packet NPM Package Serialization/deserialization utility for ILP packets
ilp-plugin NPM Package Connect to a local, open BTP server
ilp-plugin-btp NPM Package One plugin to rule them all
ilp-protocol-ccp NPM Package Serialization/deserialization for the CCP routing protocol
ilp-protocol-ildcp NPM Package Fetch asset and account details from a parent
ilp-protocol-stream NPM Package Reliably send streams of money and data over ILP
oer-utils NPM Package Tools for OER parsing and serialization

Installation

The monorepo is set up to use lerna and pnpm workspaces. To get started run the following:

  1. pnpm install - pnpm will install the dependencies and do the necessary linking (no need to run lerna bootstrap).
  2. pnpm build
  3. pnpm test - This will run the tests in all the packages.

Running script commands

Script commands such as test and lint can be run from the root of the project by running:

# Run tests for all packages
pnpm test

# Run tests for a specific module a package
pnpm test --scope=<package-name>

Or in the package directory:

pnpm test

If you are interested in contributing, please read the contributing guidelines.

For Maintainers

Versioning

Independent versioning is used for this project and releases can only be made from master. You will need to set the GH_TOKEN env variable to your personal GitHub access token. Please make sure that you are up to date with master and that the tests and linting pass. Then use the following to create a release:

# On master
GH_TOKEN=<github-token> lerna version --conventional-commits --create-release github

and follow the command prompts. This will commit the package version changes and create the necessary tags - all of which will be pushed to master. It will also create changelogs and official GitHub releases.

If you want to release an alpha then run

# On master
GH_TOKEN=<github-token> lerna version --conventional-commits --conventional-prerelease --create-release github

This will append -alpha.<alpha-version> to the release name. The alpha release can be graduated (1.0.1-alpha.1 => 1.0.1) by running:

# On master
GH_TOKEN=<github-token> lerna version --conventional-commits --conventional-graduate --create-release github

Adding new packages

All source code is expected to be TypeScript and is placed in the src folder. Tests are put in the test folder. The NPM package will not contain any TypeScript files (*.ts) but will have typings and source maps. A typical project should have the following structure:

|-- src
|-- test
|-- package.json
|-- tsconfig.build.json

The tsconfig.build.json file should have the following

{
  "extends": "../../tsconfig.json",
  "compilerOptions": {
    "composite": true,
    "baseUrl": ".",
    "rootDir": "src",
    "outDir": "dist",
    "tsBuildInfoFile": "./dist/tsconfig.build.tsbuildinfo"
  },
  "include": [
    "src"
  ]
}

The package.json file should specify the following

{
  "name": "<package-name>",
  "license": "Apache-2.0",
  "publishConfig": {
    "access": "public"
  }
}

In the scripts section of the package.json, be sure to have build, cover (which runs tests with coverage) and codecov. These will be called from the CI pipeline. Please use the following as a guideline:

"scripts": {
  "build": "tsc -p tsconfig.build.json",
  "cover": "...",
  "codecov": "curl -s https://codecov.io/bash | bash -s - -s coverage -F <flagname>"
}

The cover script should run the tests with code coverage and output the coverage results in a format that can be uploaded to codecov. The flagname will be used by codecov to track coverage per package. Please make sure it matches the regex ^[a-z0-9_]{1,45}$.

Importing legacy modules

This process preserves the commit history of the legacy modules.

git clone [email protected]:adrianhopebailie/interledgerjs.git
git clone [email protected]:interledgerjs/legacy-module.git
cd legacy-module
git pull
cd ../interledgerjs
lerna import ../legacy-module --dest=packages --preserve-commit --flatten

You then need to replace the tsconfig.json file with the tsconfig.build.json and update the package.json as described above.

Dependencies

We keep devDependencies that are shared across all packages in the root package.json file. Dependencies can be added to individual packages using Lerna

lerna add <package to install> --scope=<package-name>

# Add dev dependency
lerna add <package to install> --scope=<package-name> --dev

Running script commands

Script commands such as test and lint can be run from the root of the project by running

# All tests in all packages
lerna run test

#Scoping to a package
lerna run test --scope=<package-name>

ilp-plugin-xrp-asym-server's People

Contributors

0xask avatar adrianhopebailie avatar emschwartz avatar karzak avatar kincaidoneil avatar michielbdejong avatar njlie avatar sentientwaffle avatar traviscrist avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ilp-plugin-xrp-asym-server's Issues

Server pays the bill if accounts get compromised

Related to ilp-plugin-btp/issues/4.

Quote from the mini-accounts readme (emphasis mine):

Any secret can be used to authenticate; it is then hashed and becomes your account identifier. This has the advantage of requiring no UI-based signup flow nor any database storing usernames and passwords. It has the disadvantage that password recovery cannot be done, and only randomly generated passwords should be used. Treat your credentials like you would treat a wallet secret for a cryptocurrency.

Comparing it to a wallet secret is not quite right. If a wallet is compromised, the owner of the wallet is out of funds. With mini-accounts, however, if a client's password is compromised the mini-accounts instance is out of funds.

Why? Let's assume an attacker gets a client's password. To steal money, he would authorize to mini-accounts with the stolen password and send a payment up to the bandwidth limit. Since he cannot send a valid claim, further payments are rejected and he cannot steal more (which should not be much, but free money yay). If any legitimate (sane) client realizes that the account is compromised the only option is to close the paychan/account (sending another claim is not an option since the attacker still has the password and it cannot be changed). mini-accounts never got that last claim, so it is out the bandwidth.

So it is really in the best interest of mini-accounts that client passwords are not compromised.

Implement plugin.sendMoney

It seems that https://github.com/interledgerjs/ilp-plugin-xrp-asym-server/blob/master/index.js#L498 is used instead of https://github.com/interledgerjs/ilp-plugin-xrp-asym-server/blob/master/index.js#L520-L524?

Obviously, since this plugin exposes only one LPI, but in reality represents possibly many connected peers, it's not possible to know who to send money to when plugin.sendMoney is called. The same problem exists for plugin.sendData, which this plugin inherits from ilp-plugin-mini-accounts, but there it's solved with deep packet inspection. That same trick cannot be used here.

Maybe we should just stop pursuing the concept of exposing only one LPI? Otherwise, maybe we should change the LPI to support server plugins?

document paychan-related BTP protocols

This plugin, together with https://github.com/interledgerjs/ilp-plugin-xrp-asym-client and https://github.com/ripple/ilp-plugin-xrp-paychan, define the paychan-related protocols from interledger/rfcs#381. I think the RFCs repo should describe only the ilp protocol, because the info, channel, fund_channel, channel_signature, claim, last_claim, ripple_channel_id etc. protocols are specific to XRP, and they would be different if you use Ethereum-based payment channels.

User Authentication

Follow up to this issue I created on the old repo.

It looks like you took out BTP authentication completely. Now it seems to be enough that a BTP client proves that he opened a paychan to the server, right?

deal with undefined outgoing balance

sending money to account 1000 test.amundsen.bmp.btp18q1.6wRdeNJzEHNIsDAMAdKbdVLWIqu8b6-Bs-xVNZqplQw.XmWKc9DrpBs.J8ZZyfb8T3b6U6RrF-HCrQyg 2803620212
getting outgoing balnce from store 6wRdeNJzEHNIsDAMAdKbdVLWIqu8b6-Bs-xVNZqplQw:outgoing_balance undefined
2018-02-08T16:56:12.141Z ilp-plugin-xrp-server debug failed to pay account.
            destination=test.amundsen.bmp.btp18q1.6wRdeNJzEHNIsDAMAdKbdVLWIqu8b6-Bs-xVNZqplQw.XmWKc9DrpBs.J8ZZyfb8T3b6U6RrF-HCrQyg
            error=BigNumber Error: new BigNumber() not a number: undefined
    at raise (/home/michiel/amundsen/node_modules/ilp-plugin-xrp-asym-server/node_modules/bignumber.js/bignumber.js:1191:25)
    at /home/michiel/amundsen/node_modules/ilp-plugin-xrp-asym-server/node_modules/bignumber.js/bignumber.js:1179:33
    at new BigNumber (/home/michiel/amundsen/node_modules/ilp-plugin-xrp-asym-server/node_modules/bignumber.js/bignumber.js:194:67)
    at Account.getOutgoingBalance (/home/michiel/amundsen/node_modules/ilp-plugin-xrp-asym-server/src/account.js:117:12)
    at Plugin._sendMoneyToAccount (/home/michiel/amundsen/node_modules/ilp-plugin-xrp-asym-server/index.js:531:36)
    at util._requestId.then (/home/michiel/amundsen/node_modules/ilp-plugin-xrp-asym-server/index.js:509:34)
    at <anonymous>

npm install problems

npm ERR! code 128
npm ERR! Command failed: /usr/local/bin/git checkout 970346aa88cda564308160744bc4c322f79c52af
npm ERR! fatal: reference is not a tree: 970346aa88cda564308160744bc4c322f79c52af

That commit is on mini-accounts. Not sure why it's erroring.

Allow only one paychan per XRP address

The default bandwidth (even for a new paychan/account) is 2000 drops. An attacker can easily steal from the connector by opening many paychans to the connector, which cost 10 drops a piece, make the connector forward 2000 drops on each paychan and never send a claim.

One mitigation to this problem would be if the connector allows only one paychan per XRP address. An attacker could steal 1990 drops, but not more.

Unlink closing channel from account

_channelClose() is executed once the server detects that an incoming channel is closing. Should this function also unlink the channel from the account iff the unsecured funds were successfully claimed? Otherwise, the account cannot open a new paychan at a later point.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.