Hi! On Fri, Jan 20, 2017 at 10:55:32AM +0100, Christian Hofstaedtler wrote: > * Salvatore Bonaccorso <car...@debian.org> [170120 09:48]: > > > For the TclTk issue, looks like this upstream patch: > > > https://github.com/ruby/ruby/commit/a2b8925a94a672235ca6a16e584bf09026a957ab > > > If this is the correct patch, 2.3.0 has this fixed, but 2.1.x needs > > > a patch. > > > > Thanks added the commit as well, and the fixed version to the tracker. I > > *think*, although a problem in the source, this might not rally need an > > update > > in jessie via a DSA, since the issue is incombination with cancel_eval > > which is > > supported in Tcl/Tk8.6 or later, but we don't have that for jessie. So I > > would > > tend to just mark that one as no-dsa at least. Or do I miss something? > > Right; I didn't remember we are building with tcl8.5 in jessie. So > looks like no-dsa for that, yes. It looks like the patch might just > apply as is to ruby2.1, so when doing an update we could try > sticking it in just because.
So right, agree we can in any update include that as well. Now the question is if the remaining CVE warrant a DSA on it's own or if it is sufficient to update via a point release. AFAICT, as well for CVE-2016-2339, to exploit the flaw one would need to execute untrusted ruby code, or, passing an untrusted class to the Fiddle module. So I'm not sure if CVE-2016-2339 would as well be rather "no-dsa". @Moritz, strong opinion on that? If noth I would say to mark all of the ruby2.1 CVEs open (CVE-2016-7798, CVE-2016-2337 and CVE-2016-2339) as no-dsa and include them (if you can) in the next point release or for any future ruby2.1 DSA. Salvatore
