How does IX handle upstream bugfxes ?
1 Like
No Debian branch has rsync higher than 3.3.0. Unlikely that you’ll see it in SCALE Fangtooth (25.04), or even the SCALE 25.10 release. (Perhaps?)
I suppose it depends if the security patches can be backported to Rsync version 3.3.0.
EDIT: This might not apply to the official iX “App” for Rsync, which is not bound to the host system libraries and packages. Since Rsync 3.4.0 was just released yesterday, it’s within reason that the “Rsync App” for SCALE can pull it in with a simple update to the App itself.
You’re right in that you can’t trust the Debian versions … As they make heavily use of backports.
I’d certainly expect Debian to do that
But does IX have to do something, in order for my local TN Scale box, to pick up an updated (read Debian backported) rsync package ?
I’d expect that , since it seems that my repos (sources) points at Ie:
deb https://apt.sys.truenas.net/dragonfish/nightlies/debian/ bookworm main
Is this in the context of the “daemon” (rsync “server”) or the client side? From what I could tell, the security concern mainly implicates the rsync daemon that runs on a server. (Disabled on SCALE.)
Not sure the exact policy of iX, but I’d wager they just pull from upstream (like a Debian derivative would), and only patch a package if feasible and urgent enough.
Because they offer Rsync as an “App” (citing security concerns, no less), my guess is that you would install the Rsync App from the official iX catalog, and you will likely see it updated to 3.4.0 sooner than waiting for “Debian XYZ” to finally ship with 3.4.0.
Well for now i have decided on NAS server backups to “Pull from my server Backup sources”, that are running a rsync daemon w. multiple modules defined.
But i might enable rsync daemon on the NAS later on.
Edit: Well might not … (Security)
Wuutt !!!
So they want me to install an APP , instead of using a builtin system tool 
Why would i want to install a “Container or whatever APP” to do something that is built in ?
I know it’s an appliance …
But a teeny bit of freedom would be appreciated.
I somehow still think it’s “my system” not IX’es 
Edit:
I can see the security dangers is an open rsync daemon on the main box …
Access to “everything” as root … Jusk ask rsync to deliver it.
Well I still hope it would be my decision, not IX’es.
To run the Rsync Daemon (i.e, “service”)? Yes.
Same boat as you. But at the end of the day, the maintenance, stability, and security of the product comes first.
For this same reason, I disagree with their decision to remove Auxiliary Parameters and the ability to put the syslogs on a System Dataset that does not live on the boot-pool (which can inherit encryption to encrypt your logs, and leave them off of the boot-pool).
I’ll repeat myself until my cheeks turn blue: All these decisions are fine as defaults, and they can even “hide” them in the GUI. I’d be fine if you have to go out of your way to enable the “dangerous” advanced options, that allow Auxiliary Parameters, “dangerous” services, and freedom to relocate the syslogs.
Let the user be on their own and take responsibility for breaking their system with a big fat “We told you so!” to shame them. No one else will be affected.
“Oh, you enabled the hidden toggle? BUG REPORT CLOSED. Your own fault!”
I’m fine with that. 
1 Like
Correct, we moved rsync to an App in SCALE for exactly this kind of scenario. This means the base SCALE OS is not vulnerable, only the App if you have deployed it. Users running normal UI-based rsync tasks are not impacted. The App will be getting an update as soon as Debian pushes their fixes. (Not in our control)
CORE will get an update in the future to address as well, ETA is TBD still. Good news is that we see very small numbers of folks running rsync daemon on CORE as well (Low single digits), so most system are not at risk.
1 Like
Can you clarify this? I thought the Rsync “App” in SCALE was based on a Docker container that is not dependent on the host’s libraries?
It could be updated, independent of the version (minor/major) of SCALE and regardless of upstream Debian?
Clever … From an IX’ perspective
Your OS wouldn’t get a CVE , and unless users set the APP up with “system files” access - You might prevent a nasty “Open sourcehole”.
What about users running rsync in Cron or CLI ?
You are going to pull in an updated Debian system rsync too (once it has been released/backported) correct ?
Sorry, will clarify. We roll the app, and yes it is a pre-packaged container. But we roll that App from Debian sources (bookworm), so once those fixes land upstream then we can update the app. It in no way is tied to what is deployed on the local TrueNAS install. So we can easily re-roll the app and push an update to users out of band from the normal TrueNAS software update cycle.
1 Like
That scenario is not impacted by this bug. Just using the rsync command doesn’t put you at risk. Its only if you are hosting an rsyncd server specifically.
I.E. if you are using rsync to push data to some SSH endpoint, you are not impacted.
If you are using rsync to push data to a remote rsyncd service on another system, only that other host system is impacted, not your TrueNAS send / recv job.
I read that too.
I was asking if IX would regularly update Ie. the OS rsync ( and others) , with Debian fixes.
AKA can we expect the IX Debian to correspond to the Debian upstream versions. For the binaries IX has decided to deliver.
I’d expect that …
Or else you’d prob. be CVE’ed … Correct ?
Yes, we monitor internal tools for CVE’s and update them individually between releases where appropriate. Various reports on this are available on our security site.
Note, that we don’t just blindly update packages from upstream “just because”. Updates have an annoying tendency to bring regressions that nobody appreciates. We review CVE’s individually, assess risk, and backport fixes where appropriate. A lot of time there are CVE’s mentioned in some package version, but we don’t bother patching because its not relevant to TrueNAS. I.E. we don’t compile that specific option, or we don’t have that functionality used in any way that can be exploited, etc.
When we do major releases of software, I.E. 24.10 → 25.04, then we do the sweeping bulk update of packages, and deal with regressions through the normal SQA / BETA / RC processes.
2 Likes
Btw: I just finished “securing” all my rsync(d) modules with:
User:Pass & host allow/deny
auth users =
hosts allow = nasxxx
hosts deny = *
Now let’s see when Debian is fixing rsync 
Btw:
If i ever wanted to use the rsync from “GUI”, i suppose the
--password-file=xxx
Should go into the Auxllary Parameters field … Correct ?
