Security update of Gosa
Hello Michael, you are still listed in dla-needed.txt as the owner of Gosa. Apparently you already prepared a debdiff and sent it to the security team but it was never released. Would it be possible to share it with us? Or can you confirm that the following patches from Jessie will resolve this issue? https://tracker.debian.org/media/packages/g/gosa/changelog-2.7.4%2Breloaded2-1%2Bdeb8u2 CVE-2015-8771: 0006_code-injection-in-samba-hash-generation.patch, 0007_update-sambaHashHook-description.patch. Fix potential code injection issue in Samba hash generation. (CVE-2015-8771) CVE-2014-9760: https://sources.debian.net/src/gosa/2.7.4%2Breloaded2-12/debian/patches/0003_xss-vulnerability-on-login-screen.patch/ Regards Markus signature.asc Description: OpenPGP digital signature
Re: icu package and debdiff [new contributor, first attempt]
Hi Markus, On Mon, Jun 20, 2016 at 12:43:02PM +0200, Markus Koschany wrote: > Hello Roberto, > > > As far as upstream feedback, I presume I should post my updated patches > > to either ticket 12020 or 12276. Would that be the best approach? > > Yes, that would be a good approach indeed. > > > I am not totally clear on what sort of feedback I should seek from > > upstream. Should I just ask for a review of the patches I have > > prepared? Would I do that by posting to the ticket? > > I would post to the ticket and ask for a review of your patches. All > upstreams I have contacted so far were really helpful and of course they > are interested that their software is properly fixed too. > > > > > I'd like to think that small scale and scope of the changes and the fact > > that they are already included in upstream ICU (I think) and in OpenJDK > > means that the changes are solid. However, I understand that a > > regression could be disruptive to wheezy users so I don't want to do > > something that would unreasonably risk that occurring. Could you (or > > anyone else) suggest a course of action here? > > Since Antoine already made a good experience with upstream, I recommend > to contact them by posting to the ticket or other communication channels > (e-mail, IRC, etc.) and ask for a review of your patches. That is the > best course of action in this case. In the unlikely case that they are > totally hostile, you have to use your own judgment but I don't expect > that to happen. > Thanks very much for the feedback. I will do as you suggest and request that upstream review the patches. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com
Re: icu package and debdiff [new contributor, first attempt]
Hello Roberto, On 17.06.2016 18:48, Roberto C. Sánchez wrote: > (This message is directed to Antoine as he gave me the initial feedback, > but I welcome comments and suggestions from anyone). > > Hi Antoine, > > Thanks for the feedback on this a few weeks ago. I've been quite busy > but I don't want to leave this unresolved, so I am making an effort now > to complete this task. Thanks for your work on this. > > On Thu, May 19, 2016 at 01:24:01PM -0400, Antoine Beaupré wrote: >> >> Nitpicking: "Origin:" could be "upstream", or maybe "vendor" for those >> patches. For CVE-2016-0494, specifically, there's this upstream bug >> report which I contributed to: >> > I have updated the origin to upstream and left the java.net URLs > referencing the specific commits from which the patches are drawn. > >> http://bugs.icu-project.org/trac/ticket/12020 >> >> Well, it's the same bug than CVE-2015-4844, basically, since >> CVE-2016-0494 was introduced as part of the CVE-2015-4844. >> >> I think it's useful for upstream if you share those backported patches >> as well, unless they are trivial. It might be useful to send a ping to >> our Ubuntu friends since they have the same version on their side. >> > > As far as upstream feedback, I presume I should post my updated patches > to either ticket 12020 or 12276. Would that be the best approach? Yes, that would be a good approach indeed. > As > far as Ubuntu, would I just mail secur...@ubuntu.com? That seems to be > the only email listed on their wiki page (they don't list a discussion > mailing list): > > https://wiki.ubuntu.com/SecurityTeam/ForDebianDevelopers I don't think you need to forward your patches to Ubuntu. I assume they use the same methods as we do and they will surely monitor Debian security updates. [...] >> I am not even sure the changes are complete even with the >> above. Upstream ICU refers to the following bug: >> >> http://bugs.icu-project.org/trac/ticket/12276 >> >> ... where they link to another secret ticket. Maybe it would be useful >> to share your work there and ask for feedback. Last time they took a few >> days to give feedback, so they seem pretty responsive. >> > I am not totally clear on what sort of feedback I should seek from > upstream. Should I just ask for a review of the patches I have > prepared? Would I do that by posting to the ticket? I would post to the ticket and ask for a review of your patches. All upstreams I have contacted so far were really helpful and of course they are interested that their software is properly fixed too. > > Also, Markus suggested testing, but I have to admit I haven't the > slightest clue how I would go about testing this. ICU appears to have a > test suite, but none of the changes or discussions I have looked at in > relation to these CVEs have included any updates to the unit test suite > to account for these changes. I was also unable to find any evidence in > the unit tests that the features affected by these CVEs are covered > anywhere in the test suite. Of course, my lack of familiarity with the > ICU architecture may mean that the features are covered but I just don't > realize it. > > I'd like to think that small scale and scope of the changes and the fact > that they are already included in upstream ICU (I think) and in OpenJDK > means that the changes are solid. However, I understand that a > regression could be disruptive to wheezy users so I don't want to do > something that would unreasonably risk that occurring. Could you (or > anyone else) suggest a course of action here? Since Antoine already made a good experience with upstream, I recommend to contact them by posting to the ticket or other communication channels (e-mail, IRC, etc.) and ask for a review of your patches. That is the best course of action in this case. In the unlikely case that they are totally hostile, you have to use your own judgment but I don't expect that to happen. Regards, Markus signature.asc Description: OpenPGP digital signature
Re: Wheezy update of roundcube?
On 20.06.2016 10:56, Brian May wrote: > Brian May writes: > >> Markus Koschany writes: >> >>> I just had a closer look at the vulnerabilities. I have marked >>> CVE-2016-5103, CVE-2015-2181 and CVE-2015-2180 as not-affected because >>> the vulnerable code is not present in this version. There is no upstream >>> fix available for CVE-2016-4086. >>> >>> That leaves us with CVE-2015-8864 and CVE-2016-4096 whereby the latter >>> needs more investigation. Some affected plugins don't exist in Wheezy, >>> the rest of the code is quite different. >>> >>> If you agree I intend to fix the two CVEs shortly. At the moment I think >>> a backport is not necessary. >> >> Not sure if you were asking me or the mailing list, however no >> objections from me. I say go ahead and do it. > > Did you still want to do this? > Yes, it is done but I haven't found the time to properly test it yet. I expect an announcement this month. Regards, Markus signature.asc Description: OpenPGP digital signature
Re: Wheezy update of roundcube?
Brian May writes: > Markus Koschany writes: > >> I just had a closer look at the vulnerabilities. I have marked >> CVE-2016-5103, CVE-2015-2181 and CVE-2015-2180 as not-affected because >> the vulnerable code is not present in this version. There is no upstream >> fix available for CVE-2016-4086. >> >> That leaves us with CVE-2015-8864 and CVE-2016-4096 whereby the latter >> needs more investigation. Some affected plugins don't exist in Wheezy, >> the rest of the code is quite different. >> >> If you agree I intend to fix the two CVEs shortly. At the moment I think >> a backport is not necessary. > > Not sure if you were asking me or the mailing list, however no > objections from me. I say go ahead and do it. Did you still want to do this? -- Brian May
