Bugzilla Bug 201726

See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=437148 for details,
basically these features can be misused for user to gain an undesired shell
access.

- We don't ship this w/ unison support
- subversion support is optional on USE=subversion
- rsync support is enabled by default in the ebuild.

Some of insecure commands have been disabled in CVS, no release yet however,
plus it's unlikely it will ever cover all potential bypasses via these
features. 

So:

- we can either make rsync support optional as well, change the use flag
descriptions in use.local.desc accordingly and point users to
http://scponly.cvs.sourceforge.net/scponly/scponly/SECURITY?&view=markup for
info on security implications of those options

- or hard-disable the functionality

Opinions?

Thanks for finding that one, Jakub.

The rsync&co functionality is broken by design.
I'd say:

1) Disable all of unison, svn and rsync by default, introduce (by default
disabled) use-flags and if those are enabled, ewarn about the issues and refer
people to the SECURITY file.

2) I'd also vote for the SECURITY file to be included in the ebuild.

3) Patches from the svn or latest release should get into an ebuild that goes
stable afterwards. 

Matsuu, please advise.

4.6-r3 in cvs. added rsync USE flag and added files/SECURITY.
I tried unsuccessfully to backport patches.

4.8 in cvs.

Thx Matsuu. I presume it is fixed in 4.8 (their wiki seems out of date)?

Arches please test and mark stable. Target keywords are:

scponly-4.8.ebuild:KEYWORDS="amd64 ppc sparc x86"

x86 stable

ppc stable

sparc stable

amd64 done.

This one is ready for GLSA vote. I tend to vote NO.

I think we should GLSA this together with 203099, and note the insecurities of
svn.

Sounds like a good idea.

GLSA 200802-06, sorry for the delay.