Skip to main content

Security

Due to its nature, XPipe has to handle a lot of sensitive information. This can range from passwords for all kinds of servers, to SSH keys, and more. Therefore, the security model of XPipe plays a very important role.

This document summarizes the approach of XPipe when it comes to the security of your sensitive information. If any of your questions are left unanswered by this document, feel free to file an issue report so your question can be answered individually and can also potentially be included in this document.

Reporting a security vulnerability​

If you believe that you found a security vulnerability in XPipe, you can make use of the private security report feature of GitHub.

Security assumptions​

The general assumption is that the system on which XPipe runs on is not badly infected. This refers to your local system on which you installed XPipe, not any remote systems that you then connect to. If your local system is infected to an extent where malicious programs can modify the file system and other installed programs like XPipe, then there is no technical way of preventing malicious programs to also infect XPipe and the connected systems as well.

Reliance on other programs​

XPipe essentially delegates any form of connection and shell handling to your existing command-line tools. It does not come with any remote handling capabilities of its own. Therefore, any used command-line program should be secure. If, for example, your ssh command-line program or its connections are susceptible to MITM attacks or vulnerable in any other way, there is no way for XPipe to guarantee that the sensitive information can be kept secure. It is your responsibility to use the programs in a secure environment and keep them up to date with security patches and more. XPipe can only be as secure as your underlying command-line tools itself.

XPipe calls these programs almost exactly as you would do manually in your terminal with some a few additional parameters to automatically pass login information and adapt the environment to make it work properly. The called program therefore automatically uses your system configuration for it, e.g. your system SSH configs.

Data security and privacy​

The general approach of XPipe can be summarized as follows:

  • Any sensitive information is kept as secure as possible exclusively on your local machine, both while XPipe is running and also not running
  • When sensitive information is required on another remote system that is connected through XPipe, that information remains there as briefly and securely as possible
  • No sensitive information is sent to any other server outside your network of trusted connections

Storage of sensitive information​

All XPipe connection data is exclusively stored on your local machine at ~/.xpipe/storage. You can choose to change this storage location in the settings menu.

You have the option to fetch any sensitive information like passwords from outside sources like password managers or enter them at connection time through a prompt window. In that case, XPipe doesn't have to store any secrets itself.

In case you choose to store passwords and other secrets within XPipe, all sensitive information is encrypted when it is saved to disk on your local machine using AES with either:

  • A custom master passphrase that can be set by you in the settings menu (This option is only as secure as the password you choose)
  • A dynamically generated key file at ~/.xpipe/storage/vaultkey (The data can then only be decrypted with that file present)

By default, general connection data is not encrypted, only secrets are. So things like hostnames and usernames are stored without encryption, which is in line with many other tools. There is an available setting to encrypt all connection data if you want to do that.

Sharing of information across machines / with team members​

XPipe allows you to synchronize your connections with a remote git repository. This repository can be set up by yourself with any provider of your choice using any authentication scheme you like. XPipe supports all authentication schemes, both HTTP and SSH with advanced options like password prompts, key files, smart cards, and more.

Any information is then regularly committed to that repository. This repository can then be cloned on other systems or by other collaborators to have access to the same connections.

Passing of sensitive information​

When any kind of login information is required by a command-line program, it has to be passed to it somehow. If the program runs on your local system, the data does not leave your local system. If login information is required on a remote system, then that data must be transferred to that remote system.

In case a program accepts password input via stdin, this process is relatively straightforward. Then the passed sensitive information is just written into the stdin of the program and does not show up in any history or file system.

When a program only accepts password input via an environment variable or an askpass program, a self-deleting password supplier script file is generated by XPipe. This script contains the encrypted password and will supply the password to the target program exactly once when invoked and immediately deletes itself afterward. This behavior ensures that there is no leftover password script after an operation is performed. As a secondary measure, for cases in which the calling program crashes and is not able to execute the script and therefore doesn't delete the password script, the generated script directory is also frequently cleaned. As a result, no sensitive information of yours should show up in any kind of shell history or on any file system.

The purpose of shell scripts​

Whenever you open a remote connection in a terminal from XPipe, your terminal sometimes shows the name of a script located in your temp directory in the title bar to indicate that you're currently executing it. The naming scheme of these scripts is usually something like exec-<id>.(bat|sh|ps1). This is intended as these scripts contain all commands that are required to realize the functionality of connecting and initializing the shell environment. These scripts do not contain any sensitive information, you are free to inspect them yourselves in the temporary directory.

In some cases, e.g., when you want to run shell environment init commands on a remote system, XPipe also has to create shell scripts on the remote system. If you don't want XPipe to modify the remote file system under any circumstances, there is a setting to completely disable this behavior.

Logging​

By default, XPipe creates log files located in ~/.xpipe/logs. These log files do not contain any sensitive information. If you choose to launch XPipe in debug mode, log information is printed to the console instead and will contain a lot more and finer grained information, some of which might be sensitive.

Issue reports​

Whenever an error occurs within XPipe or you choose to open the error reporter dialog, you have the option to automatically send an error report with optional feedback and attachments. This error report does not contain any personal information unless you explicitly choose to attach log files.