[kayodelycaon]

Oh boy do I have opinions with this one. This seems like a lot of work to avoid using a perfectly good package manager on the device.

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.

[Eeems]

I know I reacted hard to this statement:

> 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].

0. https://github.com/toltec-dev/build/issues/14

[greenhathacker]

I made the mistake in that post of not mentioning that I didn't want to be required to connect the rm2 to wifi, and installing a package manager would mean I would need to do that to install software. If anything it would be something I would temporarily install, use it to install rsync, then figure out how to uninstall it, and in my mind that's functionally equivalent to what I was doing with docker. Pushing to / instead of /opt was my mistake :)

I apologize, I could have better expressed why I took the path I did. I'll edit the post later today.

[Eeems]

That makes a lot more sense. you can always just install initially and then use opkg to install local packages you scp across in the future as well: `opkg install path/to/package.ipk`

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.

[Eeems]

For anybody wanting more context on the ipk format: https://github.com/toltec-dev/toltec/blob/stable/docs/opkg.m...

[kayodelycaon]

Ah! Now that approach makes a lot more sense. Any particular reason to avoid putting it on a WiFi network for a few minutes?

[tjoff]

> 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.

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.

[Eeems]

I guess you haven't looked at our install instructions[0]. The hash check is done before running the script. You can't run the script if it doesn't match unless you choose to just run it manually and ignore the check.

0. https://toltec-dev.org/

[tjoff]

I have not. Just responding to the information that was available in this thread.

But that is better!

[kayodelycaon]

The bash script is fairly easy to download and verify before running it. It’s only 200 lines with a few functions and if statements.

[tjoff]

Yes, but the whole antipattern of wget | bash is that you don't encourage that sort of scrutiny.

[throwaway09223]

"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."

This is not true.

[kayodelycaon]

It very much is true. I do it all the time. If the target device is running ssh, you can use rsync on the source.

https://www.digitalocean.com/community/tutorials/how-to-copy...

Edit: Looks like I was wrong.

[throwaway09223]

No, it is not true. You're misunderstanding how this works.

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.

[_hyn3]

Exactly. You absolutely must have the rsync binary installed locally. The rsync "server" should only actually be run if you know you need it (that is, only if you are providing rsync services to other people).

[tnhh]

As others have pointed out, that doesn't quite work. But the way that I use rsync with my remarkable is to use sshfs to mount the remarkable's filesystem, and then run rsync between the local and mounted filesystems. Works for me without having to install rsync on the remarkable.

[danachow]

Unfortunately you will not get any speed boost in that case, in fact it will be slower having to fetch all the remote side data for small file changes.

[tnhh]

Fair enough. It does work for my simple use case: rsync student coursework to the remarkable, mark coursework on the remarkable, rsync back. There aren't many small file changes and USB is fast enough. The real bottleneck is the marking but I'm not sure if I want a package manager to help me with that!

[xdfgh1112]

Doesn't that run rsync --server on the server via ssh?

[throwaway09223]

yup.

[_e]

Does remarkable use a fork of ChromiumOS? ChromiumOS uses the BOOT-A and BOOT-B partitions for upgrades and it reverts to the previously used boot partition if the OS fails to successfully boot[0].

[0] https://www.chromium.org/chromium-os/chromiumos-design-docs/...

[Evidlo]

No, it uses Yocto/OpenEmbedded.

[_e]

Thank you for the fast response and, also, for putting this onto my radar. For anyone else who is curious, Yocto/OpenEmbedded is used to create custom linux distributions for embedded devices:

https://www.yoctoproject.org/members/openembedded/

https://www.yoctoproject.org/software-overview/

[a-dub]

using two partitions in this way on embedded devices has been a trope for a very long time. service/warranty calls are expensive!

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.

[TechBro8615]

It sounds like Blue/Green deployments.

[_e]

For the curious... An overview of the Blue/Green deployment model:

https://www.redhat.com/en/topics/devops/what-is-blue-green-d...

[a-dub]

sorta. but i think that blue/green deployments are typically monitored by some central control that will halt and reverse a whole fleet deployment, where typically embedded devices run that state machine locally. (after flashing the unused partition, if it fails to boot, fail back to the old one and disable the update).