Hello,
following the policy for nonresponsive maintainers, does anyone have a contact of Jeroen van Meeuwen (kanarip) ? All three mail addresses listed here http://fedoraproject.org/wiki/User:Kanarip bounce back, including FAS email kanarip@kanarip.com.
He is a co-maintainer of quite a number of packages (https://admin.fedoraproject.org/pkgdb/packager/kanarip/), which now have ~20 unfixed vulnerabilities combined in EPEL, some of them for over a year.
Thank you!
On Wed, Aug 6, 2014 at 10:53 AM, Jan Rusnacko jrusnack@fedoraproject.org wrote:
Hello,
following the policy for nonresponsive maintainers, does anyone have a contact of Jeroen van Meeuwen (kanarip) ? All three mail addresses listed here http://fedoraproject.org/wiki/User:Kanarip bounce back, including FAS email kanarip@kanarip.com.
He is a co-maintainer of quite a number of packages ( https://admin.fedoraproject.org/pkgdb/packager/kanarip/), which now have ~20 unfixed vulnerabilities combined in EPEL, some of them for over a year.
Hello,
this must be the second or third time we have issues contacting him. Wouldn't it now be time to finally go ahead and orphan all his packages? I mean he had time to respond and tried quite a lot to get in touch with him. [1]
Johannes
[1] https://lists.fedoraproject.org/pipermail/devel/2014-July/200860.html
Thank you!
-- Jan Rusnacko, Fedora Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
El 2014-08-06 11:58, Johannes Lips escribió:
On Wed, Aug 6, 2014 at 10:53 AM, Jan Rusnacko jrusnack@fedoraproject.org wrote:
Hello,
following the policy for nonresponsive maintainers, does anyone have a contact of Jeroen van Meeuwen (kanarip) ? All three mail addresses listed here http://fedoraproject.org/wiki/User:Kanarip [1] bounce back, including FAS email kanarip@kanarip.com.
He is a co-maintainer of quite a number of packages (https://admin.fedoraproject.org/pkgdb/packager/kanarip/ [2]), which now have ~20 unfixed vulnerabilities combined in EPEL, some of them for over a year.
Hello,
this must be the second or third time we have issues contacting him. Wouldn't it now be time to finally go ahead and orphan all his packages? I mean he had time to respond and tried quite a lot to get in touch with him. [1]
Johannes
[1] https://lists.fedoraproject.org/pipermail/devel/2014-July/200860.html
I've tried to contact him for months, with no response. +1 to go ahead on the unresponsive maintainer policy.
On Wed, 2014-08-06 at 12:53 +0200, Juan Orti Alcaine wrote:
El 2014-08-06 11:58, Johannes Lips escribió:
On Wed, Aug 6, 2014 at 10:53 AM, Jan Rusnacko jrusnack@fedoraproject.org wrote:
Hello,
following the policy for nonresponsive maintainers, does anyone have a contact of Jeroen van Meeuwen (kanarip) ? All three mail addresses listed here http://fedoraproject.org/wiki/User:Kanarip [1] bounce back, including FAS email kanarip@kanarip.com.
He is a co-maintainer of quite a number of packages (https://admin.fedoraproject.org/pkgdb/packager/kanarip/ [2]), which now have ~20 unfixed vulnerabilities combined in EPEL, some of them for over a year.
Hello,
this must be the second or third time we have issues contacting him. Wouldn't it now be time to finally go ahead and orphan all his packages? I mean he had time to respond and tried quite a lot to get in touch with him. [1]
Johannes
[1] https://lists.fedoraproject.org/pipermail/devel/2014-July/200860.html
I've tried to contact him for months, with no response. +1 to go ahead on the unresponsive maintainer policy.
Well, anyone who's at Flock currently has contact with him; he's here. If no-one else does it, I'll try and grab him and let him know about this thread.
On 6 August 2014 10:53, Jan Rusnacko jrusnack@fedoraproject.org wrote:
Hello,
following the policy for nonresponsive maintainers, does anyone have a contact of Jeroen van Meeuwen (kanarip) ? All three mail addresses listed here http://fedoraproject.org/wiki/User:Kanarip bounce back, including FAS email kanarip@kanarip.com.
He is a co-maintainer of quite a number of packages ( https://admin.fedoraproject.org/pkgdb/packager/kanarip/), which now have ~20 unfixed vulnerabilities combined in EPEL, some of them for over a year.
I have run into kanarip and will have him correct the problems one way or another by the end of FLOCK. And I will get the EPEL items dealt with as soon as possible.
Could you give me a list of packages with problems so I can do the second part?
Thank You.
Thank you!
Jan Rusnacko, Fedora Security Team
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On 06.08.2014 16:24, Stephen John Smoogen wrote:
On 6 August 2014 10:53, Jan Rusnacko <jrusnack@fedoraproject.org mailto:jrusnack@fedoraproject.org> wrote:
Hello, following the policy for nonresponsive maintainers, does anyone have a contact of Jeroen van Meeuwen (kanarip) ? All three mail addresses listed here http://fedoraproject.org/wiki/User:Kanarip bounce back, including FAS email kanarip@kanarip.com <mailto:kanarip@kanarip.com>. He is a co-maintainer of quite a number of packages (https://admin.fedoraproject.org/pkgdb/packager/kanarip/), which now have ~20 unfixed vulnerabilities combined in EPEL, some of them for over a year.I have run into kanarip and will have him correct the problems one way or another by the end of FLOCK. And I will get the EPEL items dealt with as soon as possible.
Could you give me a list of packages with problems so I can do the second part?
So the packages in question are: rubygem-actionmailer, rubygem-actionpack, rubygem-activerecord, rubygem-activeresource, rubygem-activesupport, rubygem-rails, rubygem-rack and rubygems. These are relevant bugzillas:
https://bugzilla.redhat.com/show_bug.cgi?id=1115776 https://bugzilla.redhat.com/show_bug.cgi?id=1095129 https://bugzilla.redhat.com/show_bug.cgi?id=1095127 https://bugzilla.redhat.com/show_bug.cgi?id=1095125 https://bugzilla.redhat.com/show_bug.cgi?id=1095122 https://bugzilla.redhat.com/show_bug.cgi?id=1095120 https://bugzilla.redhat.com/show_bug.cgi?id=1095118 https://bugzilla.redhat.com/show_bug.cgi?id=961066 https://bugzilla.redhat.com/show_bug.cgi?id=948706 https://bugzilla.redhat.com/show_bug.cgi?id=924318 https://bugzilla.redhat.com/show_bug.cgi?id=924297 https://bugzilla.redhat.com/show_bug.cgi?id=905374 https://bugzilla.redhat.com/show_bug.cgi?id=905373 https://bugzilla.redhat.com/show_bug.cgi?id=891468 https://bugzilla.redhat.com/show_bug.cgi?id=847202 https://bugzilla.redhat.com/show_bug.cgi?id=843924 https://bugzilla.redhat.com/show_bug.cgi?id=831583 https://bugzilla.redhat.com/show_bug.cgi?id=731453 https://bugzilla.redhat.com/show_bug.cgi?id=731451 https://bugzilla.redhat.com/show_bug.cgi?id=731450 https://bugzilla.redhat.com/show_bug.cgi?id=677629 https://bugzilla.redhat.com/show_bug.cgi?id=1097205 https://bugzilla.redhat.com/show_bug.cgi?id=909088 https://bugzilla.redhat.com/show_bug.cgi?id=814725 https://bugzilla.redhat.com/show_bug.cgi?id=771152 https://bugzilla.redhat.com/show_bug.cgi?id=771151
Looks scary, but it the end it`s just rails, rubygems and rack. All of these are co-maintained with Michael Stahnke, which I have no luck contacting either. There are actually more unfixed vulnerabilities, but I am confident they can be fixed by more active maintainers.
Thank you for helping out, really appreciated !
Thank You.
Thank you! -- Jan Rusnacko, Fedora Security Team -- devel mailing list devel@lists.fedoraproject.org <mailto:devel@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct-- Stephen J Smoogen.
<snip>
Could you give me a list of packages with problems so I can do the
second part? So the packages in question are: rubygem-actionmailer, rubygem-actionpack, rubygem-activerecord, rubygem-activeresource, rubygem-activesupport, rubygem-rails, rubygem-rack and rubygems. These are relevant bugzillas:
https://bugzilla.redhat.com/show_bug.cgi?id=1115776 https://bugzilla.redhat.com/show_bug.cgi?id=1095129 https://bugzilla.redhat.com/show_bug.cgi?id=1095127 https://bugzilla.redhat.com/show_bug.cgi?id=1095125 https://bugzilla.redhat.com/show_bug.cgi?id=1095122 https://bugzilla.redhat.com/show_bug.cgi?id=1095120 https://bugzilla.redhat.com/show_bug.cgi?id=1095118 https://bugzilla.redhat.com/show_bug.cgi?id=961066 https://bugzilla.redhat.com/show_bug.cgi?id=948706 https://bugzilla.redhat.com/show_bug.cgi?id=924318 https://bugzilla.redhat.com/show_bug.cgi?id=924297 https://bugzilla.redhat.com/show_bug.cgi?id=905374 https://bugzilla.redhat.com/show_bug.cgi?id=905373 https://bugzilla.redhat.com/show_bug.cgi?id=891468 https://bugzilla.redhat.com/show_bug.cgi?id=847202 https://bugzilla.redhat.com/show_bug.cgi?id=843924 https://bugzilla.redhat.com/show_bug.cgi?id=831583 https://bugzilla.redhat.com/show_bug.cgi?id=731453 https://bugzilla.redhat.com/show_bug.cgi?id=731451 https://bugzilla.redhat.com/show_bug.cgi?id=731450 https://bugzilla.redhat.com/show_bug.cgi?id=677629 https://bugzilla.redhat.com/show_bug.cgi?id=1097205 https://bugzilla.redhat.com/show_bug.cgi?id=909088 https://bugzilla.redhat.com/show_bug.cgi?id=814725 https://bugzilla.redhat.com/show_bug.cgi?id=771152 https://bugzilla.redhat.com/show_bug.cgi?id=771151
Looks scary, but it the end it`s just rails, rubygems and rack. All of these are co-maintained with Michael Stahnke, which I have no luck contacting either. There are actually more unfixed vulnerabilities, but I am confident they can be fixed by more active maintainers.
Hey, sorry for not getting some of these updated (you also didn't stay on #fedora-ruby long enough for me to respond). I find that updating many of these breaks API, because ruby library authors are really good at fixing security problems while introducing new issues. Many of them I didn't think I could update in EPEL -- for example moving rails from 2.x to 3.x is a HUGE change.
Rubygems got rolled into ruby upstream - so the old rubygems isn't maintained upstream.
Rack I should fix - they are good at compatibility.
I also welcome any co-maintainers on these items. I used to use these packages lots from EPEL, at my current workplace I don't really.
On 06.08.2014 23:28, Michael Stahnke wrote:
<snip> > > Could you give me a list of packages with problems so I can do the second part? So the packages in question are: rubygem-actionmailer, rubygem-actionpack, rubygem-activerecord, rubygem-activeresource, rubygem-activesupport, rubygem-rails, rubygem-rack and rubygems. These are relevant bugzillas: https://bugzilla.redhat.com/show_bug.cgi?id=1115776 https://bugzilla.redhat.com/show_bug.cgi?id=1095129 https://bugzilla.redhat.com/show_bug.cgi?id=1095127 https://bugzilla.redhat.com/show_bug.cgi?id=1095125 https://bugzilla.redhat.com/show_bug.cgi?id=1095122 https://bugzilla.redhat.com/show_bug.cgi?id=1095120 https://bugzilla.redhat.com/show_bug.cgi?id=1095118 https://bugzilla.redhat.com/show_bug.cgi?id=961066 https://bugzilla.redhat.com/show_bug.cgi?id=948706 https://bugzilla.redhat.com/show_bug.cgi?id=924318 https://bugzilla.redhat.com/show_bug.cgi?id=924297 https://bugzilla.redhat.com/show_bug.cgi?id=905374 https://bugzilla.redhat.com/show_bug.cgi?id=905373 https://bugzilla.redhat.com/show_bug.cgi?id=891468 https://bugzilla.redhat.com/show_bug.cgi?id=847202 https://bugzilla.redhat.com/show_bug.cgi?id=843924 https://bugzilla.redhat.com/show_bug.cgi?id=831583 https://bugzilla.redhat.com/show_bug.cgi?id=731453 https://bugzilla.redhat.com/show_bug.cgi?id=731451 https://bugzilla.redhat.com/show_bug.cgi?id=731450 https://bugzilla.redhat.com/show_bug.cgi?id=677629 https://bugzilla.redhat.com/show_bug.cgi?id=1097205 https://bugzilla.redhat.com/show_bug.cgi?id=909088 https://bugzilla.redhat.com/show_bug.cgi?id=814725 https://bugzilla.redhat.com/show_bug.cgi?id=771152 https://bugzilla.redhat.com/show_bug.cgi?id=771151 Looks scary, but it the end it`s just rails, rubygems and rack. All of these are co-maintained with Michael Stahnke, which I have no luck contacting either. There are actually more unfixed vulnerabilities, but I am confident they can be fixed by more active maintainers.Hey, sorry for not getting some of these updated (you also didn't stay on #fedora-ruby long enough for me to respond). I find that updating many of these breaks API, because ruby library authors are really good at fixing security problems while introducing new issues. Many of them I didn't think I could update in EPEL -- for example moving rails from 2.x to 3.x is a HUGE change.
Rubygems got rolled into ruby upstream - so the old rubygems isn't maintained upstream.
Rack I should fix - they are good at compatibility.
I also welcome any co-maintainers on these items. I used to use these packages lots from EPEL, at my current workplace I don't really.
Thank you for the reply ! So this depends from one vulnerability to another, but in general we don`t necessarily have to (and according to EPEL guidelines we really shouldn`t) update to next major version just to fix the vulnerability. For example: https://bugzilla.redhat.com/show_bug.cgi?id=731450 is for Rails 2.x in EPEL 5, but backporting a fix (https://github.com/rails/rails/commit/bfc432574d0b141fd7fe759edfe9b6771dd306...) is easy.
So please respond to my mail from July and we can start working through these - I`m happy to help you with fix for each of these issues.
Thanks !
+Ruby-sig bcc fedora-devel
<snip>
Hey, sorry for not getting some of these updated (you also didn't stay
on #fedora-ruby long enough for me to respond). I find that updating many of these breaks API, because ruby library authors are really good at fixing security problems while introducing new issues. Many of them I didn't think I could update in EPEL -- for example moving rails from 2.x to 3.x is a HUGE change.
Rubygems got rolled into ruby upstream - so the old rubygems isn't
maintained upstream.
Rack I should fix - they are good at compatibility.
I also welcome any co-maintainers on these items. I used to use these
packages lots from EPEL, at my current workplace I don't really. Thank you for the reply ! So this depends from one vulnerability to another, but in general we don`t necessarily have to (and according to EPEL guidelines we really shouldn`t) update to next major version just to fix the vulnerability. For example: https://bugzilla.redhat.com/show_bug.cgi?id=731450 is for Rails 2.x in EPEL 5, but backporting a fix ( https://github.com/rails/rails/commit/bfc432574d0b141fd7fe759edfe9b6771dd306...) is easy.
So please respond to my mail from July and we can start working through these - I`m happy to help you with fix for each of these issues.
There's been a slew of fixes for the 2.x branch of rails and friends. Some
apply rather easily, others don't. I honestly haven't thought much about it for a while (obviously). It's a bit odd, in that I really doubt that much of anybody is running a rails app from our RPMS in EPEL. Most of the layered products and developers would either bundle it themselves or use software collections, now that they are available.
In reading the discussion on EPEL.next, perhaps some of the fast moving ruby projects should look for a different repository to live inside.
On Wed, Aug 06, 2014 at 14:28:30 -0700, Michael Stahnke stahnma@puppetlabs.com wrote:
Hey, sorry for not getting some of these updated (you also didn't stay on #fedora-ruby long enough for me to respond). I find that updating many of these breaks API, because ruby library authors are really good at fixing security problems while introducing new issues. Many of them I didn't think I could update in EPEL -- for example moving rails from 2.x to 3.x is a HUGE change.
This is a bit sideways, but concerns another Ruby issue. The i686 version of rubylibs uses sse2 instructions (as the builders seem to support it) without checking to make sure the machine that is running the code has support for them.
This breaks xchat and causes issues for some web pages in midori on AMD i686 processors.
Bugs 1101811 and 1103967 seem to have this as their root cause.
-
Adam Williamson -
Bruno Wolff III -
Jan Rusnacko -
Johannes Lips -
Juan Orti Alcaine -
Michael Stahnke -
Stephen John Smoogen