# 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](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability)
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.

XPipe does not perform any validation or version checking for the programs it calls.
For example, when establishing an ssh connection through XPipe, it will straight up call `ssh user@host <options>`.
It is assumed that this `ssh` executable is secure and the one that you actually want to use.

## Data security and privacy

The general approach of XPipe can be summarized as follows:

- Any sensitive information should be 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
  should be transferred and
  remain there as briefly and securely as possible
- No sensitive information should be sent to any other server outside your network of trusted connections

### Storage of sensitive information

All XPipe 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 either fetch any sensitive information like passwords from outside sources like prompts or password managers. In that case, XPipe doesn't have to store any of that information itself.

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

- A custom master key that can be set by you in the settings menu
  (This option is only as secure as the password you choose)
- A somewhat dynamically generated key (This option can be reverse
  engineered though, there is no way of perfectly securing your data without any custom key)


### 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 temp directory.

In case a script connects to a remote system and passes login information to a program via variables or askpass
programs, it automatically becomes useless after being invoked once (See [above](#passing-of-sensitive-information)).
As the script is run immediately after it is created initially, e.g. when using the `Open in terminal` functionality, it becomes useless pretty much instantly so any attacker doesn't obtain any sensitive information from it.

### 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, these logs are 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 sensitive information, unless you explicitly choose to attach log files.

## Isolation of systems

Any infected remote system should be isolated enough such that any infection can't spread through XPipe.

### User isolation

All relevant files like configuration files and other required temporary files are only accessible by the current user.
Any other user on a system can't read or write them unless they have root/Administrator privileges.

### Isolation of remote systems

When you add a remote system as a host within XPipe, it is implicitly assumed that you trust this system.
Any required login information is sent to and handled on that remote host when required,
so it would be possible for malicious program with sufficient privileges to obtain any information sent to that host.
This would require an attacker to be able to access files of the user that is used to log into the remote system.
It should however not be possible for any malicious program on the remote host to obtain
other information stored by XPipe that is not explicitly sent to that host.

## Antivirus programs

### Windows Defender

It may occasionally happen that Windows Defender warns and
even sometimes deletes XPipe due to it identifying the application as malware.
The reason for this is simple: The application is not signed with an EV code signing
certificate as this would require a company for XPipe to be set up and would also cost around 600$+ per year.
If XPipe was signed with such a certificate, as are most Windows applications distributed by companies, all warnings
would go away automatically.
The Windows Defender / Windows SmartScreen system is essentially pay-to-win here.
Just paying the appropriate amount will automatically whitelist your application (even it is unsafe / essentially
malware)
while not paying will often blacklist it, bullying you into buying it.
You can read more about this system in [this StackExchange post](https://security.stackexchange.com/a/139520).
The manual whitelisting process without an EV certificate is purposely made difficult and essentially useless.
The Windows Defender detection rules are garbage and not deterministic, i.e.
an identical application can be flagged on one system but not the other, even though both are connected to the internet
and the Microsoft services.
In summary, don't rely on Windows Defender to be accurate when it comes to false-positives.

### macOS

On macOS the application bundle is signed and notarized and will therefore not emit any warnings.
For macOS this process does not require a company to be
set up and also only costs 125$ per year and is therefore much easier to accomplish.

### Windows antivirus programs

In some cases, it might occur that your antivirus program flags XPipe as malware.
This is due to the fact that XPipe launches shells and executes various commands in them,
which can be interpreted as malicious activity as some viruses use
the same approach and does lead to some false-positives.

For this reason, all artifacts of every release are automatically uploaded and analyzed on VirusTotal,
so uploading the release you downloaded to VirusTotal should instantly show analysis results.
From there you should be able to get a more accurate overview over the actual threat level of XPipe.

If such a detection also happens on your end, you might have to
explicitly whitelist XPipe in order for it to work correctly.
Having access to shells is necessary for XPipe, there is no fallback alternative built in that does not launch shells.
