SAFE CLI subcommand suggestions: reset and uninstall

General
1

It would be helpful if I could simply run safe uninstall and have all vault data, preferences, and other files written to the filesystem throughout using SAFE removed along with the binaries. (safe-cli, safe-authd, safe-vault)

A useful counterpart to that subcommand would reset state without removing the binaries.

4 Likes
2

Nice suggestions. Iā€™ve added a couple of separate issues for these:

  1. Add uninstall command
  2. Add reset command
3 Likes
3

@StephenC,
/cc @bochaco, @joshuef, @dirvine,

As the reset and uninstall subcommands will modify and potentially delete user data, what expectations would you have of the implementations?

4

hmmmm, good Q.

Iā€™d expect uninstall to warn what it will delete at a prompt (which coudl be overriden by a flag). Perhaps a confirmation therafter depending on how strongly worded/informative we want the warning to be.

As far as I know, weā€™re aiming to have installs of CLI based things/ config and apps to be in ~/.safe dir generally. So it should most likely be just removing thatā€¦

Iā€™m not sure if it would/should attempt to detect other apps (eg browser). Even if it did eventually, iā€™d certainly not expect it in an initial impl.

I wonder if it needs to be a ā€œsecureā€ delete? Overwriting a few times (or that can be an option laterā€¦ iā€™m also not sure how much that increases security)

Thatā€™s off the top of my head.

ā€œResetā€ is likely looking to setup as a clean install and not remove the installed apps just user data?

2 Likes
5

@joshuef

Thank you for your helpful reply.

uninstall will likely build atop reset in some fashion so Iā€™ll begin with reset. Iā€™ll address your important question of detecting other Safe apps, such as the browser, at that time.

Regarding reset and the deletion of local user data, as I donā€™t yet know what all is persisted locally, would it be permanently destructive of more than configuration and preference files? Iā€™m assuming it wouldnā€™t affect user data stored in Safe in any way, and wallets could be reinitialized by simply authenticating with the userā€™s keys.

Optional secure delete is a great idea and I suspect we could leverage OS API for it on some platforms. Iā€™ll get the basic reset functionality in place first and then revisit it.

2 Likes
6

@moderators

Please change the title of this thread to ā€œSAFE CLI subcommand suggestions: reset and uninstallā€.

1 Like
7

safe reset will revert all local file and directory creation made by Safe. To revert, all points of file and directory creation, of any repo of Safe Network Ā· GitLab, must be cataloged.

To build the catalogue, Iā€™ll search the repos for the use of any API known to create files or directories. API known to create files or directories:

  • std::fs::DirBuilder::create
  • std::fs::File::create
  • std::fs::File::with_options
  • std::fs::OpenOptions::create
  • std::fs::OpenOptions::create_new
  • std::fs::OpenOptions::open
  • std::fs::copy
  • std::fs::create_dir
  • std::fs::create_dir_all
  • std::fs::hard_link
  • std::fs::soft_link
  • std::fs::write

If you know of others in use in Safe repos, please reply with a link to a line of code.

Just use diff

I could diff my FS before and after some Safe usage, however itā€™s likely that it wouldnā€™t reveal all, especially lazily-created, files and directories. The better place to run diff checking is on test/CD/CI infrastructure as that should exercise the codebase more than any other, and therefore reveal lazily-created files and directories.

Limitations

The initial scope of this implementation will revert only file and directory creation in Safeā€™s repos. A complete catalogue would require that the entire dependency graph of Safeā€™s crates be searched.

safe reset is prone to becoming stale over time as code using file and directory creation API is added. Iā€™d appreciate anyoneā€™s ideas for maintaining safe resetā€™s consistency with the codebase, preferably without manual developer intervention. My current best idea is for a test/CD/CI diff task comparing diff results with a file and directory creation ā€˜manifestā€™ config file which lists the files and directories safe reset deletes.

1 Like
8

It shouldnt affect data on safe. Locally weā€™re persisting CLI auth, eg. But you can get that again via logging in. So you should be fine there.

cc @lionel.faber @bochaco, not sure if you have any ideas of other file locations beyond tmp and ~/.safe weā€™re using at the mo? I know the drive is for all things in ~/.safe but just to be sureā€¦

2 Likes
9

@joshuef

IMHO hard-coded paths is outdated. Well-formed programs targetting *nix OSs should adhere to https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html with more details and examples at XDG Base Directory - ArchWiki. Not only would that respect common conventions, it would also respect a userā€™s orderly FS layout preferences. In my experience with *BSD and Linux it works very well.

Perhaps I could add that in the future.

10

We used to use XDG and changed it for storing things under ~/.safe/, which other apps also do. This way showed it was way simpler and easier for users to find and know what apps are storing, and itā€™s consistent across platforns. XDG is a bit confusing when it comes to diff platforms, also IIRC data and config of an app go to completelly diff folders paths. This is a personal comment and how I see it for testing though, for sure we should adhere to standards in the future if thatā€™s found better, but again some other apps took this path too like git or cargo i think.

3 Likes
11

@joshuef

Is there an example of any other subcommand that prompts the user similarly to how safe reset will need to prompt the user for confirmation?

1 Like
12

Draft ready WIP: feat(cli): implements 'safe reset' subcommand.

1 Like
13

Sorry @anon78698497, totally missed your prev Q. Will have a look today at the draft!

:bowing_man:

1 Like