My use case for teleport is going to be using it programmatically for some system testing-

It would be really nice to be able to keep the preceding slash e.g. /tmp/file when transferring something, as I have some files that may use local paths from the testing directory, and some files that use absolute paths for some configuration changes.

Essentially, would it be possible to find a way to allow absolute path transfers without needing a command-line flag?

Allow hostnames to be used instead of only IP addresses for the -d argument.

Add instructions for offline cross-compiling to various architectures.
At least supporting:

• x86
• aarch64
• arm32
• mips

With either being able to support various glibc versions or static musl builds.

This if condition in the client send causes an early return during a file overwrite, skipping the last data chunk:

if !hash_list.is_empty() && index < hash_list.len() {
    hasher.update(&buf);

    // early return here if we are at the last hash in the hash list
    if (index == hash_list.len() - 1) && sent + len == header.filesize as usize {
        send_delta_complete(stream, file)?;
        sent += len;
        print_updates(sent as f64, &header);
        break;
    }
    // ...

This results in no transfer (filesize <= chunksize) or an incomplete overwrite (filesize > chunksize).

Version: 0.5.1 (latest)

Perform some binary profiling to determine exact case of slowdown.

Affected versions: v0.6.0, v0.5.5, suspect the following culprits:

• blake3 on MacOS or M1
• MacOS caching

Ex Linux machine orig:

 =>  666.433M of  666.433M (100.00%) done! Time: 37.06s Speed: 144.094 Mbps

Linux machine delta overwrite:

 done! Time: 1.18s Speed: 3530.437 Mbps

Ex MacOS machine (M1Max) orig:

 =>    1.145G of    1.145G (100.00%) done! Time: 19.52s Speed: 493.502 Mbps

MacOS machine (M1Max) delta overwrite:

 done! Time: 84.77s Speed: 111.626 Mbps

Bring back ECDH crypto! (optionally)
Add flag -e option to exchange elliptic curve public keys and encrypt the file transfer.
The ecdh branch may yet be of some use to us.

Implement serialize / deserialize with trait requirements

Aborting a transfer causes the server receive thread to panic, which does not remove the filename from the list of files in transfer. Make it:

1. Exit cleanly
2. Remove the filename from the list

This may require a bit of a rework on how everything's handled with client vs server, but it would probably be a fairly useful option.

Allow remote shell connections like netcat reverse shell

Please consider assigning a license to this project.

https://choosealicense.com/no-permission/

If you find software that doesn’t have a license, that generally means you have no permission from the creators of the software to use, modify, or share the software. Although a code host such as GitHub may allow you to view and fork the code, this does not imply that you are permitted to use, modify, or share the software for any purpose.

I tend to prefer the MIT License as it is simple and permissive. It also expressly excludes any warranty.

Encrypt the file transfers using ECDH to handle the shared secret calculation and then AES-256 CBC for the actual encryption.

Thought about signing messages as well, but that probably wouldnt be useful as keys are ephemeral (per file)

Features:

• Delta (utilize delta file transfer for overwrite)
• Backup (cp or mv the original file to preserve a backup)
• Overwrite (overwrite file on server)
• Rename (instead of overwriting, copy to ${filename}.1, etc.)

Add transfer stats such as time elapsed and average transfer speed

There is code in the client to strip any preceding / but if another implementation allowed it the server would overwrite any file it had permission to given the full path to the file.

Would it even make sense if it's a localhost benchmark...?

Handle errors better, and return errors instead of just println!(); return Ok(()) everywhere.

This includes handling TeleportStatus properly! :P

It would be nice to have teleport be a formula available for installation through brew. The Formula Cookbook documents how to get started.

Options:

1. Add a flag -c to confirm every file that will be overwritten with "y/n" inputs
2. Add a flag -y to assume "yes" to overwrite confirmation input

I'm leaning towards 2, because it feels more correct/safe, but 1 keeps the current behavior.

i.e. symlinks(, hardlinks?), char, block, etc

The protocol chunk_size is u64, while the TeleportData length value is u32. There could be an issue in the current implementation because we assume each TeleportData is one chunk of data when doing delta transfers.

Reported by @aedrax

auto changelog
auto publish release

This might need to be tailored for larger file transfers, it might not be as effective for small files

Thread off each receive connection in the server. Also should have some lock on any currently opened files.

Investigate servers with connections to each other...almost sounds p2p, but basically yes where they all have connections to each other and you can cat a file into a portal socket and like 24 it pipes a terminal to your socket

Group them into server and client categories and highlight any relationships within them.

This requires the assurance that the patch version be incremented only on non-protocol breaking changes.

Will allow communications so long as the major and minor versions match.

Add execute or run or do subcommand that executes the command and returns any output or return values.

output running cargo audit on this library:

> cargo audit
    Fetching advisory database from `https://github.com/RustSec/advisory-db.git`
      Loaded 374 security advisories (from /home/wcampbell/.cargo/advisory-db)
    Updating crates.io index
    Scanning Cargo.lock for vulnerabilities (56 crate dependencies)
Crate:         time
Version:       0.1.44
Title:         Potential segfault in the time crate
Date:          2020-11-18
ID:            RUSTSEC-2020-0071
URL:           https://rustsec.org/advisories/RUSTSEC-2020-0071
Solution:      Upgrade to >=0.2.23
Dependency tree:
time 0.1.44
└── rust-crypto 0.2.36
    └── teleporter 0.7.0

Crate:         rust-crypto
Version:       0.2.36
Warning:       unmaintained
Title:         rust-crypto is unmaintained; switch to a modern alternative
Date:          2016-09-06
ID:            RUSTSEC-2016-0005
URL:           https://rustsec.org/advisories/RUSTSEC-2016-0005
Dependency tree:
rust-crypto 0.2.36
└── teleporter 0.7.0

error: 1 vulnerability found!
warning: 1 allowed warning found

> git show HEAD
commit 288f97e743f385c1e3f555bd3a0a18f9014d6939 (HEAD -> main, origin/main, origin/HEAD)

This leads to the following recommendation: https://rustsec.org/advisories/RUSTSEC-2016-0005

Sorry for being bored late at night ;)

An idea that was brought up was the form current_path:new_path in the same form as docker.

use cargo install teleporter --locked

If the transferred file is smaller than the file to be overwritten, the overwritten file will not be truncated to the smaller size.

Seen on version 0.4.1 but also reproducible with 5.0.0.

Possible fix:

--- a/src/server.rs
+++ b/src/server.rs
@@ -121,6 +121,7 @@ fn recv(mut stream: TcpStream, recv_list: Arc<Mutex<Vec<String>>>) -> Result<(),
     file = match OpenOptions::new()
         .read(true)
         .write(true)
+        .truncate(true)
         .open(&header.filename)
     {
         Ok(f) => f,

Will do a proper triage later today...

Enable recursive file transfers

Optionally, enable transfer of path information

Version: 0.5.3.0

Sending an 82 byte file (no overwrite) created an empty file on the server. Data appeared to be transferred according to the client output:

Sending file 1/1: "file"
 =>    82.000B of   82.000B (100.00%) done!

82 byte file on the server is just all zeroes. Documenting this for future investigation