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.
Nice suggestions. Iāve added a couple of separate issues for these:
@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?
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?
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.
Please change the title of this thread to āSAFE CLI subcommand suggestions: reset and uninstallā.
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 https://gitlab.com/safenetwork, 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::createstd::fs::File::createstd::fs::File::with_optionsstd::fs::OpenOptions::createstd::fs::OpenOptions::create_newstd::fs::OpenOptions::openstd::fs::copystd::fs::create_dirstd::fs::create_dir_allstd::fs::hard_linkstd::fs::soft_linkstd::fs::writeIf you know of others in use in Safe repos, please reply with a link to a line of code.
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.
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.
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ā¦
IMHO hard-coded paths is outdated. Well-formed programs targetting *nix OSs should adhere to XDG Base Directory Specification 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.
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.
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?
