These questions are broad but all related to coding tips. Why ask on Whonix? Because it is related to the whonix environment.
Privacy friendly code editor, not
Can I get a tip about code editors? Need to have capability to change between files easily. Terminal editor are for one file at a time, unless some infamous vim plugin exists and is easy to use, I don’t have a good code editor. This is important because having a good code editor really helps to speed up development process.
Does Qubes-Whonix people always copy their github ssh credentials from the vault every time they want to git push? Trying to hold the passwords away from a hot/connected to the internet host.
Development helper packages nice to have? Devscripts etc? Do you have a predefined list to install on newer setups on the templates? I understand it is possible to fingerprint someone if they have specific select packages, so no need to share everything.
Is it more safe for me to sync scripts from the workstation (where I develop) to the gateway (where some scripts needs to be run) via pushing to github and pulling on the gateway or via copying the diffs via qvm-copy? I have read FileTransfer wiki page.
Most importantly, don’t do anything other than code editor and git in a development VM. Browsing has probably the highest risk. Therefore best if avoided in a development VM. Some code is also safe to test in a development VM since it purely runs locally.
Even the build script https://github.com/Whonix/Whonix would be good if it was in the usual Debian package format. It needs to be renamed anyhow to clarify that the same build script can also be used to build Kicksecure.
I used to use https://github.com/Whonix/whonix-developer-meta-files/blob/master/debug-steps/qubes-repo-temp - a script to copy the local Whonix APT repository created in the workstation to the gateway and then locally apt dist-upgrade from that repository. But building a package, adding it to the local APT repository, copying it over and dist-upgrade from it also even if fully scripted takes a while. Non-ideal during development. Would that help?
Based on qvm-copy, qrexec seems best. In essence, a development workstation getting permission to change files in a (development) gateway. Either just copying over an upgraded source folder and then running a script to install the newer files on the gateway (probably better) or replacing files in the destination in /usr/bin etc. on the gateway directly (probably non-ideal).
Did you look into Qubes split-gpg and split-ssh?
Me neither. I cannot really recommend my code editor. It has some bugs that I got used to over the years.
Most importantly, don’t do anything other than code editor and git in a development VM. Browsing has probably the highest risk. Therefore best if avoided in a development VM. Some code is also safe to test in a development VM since it purely runs locally.
Do you have a design for that? Qubes resources says VM depends on use case, of course, but sharing the setup might help.
For example, I have to run code on the gateway, and it is just easier to debug on the gateway and run there (a local code) than to copy from the WS to GW. But then I don’t wan’t to compromise my GW if I ever have to install more packages than necessary just to test code. Then I have to have 2 WS and 2GW, sometimes 1 disposable for the WS and maybe one for the GW?
I want to understand how to properly separate the development activities, cause I have to watch github on a WS just for browsing and then testing code on a different WS for development and having the rest of internet activities on another WS, while it may be good to have multiple GW and WS. I just want to do it right from the beggining, but I already have started wrongly.
Yes, that seems to help.
That page probably being not terribly helpful.
Almost every file transfer leaks data according to that wiki, therefore I stopped sharing bits.
Thanks, should really start signing my commits after I have the split-gpg split-ssh setup.
I have looked at it but never completed.
Me neither. I cannot really recommend my code editor. It has some bugs that I got used to over the years.
The debian alternatives aren’t really good and I feel like having an AppVM just to hold VSCodium VSCode without telemetry, ms branding etc. They have a deb package (not on debian.org) and an AppImage. But that is kinda too much and something would take ages to compile. Haven’t found a replace for this editor yet.
Until I write-up more… One brief advice: Keep it practical. Don’t let the perfect be the enemy of the good. If too much security results in so much usability regression that it demotivates/hinders/stops all development, then that’s also a fail.
disposable VMs (browsing, research if no bookmarks are kept, relaxed noscript)
whonix-ssh (running ssh client to ssh connect to server)
whonix-development (text editor, source code, package building, low risk debugging of applications with local connections, strictly no web browser)
whonix-gpg - Qubes split-gpg backend with with OpenPGP subkeys only, without OpenPGP master key
vault - OpenPGP master key
whonix-documents - offline, if I need to open a PDF / create a PDF
whonix-mail - mail client (no html!), strictly no web browser
whonix-mail-web - hopefully rarely needed nowadays that mail client POP/SMTP is stable
private-documents - offline, example shopping pdf invoices
bitcoin
monero
i.e. 1 use case (= mostly 1 application) = 1 dedicated App Qube (Template based)
(but if I need to open a text config file in lets say monero App Qube, I don’t get crazy about it and do it in a Disposable, I run the text editor in that VM.)
i wouldn’t run bitcoin / monero in the same App Qube
private-bank
private-mail
private-shopping (often no need to avoid mixing with private-bank)
private-router-web (router web interface)
All of this developed over time. Well, once upon a time there was a time when Qubes didn’t exist yet.
Maybe I can elaborate. Could you please rephrase your equation if still open?
Glad to contribute back so to speak! Many things you invented recently, I don’t think would have happened anytime soon or at all without you inventing them.
Maybe I can elaborate. Could you please rephrase your equation if still open?
Rephrasing:
I was mostly interested on the whonix development VMs separation and you answered more than I asked, I am glad. Most of these things seems I will only learn over time.
Glad to contribute back so to speak! Many things you invented recently, I don’t think would have happened anytime soon or at all without you inventing them.
If you want to use vim in a terminal, there are potentially some features that write to disk you might want to be aware of and disable
Swap file: Stored in $filename.swp or in $HOME in the case of unnamed files. Preserves changes to file(s) being edited in the background. Can persist if vim process if interrupted and possibly under other circumstances
.viminfo: Stored in $HOME and keeps a record of command history, search strings and other activity
I have not done any tests for any other problematic behavior but the below contents in $HOME/.vimrc should mitigate both of the above issues
In addition if you determine this to be an acceptable risk you can install the package vim-gtk3 which enables X11 clipboard copy and paste as part of buffers.
Discovered another vim feature triggered by using the in-built directory-browser that might want to be disabled to minimise on-disk artifacts.
CHANGING TO A PREDECESSOR DIRECTORY netrw-unetrw-updir {{{2
Every time you change to a new directory (new for the current session), netrw
will save the directory in a recently-visited directory history list (unless
|g:netrw_dirhistmax| is zero; by default, it holds ten entries). With the “u”
map, one can change to an earlier directory (predecessor). To do the
opposite, see |netrw-U|.
The “u” map also accepts counts to go back in the history several slots. For
your convenience, qb (see |netrw-qb|) lists the history number which may be
used in that count.
*.netrwhist*
See |g:netrw_dirhistmax| for how to control the quantity of history stack
slots. The file “.netrwhist” holds history when netrw (and vim) is not
active. By default, its stored on the first directory on the user’s
|‘runtimepath’|.
So to disable append let g:netrw_dirhistmax=0 to $HOME/.vimrc
I don’t want to break your flow, but when I created the first post, it was intended to ease development of Whonix, because someway or another I had to have a less trusted Gateway to be used for testing software.
There is no reason for me hide which files I accessed on a Whonix-Workstation dedicated to development because it only contains git repositories that will be pushed upstream.
Also, even if considering normal activities, I do not consider swap files, vim info, netwr_dirhist to contain any extra information that any malware can’t gather from reading the files, because well, they are all readable by the user user.
IMHO this does not provide extra privacy because it will always have to be readable by the user that is writing to it.
On the other hand, I stopped using VSCode in favor of the old Vi, sometimes Vim, so I don’t need to install any extra big package that could compromise my Whonix VM.
A reasonable conclusion. I am not saying this has to be ‘fixed’ but support empowering the end-user to be aware of potential artifacts that applications may leave behind in relation to potentially non-public data and for them to make the choice to do something about it or not.
Just now seeing this post, wish I had seen it sooner. I highly suggest checking out neovim, and I personally love the astronvim configuration but lazyvim is great. For navigating multiple files, handling splits, etc.
It has sane defaults and it is a way to MOVE around a codebase. No opening a single file. Open a project, use lazygit to manage flows, use lsp’s and mason for autocomplete, use ripgrep and fzf to search for files, etc.
There are some nice youtube tutorials and what not. Neovim “distros” are a game changer. And if you can get around in Vi, it will boost productivity significantly
