Base image drinternet/rsync as first party code

[Burnett01]

This action has been around and maintained for many years with 3.500+ projects depending on it.
As per demand, it is time to streamline/merge the base image code into this action code base.

In the next major version, the base image dependency (drinternet/rsync) will be included as a first party code into this project. This allows for easier code review and Q/A conducted by action users.
This also means that the action will have zero dependencies (other than alpine itself of course).
Both licenses are compatible (MIT) which should ease the migration/merge path.

Since the maintainer of the base image has always been a collaborator of this action,
nothing will change except that regular alpine version updates are done here as well.

[Burnett01]

I was able to retain the original commits for the files of the base image (drinternet/rsync)
via git filter-repo and I pushed it to a tracking branch in this repo here: drinternet-rsync-merge.

Log:

Stevens-MacBook-Pro: $ git clone https://github.com/JoshPiper/rsync-docker.git
remote: Enumerating objects: 295, done.
remote: Counting objects: 100% (109/109), done.
remote: Compressing objects: 100% (68/68), done.
remote: Total 295 (delta 59), reused 79 (delta 39), pack-reused 186

Stevens-MacBook-Pro: $ git filter-repo --path agent-add --path agent-askpass --path agent-autostart 
--path agent-start --path agent-stop --path hosts-add --path hosts-clear 
--path README.md --path LICENSE --path Dockerfile

Parsed 105 commits
New history written in 0.20 seconds; now repacking/cleaning...
Repacking your repo and cleaning out old unneeded objects

The histories of that branch and the history of this repo are unrelated,
leading to either a merge or rebase.

I am leaning towards a rebase in order to retain the commits of the base image files.
A merge would lead to a loss of the commits of those files.

A rebase will most likely take part against the upcoming non-release/8.0.0 version (which is currently in sync with master/main).

Please let me know if you are fine with a rebase of the base image files against the upcoming 8.0.0 release.

I will keep you updated how the progress is going. So far I will have to rebase each commit concerning the README.md and Dockerfile manually.

[Burnett01]

Currently no new progress on this topic due to time constraints, but I am on it

[Burnett01]

Sooooo, good news. Instead of trying to integrate the unrelated history from rsync-docker, I decided to copy the relevant files (agent-start, hosts-clear, .....) while cleaning/improving them a little bit.
To comply with the MIT of rsync/docker, I added the author to MIT of this repo.
Since he is already a maintainer (and friend), this is fine.

With that being said, version 8.0.0 will bring the following features:

• feat: integrate rsync-docker 3rd party into this action as 1st party code (no more dependency, better audit, single source of truth)
  • backported:
    • agent-start
    • agent-stop
    • agent-askpass
    • agent-add
    • hosts-add
    • hosts-clear
  • new added:
    • ssh-init
    • hosts-init
  • improved:
    • stricter permissions on .ssh/ folder (700) and known_hosts (600)
    • use set -euo pipefail in all scipts
• feat: new "strict_host_keys" option to enable support for strict host key verification. Default: false (to keep backward compatibility)
• feat: new "strict_host_keys_fingerprint" option to enable support for comparing the reported fingerprint against the expected one (todo)
• feat: new "debug" option to see the commands executed (-x) by this action
• feat: this action is now scanned for vulnerabilities by Snyk
• feat; this action is now scanned by CodeQL for Q/A
• feat: this action now performs CI tasks such as Validation, Linting and Unit Tests
• fix: various shell syntax for robustness
• fix: use printf and redirect output to non-stdout instead of echo in sensitive code locations
• refactor: use $HOME instead of tilde ~ for robustness

I am not sure yet if the strict-host-keys option should be "false" by default. I did so it is backward compatible to the old
versions which never had this. But since its 2025 and security is non-negotiable, I am leaning towards a breaking change,
eg. making 8.0.0 not compatible with older versions.
Same applies to the "legacy_allow_rsa_hostkeys" option, which was introduced in version 7.0.0 via a community contribution, in order to allow the action to connect to older SSH hosts which are still using rsa hostkeys.
Strictly speaking, its 2025 and everybody should be using the latest security featues on their SSH hosts.

What do you guys think? Should 8.x be a breaking change whilst 7.x is still being supported alongside it?