Red Hat Bugzilla – Bug 348161
Port rsync to use NSS library for cryptography
Last modified: 2017-01-05 11:01:10 EST
rsync should be ported to use NSS library for cryptography.
See the tracking bug for details and links on how it could be done.
Given rsync uses (only) MD4, and NSS considers this deprecated, how do you proposed to do this? (Without breaking the protocol, or crippling it's performance).
Note that protocols 30 and newer use MD5.
Upstream might be reluctant to introduce an NSS dependency just for two hash algorithms that are not used in a particularly security-sensitive context. IIUC, all that an attacker who broke the crypto could do is create a file that rsync would transfer incorrectly.
there is also the problem of preventing a mirror from syncing the right file therefore leaving in place a harmful one,
If you think of distribution packages this is worrisome.
It's true that it is not that easy to exploit, but that's not the point.
It would be nice if we could have modular signing so that the algorithm to be used could be negotiated. Then we could add a whole lot of algorithms though NSS and keep adding new ones when they come out wihtout having to change rsync itself. As long as 2 machines have at least one common allowed algorithm they will be able to transfer files no problem .
How much you think upstream would be willing to accept a patch that allows you to compile (optionally) rsync with NSS support and how much do you think adding a negotiation for signing algorithms would be acceptable ?
I should stop trying to speak for upstream. I don't want to be stuck in the middle of this debate.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This is no longer on-going effort (see tracker bug).