Developing into multiple projects and technologies using `dev` qube

[radek-otee]

Commitment

I confirm that I have read the following resources:

• How to troubleshoot Qusal
• How to ask questions The Smart Way
• Writing the perfect question
• Question checklist
• Could you please make my preference the default?

Question

Hi @ben-grande! A quick question on the management and interaction with the dev qube. (relates to [#68])

Since the qusal.ConnectTCP policy allows for managing access with the outside world, what is the intended/recommended procedure for adding libraries and packages required for various projects securely? I have followed the cited ideas and created a rust.install state (using this one as an example), now I would like to add things through cargo. Same question applies to pip- or poetry-based packages for python etc.

Wondering what your thoughts are.

.

[ben-grande]

Hi @ben-grande! A quick question on the management and interaction with the dev qube. (relates to [#68])

Hello, good that you have read previous issues.

Since the qusal.ConnectTCP policy allows for managing access with the outside world, what is the intended/recommended procedure for adding libraries and packages required for various projects securely? I have followed the cited ideas and created a rust.install state (using this one as an example),

Missing link?

now I would like to add things through cargo. Same question applies to pip- or poetry-based packages for python etc.

The only integration by default for dev with qusal.ConnectTCP is SSH because it allows to connect to a proxy through a command and because Git integrates well with SSH.

I don't think pip and cargo have such proxy command option, although both of them have HTTP Proxy settings. Just brainstorming, but untested as I don't have a formula that uses pip or cargo on a qube without a netvm:

1. From the netvm; install and configure an HTTP proxy;
2. From the client, bind the HTTP proxy port of the netvm locally using qubes.ConnectTCP;
3. From the client, set proxy settings for your desired tool via configuration file (~/.cargo/config or ~/.config/pip/pip.conf) and test the proxy configuration by pulling sources;
4. From the netvm, restrict domains the proxy clients can access with the proxy configuration allowlists.

Qubes uses Tinyproxy for the qubes.UpdatesProxy, it possibly can be replicated for the above setup but note that tinyproxy may be stopped on some qubes as they are not needed in all netvms as per Qusal setup.

Note this is harder to restrict than Git+SSH so less secure. It may be better than direct network access and Qubes Firewall as it only works with IPs and not DNS records (in case the proxy supports DNS based filtering). If you are not able to configure your HTTP proxy setup, I recommend using a qube with a netvm, it is better to be able to have a working solution than nothing at all.

If you complete this, a write up or formula would be nice if contributed.

[radek-otee]

Missing link?

I will PR this to you, but it's a spinoff from install-python-tools.sls with debian packages for rust documentation, a compiler and a package manager - nothing special really.

The only integration by default for dev with qusal.ConnectTCP is SSH because it allows to connect to a proxy through a command and because Git integrates well with SSH.

I don't think pip and cargo have such proxy command option, although both of them have HTTP Proxy settings. Just brainstorming, but untested as I don't have a formula that uses pip or cargo on a qube without a netvm:

I believe (this at least was historically true) pip operates through port 3128, but not entirely sure it's still true - will investigate. That said the dev qube does require a lot more flexibility if the template is to support multiple projects and technologies. I was thinking to create a sort of an "code execution powerhouse", but then it would render the dev qube a glorified typing qube (why not develop directly in the code-exec qube in this scenario), which is not at all intended. On the other hand, you probably didn't want to pollute the dev template with all technologies just in case someone may need it.

1. From the netvm; install and configure an HTTP proxy;
2. From the client, bind the HTTP proxy port of the netvm locally using qubes.ConnectTCP;
3. From the client, set proxy settings for your desired tool via configuration file (~/.cargo/config or ~/.config/pip/pip.conf) and test the proxy configuration by pulling sources;

cargo proxy <- your suggestions are making more and more sense :)

Any tips / templates on the config file? A quick google search reveals the following for pip: https://stackoverflow.com/questions/14277088/what-url-should-i-authorize-to-use-pip-behind-a-firewall

4. From the netvm, restrict domains the proxy clients can access with the proxy configuration allowlists.

Qubes uses Tinyproxy for the qubes.UpdatesProxy, it possibly can be replicated for the above setup but note that tinyproxy may be stopped on some qubes as they are not needed in all netvms as per Qusal setup.

Note this is harder to restrict than Git+SSH so less secure. It may be better than direct network access and Qubes Firewall as it only works with IPs and not DNS records (in case the proxy supports DNS based filtering). If you are not able to configure your HTTP proxy setup, I recommend using a qube with a netvm, it is better to be able to have a working solution than nothing at all.

If you complete this, a write up or formula would be nice if contributed.

Happy to try it, see where it gets us :)

[radek-otee]

One more question: in your dev README, you state:

The installation will make the Qusal TCP Proxy available in the updatevm (after it is restarted in case it is template based). If you want to have the proxy available on a netvm that is not deployed by Qusal, install the Qusal TCP proxy on the templates of your netvm:

sudo qubesctl --skip-dom0 --targets=TEMPLATE state.apply sys-net.install-proxy

From there we would actually configure the proxy to be usable with dev for the cargo and pip contexts. Where would be a good place to configure the proxy? I am new to Qubes and any pointers appreciated.

In a more general sense, how do you go about it? Presumably you also must have hit that wall when coding for multiple contexts?

[ben-grande]

Missing link?

I will PR this to you, but it's a spinoff from install-python-tools.sls with debian packages for rust documentation, a compiler and a package manager - nothing special really.

Please read the contribution guidelines before anything.

The only integration by default for dev with qusal.ConnectTCP is SSH because it allows to connect to a proxy through a command and because Git integrates well with SSH. I don't think pip and cargo have such proxy command option, although both of them have HTTP Proxy settings. Just brainstorming, but untested as I don't have a formula that uses pip or cargo on a qube without a netvm:

I believe (this at least was historically true) pip operates through port 3128, but not entirely sure it's still true - will investigate. That said the dev qube does require a lot more flexibility if the template is to support multiple projects and technologies. I was thinking to create a sort of an "code execution powerhouse", but then it would render the dev qube a glorified typing qube (why not develop directly in the code-exec qube in this scenario), which is not at all intended. On the other hand, you probably didn't want to pollute the dev template with all technologies just in case someone may need it.

I don't plan to make the dev qube formula to fit all developers, that would not be possible even considering that developers using the same programming language can use multiple tools that may not intersect.

The dev qube covers the basics:

• Git over Qrexec to a qube
• Git over SSH using Qrexec to a remote host
• Git configuration
• Dotfiles (shell, X11, tmux etc)
• Searching utilities (ripgrep, fzf)
• Documentation (man-db, info)
• Lint (pre-commit, reuse, pylint, shellcheck)
• Editing (vim)

The one thing I would actually consider trimming from dev is the lint part, it is too specific to my use of qusal and the utilities I use in the project. A separate state I shall organize.

So, adding new things even to the python installation has to be considered if it serves the needs of many and also doesn't put burden on the project. Installation from cargo and pip has been a no-go as the default installation method unless in special circumstances where external projects indicate to use those tools.

1. From the netvm; install and configure an HTTP proxy;
2. From the client, bind the HTTP proxy port of the netvm locally using qubes.ConnectTCP;
3. From the client, set proxy settings for your desired tool via configuration file (~/.cargo/config or ~/.config/pip/pip.conf) and test the proxy configuration by pulling sources;

cargo proxy <- your suggestions are making more and more sense :)

Any tips / templates on the config file? A quick google search reveals the following for pip: https://stackoverflow.com/questions/14277088/what-url-should-i-authorize-to-use-pip-behind-a-firewall

No tips, haven't done it.

[ben-grande]

One more question: in your dev README, you state:

The installation will make the Qusal TCP Proxy available in the updatevm (after it is restarted in case it is template based). If you want to have the proxy available on a netvm that is not deployed by Qusal, install the Qusal TCP proxy on the templates of your netvm:

sudo qubesctl --skip-dom0 --targets=TEMPLATE state.apply sys-net.install-proxy

From there we would actually configure the proxy to be usable with dev for the cargo and pip contexts. Where would be a good place to configure the proxy? I am new to Qubes and any pointers appreciated.

In a more general sense, how do you go about it? Presumably you also must have hit that wall when coding for multiple contexts?

Let's first separate the current qusal.ConnectTCP to the proxy that will be used in this issue. They are different things. The RPC qusal.ConnectTCP is not enough to solve this issue and the proxy that will be configured from this issue needs to be in a separate state, not in sys-net.install-proxy.

A place to configure the proxy is in a networked qube, it doesn't need to be a netvm. If you are new to Qubes, read the upstream documentation about Qrexec.

[radek-otee]

Please read the contribution guidelines before anything.

will do

I don't plan to make the dev qube formula to fit all developers, that would not be possible even considering that developers using the same programming language can use multiple tools that may not intersect.

Agreed, I guess my point is for the dev qube to become an extensible enough to be usable beyond basic bash and python in terms of programming, with as little loss of security as possible, since it is one of you design principles in this project.

So, adding new things even to the python installation has to be considered if it serves the needs of many and also doesn't put burden on the project. Installation from cargo and pip has been a no-go as the default installation method unless in special circumstances where external projects indicate to use those tools.

A potential counter-example for that would be that python without pip is (by analogy) pretty much as paralysed as removing apt from debian :) - I am thinking it's not the tool itself that the qube may potentially need, it's the possibility (and instruction) of setting it up if needed, with good sec practices that I am thinking about.

Always interesting to talk UX stuff :)