From: Vladimir V. <vl...@ve...> - 2012-07-13 19:54:34
|
There is a security issue in Ganglia Web going back to at least 3.1.7 which can lead to arbitrary script being executed with web user privileges possibly leading to a machine compromise. Issue has been fixed in the latest version of Ganglia Web which can be downloaded from https://sourceforge.net/projects/ganglia/files/ganglia-web/3.5.1/ If you are running Ganglia Web open on the internet you are advised to upgrade ASAP or at a minimum password protect access to Ganglia Web. We'll have a write up about details of the vulnerability in few days. Sincerely, Vladimir |
From: Daniel P. <da...@po...> - 2012-07-15 17:27:14
|
I think we need to be clear about the support lifecycle for older versions - I remember 3.0.x was being supported for a while when 3.1.x was in use - I'm not sure if anyone has taken on 3.1.x support? Debian 6.0 (squeeze) is carrying the 3.1.7 package. http://packages.debian.org/search?keywords=ganglia-webfrontend The Debian security team will accept a patch on that (e.g. a 3.1.8 release) - they won't accept other changes. For example, they won't push out a 3.5.1 package to Debian 6.0 users. Even when Debian 7.0 (wheezy) is released later this year, Debian 6.0 is still supported by security updates for 1 year. How do people feel about a 3.1.8 release? Is there anything else particularly urgent that should be cherry-picked for such a release? Do other distros need 3.1.8 too? Although 3.3.5 is listed on the page above, I'm going to push for 3.5.x to be included in Debian 7.0 - that means it will be around for 3 years from now. I think it is a good idea to have a branch for 3.5.x minor updates so that security fixes for Debian and other distros can be cherry-picked for such releases. On 13/07/12 21:54, Vladimir Vuksan wrote: > There is a security issue in Ganglia Web going back to at least 3.1.7 > which can lead to arbitrary script being executed with web user privileges > possibly leading to a machine compromise. Issue has been fixed in the > latest version of Ganglia Web which can be downloaded from > > https://sourceforge.net/projects/ganglia/files/ganglia-web/3.5.1/ > > If you are running Ganglia Web open on the internet you are advised to > upgrade ASAP or at a minimum password protect access to Ganglia Web. > > We'll have a write up about details of the vulnerability in few days. > > Sincerely, > > Vladimir > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Ganglia-general mailing list > Gan...@li... > https://lists.sourceforge.net/lists/listinfo/ganglia-general > |
From: Bernard Li <be...@va...> - 2012-07-15 18:28:11
|
Hi Daniel: On Sun, Jul 15, 2012 at 10:26 AM, Daniel Pocock <da...@po...> wrote: > I think we need to be clear about the support lifecycle for older > versions - I remember 3.0.x was being supported for a while when 3.1.x > was in use - I'm not sure if anyone has taken on 3.1.x support? I saw Kostas on IRC and talked to him briefly about the security vulnerability and he mentioned that he will take a look at backporting fixes to 3.1.7 since that is the latest version available on EPEL. I don't think he has volunteered to take over support for the entire branch, but will at least work on releasing updated RPMs for EPEL users. Hopefully he could chime in on this ;-) Thanks, Bernard |
From: Daniel P. <da...@po...> - 2012-07-15 18:40:51
|
On 15/07/12 20:27, Bernard Li wrote: > Hi Daniel: > > On Sun, Jul 15, 2012 at 10:26 AM, Daniel Pocock <da...@po...> wrote: > > >> I think we need to be clear about the support lifecycle for older >> versions - I remember 3.0.x was being supported for a while when 3.1.x >> was in use - I'm not sure if anyone has taken on 3.1.x support? >> > I saw Kostas on IRC and talked to him briefly about the security > vulnerability and he mentioned that he will take a look at backporting > fixes to 3.1.7 since that is the latest version available on EPEL. I > don't think he has volunteered to take over support for the entire > branch, but will at least work on releasing updated RPMs for EPEL > users. > > Hopefully he could chime in on this ;-) > I don't think there is any obligation on anyone to do this - but perhaps it would be useful to track supported versions (and related distros) on a wiki page so we don't duplicate any effort e.g: 3.1.x: Distros: Debian 6, EPEL Updates: Kostas? Note: security fixes only 3.2.x: Note: unsupported, go to 3.5.x? 3.3.x: Note: unsupported, go to 3.5.x? 3.4.x: Note: unsupported, go to 3.5.x? 3.5.x: Distros: Debian 7? Updates: ? Note: we aim to make this the next long-term-support version for Debian 7, EPEL In this example, I've marked 3.[234].x as unsupported because I don't know if any stable distro is carrying any of them - feel free to correct me |
From: Bernard Li <be...@va...> - 2012-07-15 18:48:43
|
Hi Daniel: If you want to start a wiki page for that, that's fine. But in my experience these pages get stale pretty quickly ;-) Cheers, Bernard On Sun, Jul 15, 2012 at 11:40 AM, Daniel Pocock <da...@po...> wrote: > On 15/07/12 20:27, Bernard Li wrote: >> Hi Daniel: >> >> On Sun, Jul 15, 2012 at 10:26 AM, Daniel Pocock <da...@po...> wrote: >> >> >>> I think we need to be clear about the support lifecycle for older >>> versions - I remember 3.0.x was being supported for a while when 3.1.x >>> was in use - I'm not sure if anyone has taken on 3.1.x support? >>> >> I saw Kostas on IRC and talked to him briefly about the security >> vulnerability and he mentioned that he will take a look at backporting >> fixes to 3.1.7 since that is the latest version available on EPEL. I >> don't think he has volunteered to take over support for the entire >> branch, but will at least work on releasing updated RPMs for EPEL >> users. >> >> Hopefully he could chime in on this ;-) >> > > > I don't think there is any obligation on anyone to do this - but perhaps > it would be useful to track supported versions (and related distros) on > a wiki page so we don't duplicate any effort > > e.g: > > 3.1.x: Distros: Debian 6, EPEL Updates: Kostas? Note: security > fixes only > > 3.2.x: Note: unsupported, go to 3.5.x? > > 3.3.x: Note: unsupported, go to 3.5.x? > > 3.4.x: Note: unsupported, go to 3.5.x? > > 3.5.x: Distros: Debian 7? Updates: ? Note: we aim to make > this the next long-term-support version for Debian 7, EPEL > > > In this example, I've marked 3.[234].x as unsupported because I don't > know if any stable distro is carrying any of them - feel free to correct me |
From: Jesse B. <ha...@gm...> - 2012-07-16 00:12:11
|
On Sun, Jul 15, 2012 at 2:48 PM, Bernard Li <be...@va...> wrote: > Hi Daniel: > > If you want to start a wiki page for that, that's fine. But in my > experience these pages get stale pretty quickly ;-) While true, "stale" != "inaccurate" or even "useless". I've written information on (internal) wiki pages that is 5 years old, with nary a change. The information is still accurate and useful to this day. -- Jesse Becker |
From: Daniel P. <da...@po...> - 2012-08-02 20:35:44
|
Just wondering if anyone has already started looking at doing 3.1.8 with the security fix? On 15/07/12 18:48, Bernard Li wrote: > Hi Daniel: > > If you want to start a wiki page for that, that's fine. But in my > experience these pages get stale pretty quickly ;-) > > Cheers, > > Bernard > > On Sun, Jul 15, 2012 at 11:40 AM, Daniel Pocock <da...@po...> wrote: >> On 15/07/12 20:27, Bernard Li wrote: >>> Hi Daniel: >>> >>> On Sun, Jul 15, 2012 at 10:26 AM, Daniel Pocock <da...@po...> wrote: >>> >>> >>>> I think we need to be clear about the support lifecycle for older >>>> versions - I remember 3.0.x was being supported for a while when 3.1.x >>>> was in use - I'm not sure if anyone has taken on 3.1.x support? >>>> >>> I saw Kostas on IRC and talked to him briefly about the security >>> vulnerability and he mentioned that he will take a look at backporting >>> fixes to 3.1.7 since that is the latest version available on EPEL. I >>> don't think he has volunteered to take over support for the entire >>> branch, but will at least work on releasing updated RPMs for EPEL >>> users. >>> >>> Hopefully he could chime in on this ;-) >>> >> >> >> I don't think there is any obligation on anyone to do this - but perhaps >> it would be useful to track supported versions (and related distros) on >> a wiki page so we don't duplicate any effort >> >> e.g: >> >> 3.1.x: Distros: Debian 6, EPEL Updates: Kostas? Note: security >> fixes only >> >> 3.2.x: Note: unsupported, go to 3.5.x? >> >> 3.3.x: Note: unsupported, go to 3.5.x? >> >> 3.4.x: Note: unsupported, go to 3.5.x? >> >> 3.5.x: Distros: Debian 7? Updates: ? Note: we aim to make >> this the next long-term-support version for Debian 7, EPEL >> >> >> In this example, I've marked 3.[234].x as unsupported because I don't >> know if any stable distro is carrying any of them - feel free to correct me |
From: Bernard Li <be...@va...> - 2012-08-02 21:21:13
|
Hi Daniel: On Thu, Aug 2, 2012 at 1:35 PM, Daniel Pocock <da...@po...> wrote: > Just wondering if anyone has already started looking at doing 3.1.8 with > the security fix? That depends. Are we still maintaining the 3.1.x tree? Traditionally we have kept with the current branch and one release branch before. For instance if current web is at 3.5 then we maintain that and 3.4. I believe Kostas has already pushed out patches for 3.1.7 to Fedora/EPEL so in terms of distributed binary packages I guess we should be fine? We could potentially pull the old versions from SourceForge.net so people don't download the old versions, but they should really be getting the latest and greatest... Cheers, Bernard |
From: Daniel P. <da...@po...> - 2012-08-02 21:36:02
|
On 02/08/12 21:21, Bernard Li wrote: > Hi Daniel: > > On Thu, Aug 2, 2012 at 1:35 PM, Daniel Pocock <da...@po...> wrote: > >> Just wondering if anyone has already started looking at doing 3.1.8 with >> the security fix? > > That depends. Are we still maintaining the 3.1.x tree? Traditionally > we have kept with the current branch and one release branch before. > For instance if current web is at 3.5 then we maintain that and 3.4. I remember that logic - but that doesn't really reflect what the distributions do Just backporting/cherry-picking the most essential security fixes to an old branch shouldn't be a big pain though > I believe Kostas has already pushed out patches for 3.1.7 to > Fedora/EPEL so in terms of distributed binary packages I guess we > should be fine? Debian 6 also has 3.1.x - when this was mentioned before, I thought Kostas was updating the 3.1 branch and then the Debian and Fedora packages could all be built from the same tarball Kostas, could you possibly commit what you did onto the 3.1 branch and then I'll release a tarball? However, I can't see the 3.1 branch in git... does anyone know where it went or a quick way to revive it? $ git branch -a * master release/3.3 release/3.4 remotes/origin/HEAD -> origin/master remotes/origin/master remotes/origin/php-support remotes/origin/release/3.3 remotes/origin/release/3.4 > We could potentially pull the old versions from SourceForge.net so > people don't download the old versions, but they should really be > getting the latest and greatest... That's not what distributions support - keep in mind, for many people, they only need something basic, they are happy to run apt-get or yum and get the package in 30 seconds, and that convenience is more important than new features - so they are not going to dedicate 30-60 minutes to downloading a tarball and working out what to do with it |
From: Bernard Li <be...@va...> - 2012-08-02 21:49:46
|
Hi Daniel: On Thu, Aug 2, 2012 at 2:35 PM, Daniel Pocock <da...@po...> wrote: > That's not what distributions support - keep in mind, for many people, > they only need something basic, they are happy to run apt-get or yum and > get the package in 30 seconds, and that convenience is more important > than new features - so they are not going to dedicate 30-60 minutes to > downloading a tarball and working out what to do with it Well if we agree that we are EOL'ing 3.1, then it is up to the distributions who are still on the old version to maintain it for security patches. I don't think it's really our responsibility to fix bugs for releases that are old. We have better things to do with our time. Just my $0.02. Cheers, Bernard |
From: Daniel P. <da...@po...> - 2012-08-02 21:57:03
|
On 02/08/12 21:49, Bernard Li wrote: > Hi Daniel: > > On Thu, Aug 2, 2012 at 2:35 PM, Daniel Pocock <da...@po...> wrote: > >> That's not what distributions support - keep in mind, for many people, >> they only need something basic, they are happy to run apt-get or yum and >> get the package in 30 seconds, and that convenience is more important >> than new features - so they are not going to dedicate 30-60 minutes to >> downloading a tarball and working out what to do with it > > Well if we agree that we are EOL'ing 3.1, then it is up to the > distributions who are still on the old version to maintain it for > security patches. I don't think it's really our responsibility to fix > bugs for releases that are old. We have better things to do with our > time. Not quite... Kostas already did the effort for Fedora Someone (probably me) has to do the same for Debian End result: it is not some invisible person out there from the distribution community - it comes back to us If we don't do it, Ganglia would be dropped from the distributions. Keeping a branch just means that we can avoid duplicating effort on such things - the branch doesn't need to have every security enhancement (e.g. the recent gid stuff), just essential web security fixes. There is nothing else I have seen in the last 6 months that belongs on 3.1 |
From: Bernard Li <be...@va...> - 2012-08-02 22:08:46
|
Perhaps I'm totally off here but is this saying 3.3.5 is under "testing" and will eventually be "stable"? http://packages.qa.debian.org/g/ganglia.html If that is the case, shouldn't we work on backport it into the 3.3.x tree as opposed to 3.1.x tree? Regards, Bernard On Thu, Aug 2, 2012 at 2:56 PM, Daniel Pocock <da...@po...> wrote: > > > On 02/08/12 21:49, Bernard Li wrote: >> Hi Daniel: >> >> On Thu, Aug 2, 2012 at 2:35 PM, Daniel Pocock <da...@po...> wrote: >> >>> That's not what distributions support - keep in mind, for many people, >>> they only need something basic, they are happy to run apt-get or yum and >>> get the package in 30 seconds, and that convenience is more important >>> than new features - so they are not going to dedicate 30-60 minutes to >>> downloading a tarball and working out what to do with it >> >> Well if we agree that we are EOL'ing 3.1, then it is up to the >> distributions who are still on the old version to maintain it for >> security patches. I don't think it's really our responsibility to fix >> bugs for releases that are old. We have better things to do with our >> time. > > Not quite... Kostas already did the effort for Fedora > > Someone (probably me) has to do the same for Debian > > End result: it is not some invisible person out there from the > distribution community - it comes back to us > > If we don't do it, Ganglia would be dropped from the distributions. > > Keeping a branch just means that we can avoid duplicating effort on such > things - the branch doesn't need to have every security enhancement > (e.g. the recent gid stuff), just essential web security fixes. There > is nothing else I have seen in the last 6 months that belongs on 3.1 > > > > > |
From: Daniel P. <da...@po...> - 2012-08-02 22:39:13
|
On 02/08/12 22:08, Bernard Li wrote: > Perhaps I'm totally off here but is this saying 3.3.5 is under > "testing" and will eventually be "stable"? > > http://packages.qa.debian.org/g/ganglia.html > > If that is the case, shouldn't we work on backport it into the 3.3.x > tree as opposed to 3.1.x tree? I was going to get to that... wheezy (Debian 7) probably won't be released for another few months Even after that, people with squeeze (Debian 6) have been promised security updates for 12 months from the official release of wheezy: http://www.debian.org/security/faq#lifespan I really tried to get 3.4 and standalone ganglia-web ready for Debian 7, but as I am not a full DD and I can't do all the things myself (like the recent minimised javascript issue), this didn't happen before the freeze process began - so it looks like we will be seeing 3.3.x in some form for up to another 3.5 years from now. This is why I made a big push to get the new web code into the 3.3 releases though: so at least it will be there in some form for Debian users to admire (and hopefully update) |
From: Kostas G. <k.g...@at...> - 2012-08-03 17:17:00
|
On Thu, Aug 02, 2012 at 09:35:47PM +0000, Daniel Pocock wrote: > I remember that logic - but that doesn't really reflect what the > distributions do > > Just backporting/cherry-picking the most essential security fixes to an > old branch shouldn't be a big pain though > > > I believe Kostas has already pushed out patches for 3.1.7 to > > Fedora/EPEL so in terms of distributed binary packages I guess we > > should be fine? > > Debian 6 also has 3.1.x - when this was mentioned before, I thought > Kostas was updating the 3.1 branch and then the Debian and Fedora > packages could all be built from the same tarball > > Kostas, could you possibly commit what you did onto the 3.1 branch and > then I'll release a tarball? As you noticed there are no branches (or tags) for old releases :( If we can ressurect them I'll be happy to push the fixes. Kostas |
From: Daniel P. <da...@po...> - 2012-08-09 12:18:11
|
>> Kostas, could you possibly commit what you did onto the 3.1 branch and >> then I'll release a tarball? > > As you noticed there are no branches (or tags) for old releases :( > If we can ressurect them I'll be happy to push the fixes. > https://github.com/ganglia/monitor-core/branches - it is there now, release/3.1 and all the 3.1.x tags Please CC me directly when committed and I'll tag 3.1.8 I can resurrect other branches too, please let me know if required - I'll send a separate email about the process |