Menu

Report a security issue

If you found a way to attack a Dassie node, its wallet, its peers or its releases, thank you. Please tell us privately first, so that it can be fixed before anyone else learns of it.

On this page
  1. How to report it
  2. What to include
  3. Testing safely
  4. What happens next

How to report it

Report it on GitHub, in private. Only you and the maintainers see the report, and you talk it through with them there.

  1. Sign in to GitHub and open Report a vulnerability on Dassie's repository.
  2. Describe what you found, as below, and submit it.
  3. The maintainers answer you in the report. You see each reply there, and GitHub tells you about it.

No GitHub account? Join Dassie's Discord and, in a public channel, ask a maintainer to message you. Leave every detail of the issue out of that message, and describe it once a maintainer has written to you directly.

What to include

  • the version you found it in (dassie --version), or the commit, if you read the code;
  • the part it is in: the node, the wallet, the desktop app, the dassie command, a settlement hub, a front door, the market maker, the installer and updater, the release mirror, or dassie.land;
  • the steps to reproduce it, or a proof of concept, as small as you can make it;
  • what an attacker gains, and what they need first: a peer, a node of their own, the owner's login, a place on the network path;
  • whether you have seen it used against anyone;
  • how you would like to be credited, if at all.

Testing safely

Try your attack on nodes you run yourself. The local dev network starts several nodes on your machine, with a fake XRP Ledger, in one command. Please don't test against other people's nodes, the testnet's bootstrap nodes and the hubs they keep, or the release mirror: others rely on them.

What happens next

  1. The maintainers read your report and answer you in it. Dassie is a small project, so this can take a few days.
  2. Together you work out how serious it is, and the fix is prepared in private.
  3. The fix ships in a signed release. Nodes installed with the installer look for a new release once a day and switch to it by themselves, unless they were installed with --no-service. On NixOS, the owner takes it by changing the flake input. The desktop app, which does not update itself yet, takes it when its owner builds the new version. Updates and rollback says more.
  4. Once nodes have had time to update, the maintainers can publish your report as an advisory on GitHub, crediting you if you want that.

Please keep the issue to yourself until the fix is out. If you plan to write about it, say so in the report, and agree on a date.

How releases are signed, so that a fix reaches nodes the same way as every release.

A kopje of granite blocks against the sun, in veld grass; one dassie climbs its slab, one keeps lookout on top inside the sun, and one sleeps on the next rock; on a wide screen, a pair sits on a kopje to the left