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

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

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.

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.

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.

This allows removal of std::convert::{TryFrom, TryInfo} since they are included in the std::prelude.

Notice that they will receive the following error if not using =>1.56:

> cargo +1.55.0-x86_64-unknown-linux-gnu b
error: failed to parse manifest at `/home/wcampbell/projects/wcampbell/code/teleport/Cargo.toml`

Caused by:
  feature `edition2021` is required

  The package requires the Cargo feature called `edition2021`, but that feature is not stabilized in this version of Cargo (1.55.0 (32da73ab1 2021-08-23)).

  Consider trying a newer version of Cargo (this may require the nightly release).
  See https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#edition-2021 for more information about the status of this feature.

But the future is here!

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 ;)

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.

Set the maximum chunk size to be 4GB for delta chunks and file transfers. Realistically it will not get this large unless there is a crazy huge file transfer going on anyway.

Check that the length values are within the bounds of the fields we are sending in.

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

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?