ANNOUNCE: Zope 2.6.3 Release and Security Update
Zope 2.6.3 Release and Security Update Zope 2.6.3 contains a number of security related fixes for issues resolved during a comprehensive security audit conducted in Q4 2003. You may download Zope 2.6.3 from Zope.org: http://www.zope.org/Products/Zope/2.6.3/ **Users of the VerboseSecurity add-on product for Zope please note:** some of the security-related changes in Zope 2.6.3 are incompatible with the VerboseSecurity product. Please uninstall the VerboseSecurity product before upgrading to 2.6.3 to avoid problems. It is expected that VerboseSecurity will be updated to be compatible with Zope 2.6.3 in the near future. Also note that there are binary code changes in the 2.6.3 release, making it impossible to issue an external "hotfix" to resolve these issues. CVS users should be sure to update their sites **and rebuild the C Python extensions** to ensure that all fixes are deployed. In the fourth quarter of 2003, a comprehensive evaluation of the changes to Python from version 2.1 to 2.3.3 was undertaken. This evaluation was designed to assess each change to the Python environment in terms of its potential impact on the Zope application server and Zope applications, with the goal of making Python 2.3.3 the required Python platform for Zope beginning with Zope 2.7. The evaluation was focused on assessing changes to Python in the following contexts: - Changes that would have compatibility or other effects on existing or new Zope applications - Changes that could potentially affect the Zope security architecture or change the behavior of the restricted execution environment used by Zope to run untrusted code In the course of the evaluation, very few of the Python changes in 2.3.3 directly affected the Zope security architecture or had impacts on the restricted execution model. However, a number of pre-existing potential issues were discovered and resolved in the course of the comprehensive security audit that was performed as a part of the Python upgrade evaluation. Zope 2.6.3 provides fixes for all of these issues. A description of each issue, who is affected and issue status is included below. For more information on what is new in this release, see the CHANGES.txt and HISTORY.txt files for the release: - http://www.zope.org/Products/Zope/2.6.3/CHANGES.txt - http://www.zope.org/Products/Zope/2.6.3/HISTORY.txt For more information on the available Zope releases, guidance for selecting the right distribution and installation instructions, please see: http://www.zope.org/Documentation/Misc/InstallingZope.html ISSUES RESOLVED BY Zope 2.6.3: - For loops, list comprehensions, and other iterations in untrusted code Issue Description Iteration over sequences could in some cases fail to check access to an object obtained from the sequence. Subsequent checks (such as for attributes access) of such an object would still be performed, but it should not have been possible to obtain the object in the first place. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - List and dictionary instance methods in untrusted code Issue Description List and dictionary instance methods such as the get method of dictionary objects were not security aware and could return an object without checking access to that object. Subsequent checks (such as for attributes access) of such an object would still be performed, but it should not have been possible to obtain the object in the first place. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Use of import as in untrusted code Issue Description Use of "import as" in Python scripts could potentially rebind names in ways that could be used to avoid appropriate security checks. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Use of min, max, enumerate, iter, and sum in untrusted code Issue Description A number of newer built-ins were either unavailable in untrusted code or did not perform adequate security checking. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Broken binding validation in untrusted code Issue Description The variables bound to page templates and Python scripts such as "context" and "container" were not checked adequately, allowing a script to potentially access those objects without ensuring the necessary permissions on the part of the executing user. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Unpacking in untrusted code Issue Description Unpacking via function calls, variable assignment, exception variables and other contexts did not perform adequate security checks, potentially allowing access to objects that should have been protected. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Unicode passed to RESPONSE.write() could shutdown process Issue Description Inadequate type checking could allow unicode values passed to RESPONSE.write() to be passed into deeper layers of asyncore, where an exception would eventually be generated at a level that would cause the Zserver main loop to terminate. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - PythonScript class security not initialized properly Issue Description Class security was not properly intialized for PythonScripts, potentially allowing access to variables that should be protected. It turned out that most of the security assertions were in fact activated as a side effect of other code, but this fix is still appropriate to ensure that all security declarations are properly applied. Who Is Affected? Sites that use Python Scripts. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - XML-RPC instance marshaling may disclose protected values Issue Description XML-RPC marshalling of class instances used the instance __dict__ to marshal the object, and could include attributes prefixed with an underscore name. These attributes are considered private in Zope and should generally not be disclosed. Who Is Affected? All Zope sites. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - DTML tag dtml-tree may allow DoS attack Issue Description The dtml-tree tag used an "eval" of user-supplied data; its efforts to prevent abuse were ineffective. Who Is Affected? All Zope sites. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Potential cross-site scripting problem in default ZSearch interface Issue Description Browsers that do not escape html in query strings such as Internet Explorer 5.5 could potentially send a script tag in a query string to the ZSearch interface for cross-site scripting. Who Is Affected? Sites that use the default ZSearch interface. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Proxy rights on DTMLMethods transferred via acquisition Issue Description DTMLMethods with proxy rights could incorrectly transfer those rights via acquisition when traversing to a parent object. Who Is Affected? Sites that allow users who have increased permissions in subfolders to write DTMLMethods. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Improper security assertions on DTMLDocument objects Issue Description Some improper security assertions on DTMLDocument objects could potentially allow access to members that should be protected. Who Is Affected? Sites that use DTMLDocuments for secure content. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - PropertyManager 'lines' and 'tokens' properties stored as list Issue Description Some property types were stored in a mutable data type (list) which could potentially allow untrusted code to effect changes on those properties without going through appropriate security checks in particular scenarios. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Inadequate security assertions on admin "find" functions Issue Description Inadequate security assertions on administrative "find" methods could potentially be abused. Who Is Affected? All Zope sites. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - ZTUtils.SimpleTree state handling Issue Description The ZTUtils SimpleTree decompressed tree state data from the request without checking for final size, which could allow for certain types of DoS attacks. Who Is Affected? Sites that rely on the ZTUtils.SimpleTree. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Configuration file did not override security policy selection Issue Description This is not really a security issue, just a usability issue. It has always been possible to alternate between C and Python implemenations of the Zope security policy using certain environment variables. As of Zope 2.7, use of environment variables is deprecated in favor of the new 2.7 configuration files. The new configuration machinery was not implementing the directive used to override the default security policy. Who Is Affected? Zope 2.7 beta users. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher.
Brian -- Does this mean that Zope 2.6.3 is compatible with Python 2.3.3? I would be nice to retire 2.1.3. -dra On Thu, 8 Jan 2004, Brian Lloyd wrote:
Zope 2.6.3 Release and Security Update
Zope 2.6.3 contains a number of security related fixes for issues resolved during a comprehensive security audit conducted in Q4 2003. You may download Zope 2.6.3 from Zope.org:
[...]
On Thu, 2004-01-08 at 20:31, Dennis Allison wrote:
Does this mean that Zope 2.6.3 is compatible with Python 2.3.3? I would be nice to retire 2.1.3.
I'm not aware of any Zope Corp internal projects still using Python 2.1.3. I'm not aware of any serious incompatibilities. I suppose the only risk would be that fixing problems in Zope 2.6 specific to a Python version would have low priority because Zope 2.7 is on the horizon. Jeremy (not speaking for ZC)
Dennis Allison wrote:
Does this mean that Zope 2.6.3 is compatible with Python 2.3.3? I would be nice to retire 2.1.3.
A significant part of the effort for 2.6.3 (which was a backport from the original 2.7 work) lay in ensuring that the issues were fixed under all three Pythons (2.1.3, 2.2.3, 2.3.3). While we won't change the "officially supported" Python at this point in the 2.6 release cycle, you should know that our own projects have been running 2.6.x on 2.2.3 since at least June. After this effort, I have no reservations about recommending that those same customers begin evaluating the use of 2.3.3 for their 2.6-based Zope sites. In addition, we have a major support customer who *must* upgrade to Python 2.3.3, in order to allow Data.fs on Windows to grow beyond 2 Gb; they are not, however, ready to upgrade Zope (yet) to 2.7. We therefor have incentive to fix at least *major* issues related to running 2.6.3 under Python 2.3.3 (cosmetics are a different story, of course). Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
Glad to hear the news. I tried using Python 2.2 and 2.3 with Zope 2.6.2b3 with little success in the early Fall without success--but the many problems were RH9 related. We've since gone back to RH7.3 (the last stable RH release in my book) and used Python 2.1.3 for Zope (and Python 2.3.3 for everything else except RedHat tools). On Thu, 8 Jan 2004, Tres Seaver wrote:
Dennis Allison wrote:
Does this mean that Zope 2.6.3 is compatible with Python 2.3.3? I would be nice to retire 2.1.3.
A significant part of the effort for 2.6.3 (which was a backport from the original 2.7 work) lay in ensuring that the issues were fixed under all three Pythons (2.1.3, 2.2.3, 2.3.3). While we won't change the "officially supported" Python at this point in the 2.6 release cycle, you should know that our own projects have been running 2.6.x on 2.2.3 since at least June. After this effort, I have no reservations about recommending that those same customers begin evaluating the use of 2.3.3 for their 2.6-based Zope sites.
In addition, we have a major support customer who *must* upgrade to Python 2.3.3, in order to allow Data.fs on Windows to grow beyond 2 Gb; they are not, however, ready to upgrade Zope (yet) to 2.7. We therefor have incentive to fix at least *major* issues related to running 2.6.3 under Python 2.3.3 (cosmetics are a different story, of course).
Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
Dennis Allison wrote:
Glad to hear the news. I tried using Python 2.2 and 2.3 with Zope 2.6.2b3 with little success in the early Fall without success--but the many problems were RH9 related. We've since gone back to RH7.3 (the last stable RH release in my book) and used Python 2.1.3 for Zope (and Python 2.3.3 for everything else except RedHat tools).
RH9 has been rock solid for us, given two choices we made: - *Never*, *ever* run Zope in production with the OS's version of Python: it *won't* be built optimized for Zope, and it *will* change unexpectedly (from the perspective of the appserver developer). The SA will feel free to change the OS Python, including adding potentially destabilizing extensions, or *upgrading* it, and will be unrepentant when you (the appserver developer) complain that he broke your Zope. - *Run*, don't walk to get access to the updated kernel and glibc; the kernel, in particular, which RH9 installs out of the box is pathetically useless for running a memory-hungry appserver. We have found both yum and the apt-rpm port useful for keeping servers up to date. Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
Tried to do the former, but Python 2.3.1 would not build on RH9 with significant brain surgery. Updated RH9 to the bleeding edge and got things mostly working except for some subsystems adn supporting systems which use threading and would not work under the new threading model without significant rework. Hence the decision to revert to RH7.3. Eventually we plan to move to a Gentoo system--I've been experimenting with Gentoo and have found it to be fairly easy to construct a customized, fast, and clean system although the time-to-build can be daunting. After some more testing I plan to move to Gentoo for production, a move motivated by the bad experience I've had with RH9 and RedHat's new business focus on the enterprise. One point of information, Tres. Was your positive experience over a range of machines. We've pretty much standardized on dual processor Athlon machines, 4GB memories, and hardware raid controllers in a RAID-10 configuration. It's possible that our problems with RH9 may be tied to some problem with their Athlon SMP systems. Thanks for your comments and advise. On Thu, 8 Jan 2004, Tres Seaver wrote:
Dennis Allison wrote:
Glad to hear the news. I tried using Python 2.2 and 2.3 with Zope 2.6.2b3 with little success in the early Fall without success--but the many problems were RH9 related. We've since gone back to RH7.3 (the last stable RH release in my book) and used Python 2.1.3 for Zope (and Python 2.3.3 for everything else except RedHat tools).
RH9 has been rock solid for us, given two choices we made:
- *Never*, *ever* run Zope in production with the OS's version of Python: it *won't* be built optimized for Zope, and it *will* change unexpectedly (from the perspective of the appserver developer). The SA will feel free to change the OS Python, including adding potentially destabilizing extensions, or *upgrading* it, and will be unrepentant when you (the appserver developer) complain that he broke your Zope.
- *Run*, don't walk to get access to the updated kernel and glibc; the kernel, in particular, which RH9 installs out of the box is pathetically useless for running a memory-hungry appserver. We have found both yum and the apt-rpm port useful for keeping servers up to date.
Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Dennis Allison wrote:
Tried to do the former, but Python 2.3.1 would not build on RH9 with significant brain surgery. Updated RH9 to the bleeding edge and got things mostly working except for some subsystems adn supporting systems which use threading and would not work under the new threading model without significant rework. Hence the decision to revert to RH7.3. Eventually we plan to move to a Gentoo system--I've been experimenting with Gentoo and have found it to be fairly easy to construct a customized, fast, and clean system although the time-to-build can be daunting. After some more testing I plan to move to Gentoo for production, a move motivated by the bad experience I've had with RH9 and RedHat's new business focus on the enterprise.
I am tracking Whitebox Linux (http://www.whiteboxlinux.org) at the moment: it is a "rebuild-RHEL-3-from-SRPM-under-RH-trademark-policy" distro, which seems to have decent momentum (updates flow through quickly, for instance).
One point of information, Tres. Was your positive experience over a range of machines. We've pretty much standardized on dual processor Athlon machines, 4GB memories, and hardware raid controllers in a RAID-10 configuration. It's possible that our problems with RH9 may be tied to some problem with their Athlon SMP systems.
Hmm, good point; we are using Dell's datacenter-class boxen, which are all Intel hardware. Our experiences with Athlon-based boxes were less happy, even under 7.3: we attributed the problems to the fact that they were "homebrew" hardware, rather than to problems with RH Athlon kernels. Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
Tres Seaver wrote:
RH9 has been rock solid for us, given two choices we made:
- *Never*, *ever* run Zope in production with the OS's version of Python: it *won't* be built optimized for Zope,
Can you point us to an article or other doc source that talks about how to optimize python for Zope? TIA! Kirk -- Theorie ist, wenn man alles weiss und nichts klappt. Praxis ist, wenn alles klappt und keiner weiss warum. Bei uns sind Theorie und Praxis vereint: nichts klappt und keiner weiss warum!
RH9 has been rock solid for us, given two choices we made: - *Never*, *ever* run Zope in production with the OS's version of Python: it *won't* be built optimized for Zope,
Can you point us to an article or other doc source that talks about how to optimize python for Zope?
That was a bad choice of words. You don't "optimize Python for Zope". You just avoid the system binary because that has been tampered with in all kinds of weird ways to fit the distribution's own needs, so I guess you could call it "un-optimized". "Optimized" would the simple act of building your own python. jens
On Saturday 10 January 2004 08:47 am, Jens Vagelpohl wrote:
RH9 has been rock solid for us, given two choices we made: - *Never*, *ever* run Zope in production with the OS's version of Python: it *won't* be built optimized for Zope,
Can you point us to an article or other doc source that talks about how to optimize python for Zope?
That was a bad choice of words. You don't "optimize Python for Zope". You just avoid the system binary because that has been tampered with in all kinds of weird ways to fit the distribution's own needs, so I guess you could call it "un-optimized". "Optimized" would the simple act of building your own python.
jens
I have NEVER run into that problem with debian. I have been using zope for years with the default install of python on debian and it has worked without problems. Also when you use the dists version you can install other packages for it easier. I can do apt-get install python2.1-imaging and for many other extension types.
On Sat, 2004-01-10 at 17:57, kosh wrote:
I have NEVER run into that problem with debian. I have been using zope for years with the default install of python on debian and it has worked without problems. Also when you use the dists version you can install other packages for it easier. I can do apt-get install python2.1-imaging and for many other extension types.
I think Tres' point was really not that you can't use the system installed Python or that there *are* problems with any given default install of Python on any given distribution, it's just that a) nobody knows; it's too hard to keep track of... Red Hat patches Python in some fairly strange ways, for instance and b) when the sysadmin tasks are performed by someone who is not the developer, there's a potential for problems when the system Python gets upgraded. It's cheap to build your own Python, and makes a lot of sense in the context of trying to deploy many systems for production use. It's definitely possible to use the system-installed Python for Zope and might even make sense in a lot of cases but not for all. FWIW, on Debian, I've found that it's a pain in the ass to *build* Python because of weirdness with placement of libz.so (which Python requires in order to build the zlib library, which Zope in turn relies on to start), and I seem to also remember needing to play games with the readline libraries in order to have readline-capable interactive Python sessions. All that said, I'd rather solve all of those problems and use my own Python because I do codevelopment with people on different platforms. I'll usually build a set of "buildout" scripts that installs Python along with Zope and all the products I need. I do this because the buildout needs to work on BSD, Linux, Cygwin, and Solaris. It's a nobrainer in this case to *not* use the system installed Python. - C
On Saturday 10 January 2004 05:14 pm, Chris McDonough wrote:
On Sat, 2004-01-10 at 17:57, kosh wrote:
I have NEVER run into that problem with debian. I have been using zope for years with the default install of python on debian and it has worked without problems. Also when you use the dists version you can install other packages for it easier. I can do apt-get install python2.1-imaging and for many other extension types.
I think Tres' point was really not that you can't use the system installed Python or that there *are* problems with any given default install of Python on any given distribution, it's just that a) nobody knows; it's too hard to keep track of... Red Hat patches Python in some fairly strange ways, for instance and b) when the sysadmin tasks are performed by someone who is not the developer, there's a potential for problems when the system Python gets upgraded. It's cheap to build your own Python, and makes a lot of sense in the context of trying to deploy many systems for production use. It's definitely possible to use the system-installed Python for Zope and might even make sense in a lot of cases but not for all.
FWIW, on Debian, I've found that it's a pain in the ass to *build* Python because of weirdness with placement of libz.so (which Python requires in order to build the zlib library, which Zope in turn relies on to start), and I seem to also remember needing to play games with the readline libraries in order to have readline-capable interactive Python sessions. All that said, I'd rather solve all of those problems and use my own Python because I do codevelopment with people on different platforms. I'll usually build a set of "buildout" scripts that installs Python along with Zope and all the products I need. I do this because the buildout needs to work on BSD, Linux, Cygwin, and Solaris. It's a nobrainer in this case to *not* use the system installed Python.
- C
I find that when I build stuff myself it creates a lot more work since you have to remember every package you have built by hand and to rebuild it when there are exploits. If I keep everything in the package system then it will take care of the upates with far less time on my part. That is also why when I do stuff I choose dependencies for my software based on what is in the debian archives since the stuff in those archives is the easiest to install and keep updated over time and it also tends to have the most popular packages so you end up using a library that most systems probably have easily available. I do all of this for long term maintenance to make my life easier so I can spend more time doing devel and less time taking care of all of the upate stuff the system should be able to do for me.
On Sat, 2004-01-10 at 19:28, kosh wrote:
I find that when I build stuff myself it creates a lot more work since you have to remember every package you have built by hand and to rebuild it when there are exploits. If I keep everything in the package system then it will take care of the upates with far less time on my part.
Yeah, I don't blame you. I don't do the same, mainly out of fear and having been burned this way before, but if it works for you, congrats.
Kirk Lowery wrote:
Tres Seaver wrote:
RH9 has been rock solid for us, given two choices we made:
- *Never*, *ever* run Zope in production with the OS's version of Python: it *won't* be built optimized for Zope,
Can you point us to an article or other doc source that talks about how to optimize python for Zope?
Since Python 2.2 (I think), a "stock" Python build is fine, at least on modern Linuces: threads and large file support are configured in by default (I think FreeBSD still needs a patch to bump stack size). Red Hat's packaged version of Python, however, does several odd things: - It is configured with '--enable-unicode=ucs4', which is OK for scripting, but suboptimal for long-running processes (unless the dominant charset for your site maps better onto 4 bytes). - It splits out critical include files, headers, and tools into separate -devel and -tools pacakges, which aren't installed by default. Building extensions is therefore harder, because you have to get 'python-devel' installed first, and pydoc is missing (good luck figuring out where it should be, if you don't already know to look in python-tools!) - They are typically "behind" the versions which contain fixes for bugs which are particularly noxious for a long-running process like Zope. Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
I have to agree with the recommendations of never running Zope with the OS Python. In fact, I usually don't even get it to work, since the OS Python have a tendency to not include modules included in the standard Python distribution, or behave weridly in some other way. For example, OpenBSD's standard binary Python used to barf on py files with Windows line endings, a big problem if you run a mixed environment. As to discussions in what OS to run, I can only say: OpenBSD. Very secure, dead easy to install and a very nice "source code" package delivery system in addition to the binary package distributions, removing the need to wait for the package to be recompiled by the package manager for your version of OpenBSD. Happily and securely runs several Zope servers even on old puny machines. :-) It doesn't work well as a client though, but as a server, I have yet to find anything to beat it. Well, maybe VMS was slightly better. :-) //Lennart
On Friday 09 January 2004 03:23 am, Lennart Regebro wrote:
I have to agree with the recommendations of never running Zope with the OS Python. In fact, I usually don't even get it to work, since the OS Python have a tendency to not include modules included in the standard Python distribution, or behave weridly in some other way. For example, OpenBSD's standard binary Python used to barf on py files with Windows line endings, a big problem if you run a mixed environment.
Actually I disagree. I run debian sid systems and I use the os python for zope. I have never had a problem with it and it saves me a huge ammount of headaches since any updates for security etc get automatically applied when I do updates. I use the debian install of zope also so everything is in the dependency system. This has not caused me to run into any strange problems and debian for a long while now has had multiple versions of python available so zope just uses has whichever one it needs as a dependency. It just seems to work very well and it saves me a lot of time. I have also not had a zope crash in about 2 years now even when doing product developmet under zope by just following the version of zope that is in debian sid which usually lags behind a new zope release by a few days.
From: "kosh" <kosh@aesaeion.com>
Actually I disagree. I run debian sid systems and I use the os python for zope. I have never had a problem with it and it saves me a huge ammount of headaches since any updates for security etc get automatically applied when I do updates. I use the debian install of zope also so everything is in the dependency system.
That probably does work. However, on my Debian, I can't even run the Zope setup on a source code distribution, because for some reason, the Debian binary distribution of Python does not include distutils! Why? I don't know. Can I fix it? Maybe, but I don't know how. Compiling python from the source is trivial and works, so that's what I end up doing anyway.
On Friday 09 January à 14:45, Lennart Regebro wrote:
From: "kosh" <kosh@aesaeion.com>
Actually I disagree. I run debian sid systems and I use the os python for zope. I have never had a problem with it and it saves me a huge ammount of headaches since any updates for security etc get automatically applied when I do updates. I use the debian install of zope also so everything is in the dependency system.
That probably does work. However, on my Debian, I can't even run the Zope setup on a source code distribution, because for some reason, the Debian binary distribution of Python does not include distutils! Why? I don't know. Can I fix it? Maybe, but I don't know how.
apt-get install python-dev -- Sylvain Thénault LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org
Brian Lloyd wrote:
Zope 2.6.3 Release and Security Update
Good to hear. Have these changes been merged into HEAD yet? -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer
So I am a little hazy on how one upgrades from 2.6.1 or .2 to 2.6.3. I don't see any obvious notes on upgrading linked from the download pages or in the doc directory of the distributed tar ball - nor in the install or maintenance chapters of the Zope book. I have installed from source and have separate directories for SOFTWARE_HOME and my INSTANCE_HOME. Do I just install the new one in an appropriate location, change the environment variable in my run script, and restart the server? Seems like there might be more to it than that - unless there were no changes to the object model so the database would not have to change as a result of these fixes. And what is a HotFix? I kind of infer that that is what the 2.6.1-to-2.6.2 file is for. Do I need to do ???? with that to migrate my 2.6.1 site to 2.6.2 before heading on to 2.6.3? Or are hot fixes irrelevant if I have servers that I can restart at will because I don't have that much data and can restart quickly? Thanks in advance, Cynthia
Cynthia Kiser wrote at 2004-1-8 23:26 -0800:
... I have installed from source and have separate directories for SOFTWARE_HOME and my INSTANCE_HOME.
That's very good.
Do I just install the new one in an appropriate location, change the environment variable in my run script, and restart the server?
Precisely -- when you install from a binary release. When you start with a source release, you must generate the C extensions after installation.
.... And what is a HotFix?
A special (Zope) product that modifies classes dynamically on (every) Zope start. If a hotfix can do the job, you do not need a new version. -- Dieter
Quoting Dieter Maurer <dieter@handshake.de>:
Do I just install the new one in an appropriate location, change the environment variable in my run script, and restart the server?
Precisely -- when you install from a binary release.
When you start with a source release, you must generate the C extensions after installation.
How do I generate C extensions? Is that what happens when I run the wo_pcgi.py script? or is there something extra that one does when upgrading that is different from installing? If so, where do I find instructions - at the level of "what do I type on the command line" - for upgrades? Thanks, -- Cynthia Kiser
Cynthia Kiser wrote at 2004-1-9 14:53 -0800:
Quoting Dieter Maurer <dieter@handshake.de>:
Do I just install the new one in an appropriate location, change the environment variable in my run script, and restart the server?
Precisely -- when you install from a binary release.
When you start with a source release, you must generate the C extensions after installation.
How do I generate C extensions? Is that what happens when I run the wo_pcgi.py script?
Precisely. -- Dieter
Are there any special things I should take into account when upgrading from 2.6.2 to 2.6.3? The reason I ask this is that when I just upgraded the roles stopped working in Plone. Not even the owner (or the manager) could view his/her own objects if they were set to private. When I downgraded to 2.6.2 the problem disappeared. I'm not using the Verbose Security product. -Petter-
participants (15)
-
Brian Lloyd -
Chris McDonough -
Cynthia Kiser -
Dennis Allison -
Dieter Maurer -
Jamie Heilman -
Jens Vagelpohl -
Jeremy Hylton -
John J Lee -
Kirk Lowery -
kosh -
Lennart Regebro -
Petter Holmström -
Sylvain Thénault -
Tres Seaver