Bug 348161 - Port rsync to use NSS library for cryptography
Summary: Port rsync to use NSS library for cryptography
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: rsync
Version: rawhide
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
Assignee: Michal Ruprich
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: CryptoConsolidation
TreeView+ depends on / blocked
 
Reported: 2007-10-23 10:22 UTC by Peter Vrabec
Modified: 2019-12-10 09:29 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-05 16:01:10 UTC
Type: ---


Attachments (Terms of Use)

Description Peter Vrabec 2007-10-23 10:22:49 UTC
rsync should be ported to use NSS library for cryptography.
See the tracking bug for details and links on how it could be done.

Comment 1 Andrew Bartlett 2008-08-29 08:05:40 UTC
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).

Comment 2 Matt McCutchen 2009-11-21 06:13:08 UTC
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.

Comment 3 Simo Sorce 2009-11-21 15:33:07 UTC
Matt,
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 ?

Comment 4 Matt McCutchen 2009-11-24 02:57:10 UTC
I should stop trying to speak for upstream.  I don't want to be stuck in the middle of this debate.

Comment 5 Fedora Admin XMLRPC Client 2010-10-05 11:59:51 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 6 Fedora Admin XMLRPC Client 2012-05-07 09:31:44 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 7 Fedora Admin XMLRPC Client 2014-09-30 12:14:00 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 8 Fedora Admin XMLRPC Client 2015-04-09 10:21:57 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 9 Fedora Admin XMLRPC Client 2016-10-17 10:55:30 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 10 Nikos Mavrogiannopoulos 2017-01-05 16:01:10 UTC
This is no longer on-going effort (see tracker bug).


Note You need to log in before you can comment on or make changes to this bug.