From ${URL} : I'm the librsync (not rsync) maintainer. I can confirm this is a real bug, and I would like a CVE assigned. I appreciate Mik reporting this. Since it's now been discussed in public I don't see any point treating this as embargoed. I'm working on his patch adding BLAKE2 (eg making it pass tests, having an option for back-compatibility) so that it can be released. reference: https://github.com/librsync/librsync/issues/5 @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
Where is the patch supposedly fixing this bug? :/ Thanks
Maybe it would be better to add librsync-1.0.0 to the tree? I can see that 5 packages use librsync: app-backup/burp - it's ready for librsync-1.0.0 I don't know if packages below are reade for librsync-1.0.0 app-backup/duplicity app-backup/rdiff-backup net-misc/dropbox sys-cluster/csync2
librsync-2.0.0 is in the portage tree now in testing. Since the package is without a maintainer I can take care of it.
Alessandro Calorì has offered and is set now as the proxy maintainer in metadata. commit a7f5caaeca9a1d454cf918dcbfa275b2245bc97b Author: Ian Delaney <idella4@gentoo.org> Date: Fri Dec 18 20:11:12 2015 +0800 net-libs/librsync: set new proxy maintainer in metadata Documented offer by him made in the gentoo (security) bug #525396 Gentoo bug: #525396 0.9.7-r3 is s tabled version. It appears likely that this bump will suufice as a fix to this security issue given it was lodged in 2014-10-14 and a bumped version will carry this patch from then
Maintainer(s), please advise if you are ready for stabilization or call for stabilization yourself.
(In reply to Yury German from comment #5) > Maintainer(s), please advise if you are ready for stabilization or call for > stabilization yourself. The package is ready for stabilization and the latest version fixes this bug.
Arch teams please stabilise =net-libs/librsync-2.0.0 Targets: alpha amd64 arm ia64 ppc ppc64 sparc x86 Hmm ~hppa. This wasn't done last time but I would think it could easily be added to the mix. jer what do you think?
(In reply to Ian Delaney from comment #7) > Arch teams please stabilise =net-libs/librsync-2.0.0 > > Targets: alpha amd64 arm ia64 ppc ppc64 sparc x86 > > Hmm ~hppa. This wasn't done last time but I would think it could easily be > added to the mix. jer what do you think? You forgot to CC me? Anyway (and for some reason I keep repeating this lately), architectures with no stable keywords on a package do NOT need to stabilise. 1) Adding a stable keyword would then suddenly add the burden of security support for that architecture. 2) Security bugs are no place to improve the number of available packages for a given architecture.
It looks like this update will break the stable duplicity. I take it that there is no backport available? I also noted that the ebuild lacks a subslot. I'm not suggesting that this be delayed to address this.
(In reply to Richard Freeman from comment #9) > It looks like this update will break the stable duplicity. I take it that > there is no backport available? librsync 1.0 breaks API compatibility with the previous version. Every package which depends on librsync would break _IF_ it does not support new API's. This problem has nothing to do with the library itself but has to be addressed in the application's ebuilds which depend on it. (In reply to Richard Freeman from comment #9) > I also noted that the ebuild lacks a subslot. I am working on the possibility to use slots for the two versions (0.9.7 and 2.0.0). My suggestion ATM is to stabilize both and to let portage to handle dependencies. Also patching the applications to support the new API's is a possibility and it is trivial: only one function signature seems to have been changed). I am also trying to backport the security patches to version 0.9.7.
> > (In reply to Richard Freeman from comment #9) > > I also noted that the ebuild lacks a subslot. > > I am working on the possibility to use slots for the two versions (0.9.7 and > 2.0.0). My suggestion ATM is to stabilize both and to let portage to handle > dependencies. I wasn't suggesting adding support for slots, just subslots, though both would obviously be nice. Portage won't rebuild reverse-deps without them.
app-backup/rdiff-backup-1.3.3-r1.ebuild : DEPEND -=- ~net-libs/librsync-0.9.7
AMD64: Definitely breaks duplicity, rdiff-backup has explicit dependency on current version. Attached Build log for duplicity
Created attachment 421254 [details] BuildLog
The API differences are: - the constant "RS_DEFAULT_STRONG_LEN" (deleted); - the function "rs_sig_begin" (signature changed). These differences are due to the fact that new versions on librsync (1.0 and above) don't use MD4 as default. If a package does not support the new ABI the relative ebuild has to limit the compatible version as Jeroen Roovers described above for rdiff-backup. librsync 0.9.7 and 2.0.0 cannot be installed in parallel because of some file collisions (headers and the rdiff utility). I'm working on the makefiles to make them fit in two different slots but as for now the ebuilds are strictly exclusives.
(In reply to Craig from comment #13) > AMD64: Definitely breaks duplicity, rdiff-backup has explicit dependency on > current version. > > Attached Build log for duplicity I'd suggest keeping duplicity issues in the duplicity bug which is linked to this one. I'm just waiting on radhermit to OK stabilizing the newer version, which seems to work fine with the new version.
(In reply to Richard Freeman from comment #16) > (In reply to Craig from comment #13) > > AMD64: Definitely breaks duplicity, rdiff-backup has explicit dependency on > > current version. > > > > Attached Build log for duplicity > > I'd suggest keeping duplicity issues in the duplicity bug which is linked to > this one. I'm just waiting on radhermit to OK stabilizing the newer > version, which seems to work fine with the new version. Radhermit isnt around https://www.gentoo.org/inside-gentoo/developers/unavailable-developers.html
(In reply to Craig from comment #17) > (In reply to Richard Freeman from comment #16) > > (In reply to Craig from comment #13) > > > AMD64: Definitely breaks duplicity, rdiff-backup has explicit dependency on > > > current version. > > > > > > Attached Build log for duplicity > > > > I'd suggest keeping duplicity issues in the duplicity bug which is linked to > > this one. I'm just waiting on radhermit to OK stabilizing the newer > > version, which seems to work fine with the new version. > > Radhermit isnt around > https://www.gentoo.org/inside-gentoo/developers/unavailable-developers.html Thanks for the catch. I'll co-maintain this and take care of it.
amd64 stable
x86 stable.
sparc stable
arm stable
alpha stable
ia64 stable
ppc stable
Stable for PPC64.
GLSA Vote: No Thank you all for you work. Closing as [noglsa].
