> Going further down the rabbit hole, the toltec GitHub page mentions that it works on top of the Entware distribution, and recommends what is basically “wget | bash”. I’m not a fan of this. Could I install my own rsync?
We made sure that the toltec install process includes a hash of the install script to prove that it isn't modified by a man-in-the-middle. Toltec itself requires the use of SSL to connect after the fact, which lowers the risk after it's been installed. We are also exploring the implications of adding package signing[0].
I apologize, I could have better expressed why I took the path I did. I'll edit the post later today.
another option would be to just grab the files from the package itself and extract them to the device, and then manually run the install script steps as required. They are basically just gz tarballs.
A bit late for that, no?
Maybe I misunderstood but the modified version could do it's thing and then download the official script to fool that check.
Or pretty much anything else imaginable.
But that is better!
This is not true.
https://www.digitalocean.com/community/tutorials/how-to-copy...
Edit: Looks like I was wrong.
The document you link is using ssh as a transport protocol as opposed to the rsync protocol. The rsync binary must be installed on both systems for this to work.
When you run something like:
rsync file user@rhost:/dest/path
The local rsync binary invokes ssh, and then executes the rsync binary on the remote system and from there the two instances of rsync effectuate the transfer.
If you do not have rsync available in your path on the remote system you will not be able to copy files over ssh. This is documented in the manpage.
Try it.
[0] https://www.chromium.org/chromium-os/chromiumos-design-docs/...
usually there are three. system a and system b which are updated and flipped and some sort of emergency recovery that either has a factory image or a very light rom that phones home for a new image.
https://www.redhat.com/en/topics/devops/what-is-blue-green-d...
They could have used rsync without installing rsync on the device. The target device doesn't need to have rsync for rsync to be used.
They could have installed the package manager and left it. It doesn't run anything in the background on my device. It's easy enough to verify you don't have a systemd service or timer running it. (cron isn't installed, iirc)
They could have compiled rsync with all of the libraries bundled with it. (Maybe this is beyond their expertise?)
Their solution is using Docker to use the package manager and then overwriting system files on the device in the worse possible way, without understanding what they are doing. At that point, they verified in Docker. Should be safe to run it on the tablet then, yes?
What attack vector are they worried about? :/ Toltec is actively worked on, odds are someone would notice someone else fucking with repository.
The cherry on top was completely not understanding how the remarkable works. There are two partitions for a reason. The inactive one is used for software updates. When the reMarkable downloads an update, it downloads it to the inactive partition. When you "install" the update, it flips which of the two partitions is active. If the update fails to boot, it flips back to the known good state. All they had to do was switch the active partition, the next update would overwrite the broken partition. https://github.com/ddvk/remarkable2-recovery/issues/6
This looks like a bad case of tunnel vision, combined with a lack of understanding. I'm glad they managed to figure out how to fix it.