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.
