Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
  • Sign in / Register
  • Node Launcher Node Launcher
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 12
    • Issues 12
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 6
    • Merge requests 6
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • THORChain
  • DevOps
  • Node LauncherNode Launcher
  • Issues
  • #59
Closed
Open
Created Jan 01, 2022 by Hildisvíni Óttar@hildisviniottar

ADD: Automatic backup (regularly)

Currently NO must manually perform make backup for TSS keyshares, which change every churn. In a disaster scenario, NO's may not be able to reconstruct keyshares due to not enough backups.

In order to capture 2/3+ key share backups every churn (for emergency purposes, and to protect NO from infra fails), suggest making backup automatic for all make status commands.

  1. Remove the 'Are you sure? Confirm [y/n]' prompt for make backup (it's non-destructive ... just do it immediately).
  2. Auto-backup for every make status run.

Security discussion: The user will have a backup/ folder created with key shares and private keys on the machine they are running, possibly without them knowing. This can be mitigated with public awareness notice posted in Discord. The NO's machine (laptop, etc) used to run node-launcher folder with kubectl should already be secure and is already integral part of trusted zone, so storing backup/ folder automatically should be fine. This is a good trade-off to secure TC against existential threats.

Assignee
Assign to
Time tracking