[Zope-Checkins] SVN: Zope/trunk/inst/versions.py 2.12.0a1 is the next target version
Log message for revision 94850: 2.12.0a1 is the next target version Changed: U Zope/trunk/inst/versions.py -=- Modified: Zope/trunk/inst/versions.py === --- Zope/trunk/inst/versions.py 2009-01-19 17:16:59 UTC (rev 94849) +++ Zope/trunk/inst/versions.py 2009-01-19 17:28:08 UTC (rev 94850) @@ -1,7 +1,7 @@ -ZOPE_MAJOR_VERSION = '2.11' +ZOPE_MAJOR_VERSION = '2.12' ZOPE_MINOR_VERSION = '0' ZOPE_BRANCH_NAME= '$Name$'[6:] or 'no-branch' # always start prerelease branches with '0' to avoid upgrade # issues in RPMs -VERSION_RELEASE_TAG = 'a1' +VERSION_RELEASE_TAG = 'a1-unreleased' ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
Re: [Zope-dev] [Zope-tests] UNKNOWN : Zope[2.buildout]-trunk Python-2.5.2 : Linux
Enough! I have put a copy of docutils-0.4.tar.gz on the test server and point buildout at it via ~/.buildout/default.cfg. Stefan On 19.01.2009, at 02:55, Zope Tests wrote: Zope Tests : UNKNOWN Zope[2.buildout]-trunk Python-2.5.2 : Linux Running /usr/local/python2.5/bin/python ./bin/test --all /usr/local/python2.5/bin/python: can't open file './bin/test': [Errno 2] No such file or directory UNKNOWN [snip] Getting distribution for 'docutils==0.4'. While: Installing test. Getting distribution for 'docutils==0.4'. Error: Can't download http://prdownloads.sourceforge.net/docutils/docutils-0.4.tar.gz?download : 404 Not Found ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 7 OK, 1 Unknown
Summary of messages to the zope-tests list. Period Sun Jan 18 12:00:00 2009 UTC to Mon Jan 19 12:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Unknown --- Subject: UNKNOWN : Zope[2.buildout]-trunk Python-2.5.2 : Linux From: Zope Tests Date: Sun Jan 18 20:55:42 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010886.html Tests passed OK --- Subject: OK : Zope-2.8 Python-2.3.7 : Linux From: Zope Tests Date: Sun Jan 18 20:45:10 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010879.html Subject: OK : Zope-2.9 Python-2.4.5 : Linux From: Zope Tests Date: Sun Jan 18 20:46:40 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010880.html Subject: OK : Zope-2.10 Python-2.4.5 : Linux From: Zope Tests Date: Sun Jan 18 20:48:11 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010881.html Subject: OK : Zope-2.11 Python-2.4.5 : Linux From: Zope Tests Date: Sun Jan 18 20:49:41 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010882.html Subject: OK : Zope-trunk Python-2.4.5 : Linux From: Zope Tests Date: Sun Jan 18 20:51:11 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010883.html Subject: OK : Zope-trunk Python-2.5.2 : Linux From: Zope Tests Date: Sun Jan 18 20:52:41 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010884.html Subject: OK : Zope[2.buildout]-trunk Python-2.4.5 : Linux From: Zope Tests Date: Sun Jan 18 20:54:11 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010885.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Release zc.selenium on pypi
On 2009-01-07 14:32:07 +0100, Benji York be...@zope.com said: On Wed, Jan 7, 2009 at 7:29 AM, Christian Zagrodnick c...@gocept.com wrote: there is zc.selenium on svn.zope.org which is not on pypi. Could this be released? Yes. Also it speaks of the ZVLS in some files which doesn't seem to be correct. It's not correct. They should all be ZPL. Just released 1.1.0 and added you as owner. -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-tests] UNKNOWN : Zope[2.buildout]-trunk Python-2.5.2 : Linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan H. Holek wrote: Enough! I have put a copy of docutils-0.4.tar.gz on the test server and point buildout at it via ~/.buildout/default.cfg. Thanks! Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJdIqB+gerLs4ltQ4RAjvyAJ9KM9QfJMNGdWCWqxYtvcMxsfCeNwCfZxfo QHydoPBanfpLt1yrrRFuZsQ= =Y6/X -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
Hi there, Oh joy, a naming discussion. :) A namespace isn't a framework. Be careful we don't start pretending that the zope.* namespace is a framework. If you start judging which packages belong in the zope.* namespace and which are not, what standards are really being used? The only standard I've seen in this thread was something about the elder Zope gods writing into stone what shall go into zope.* and what shall not. I don't think that's a sensible position for a framework that's supposed to be evolving. Or isn't it? The Zope 3 framework isn't all zope.* packages. It's a selection made carefully by developers of the framework that can be installed as a whole. Okay, scratch that, as Zope 3 is a bad example of this for some reason. I'm not sure that's a good thing; a framework without people who decide what goes into it? How does one install Zope 3? It works for Grok though: The Grok framework is a bunch of zope.*, grokcore.*, z3c.*, zc.* and packages, and other packages to boot, integrated together that can be installed as a whole. The Grok development team determines what's part of a core Grok installation. It also works for Zope 2. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
Andreas Jung wrote: On 17.01.2009 8:39 Uhr, Dieter Maurer wrote: [snip] It is good to be able to access both site and request in a standard way. And it similiar accessing the current transaction using import transaction tx = transaction.get() So: +1 +1 too. For Zope 2 and for Zope 3. In some cases it's really hard to get to the request otherwise. Take a look at zc.resourcelibrary for a Zope 3 library that could use zope.globalrequest. Right now it doesn't use an abstraction but just cheats by knowing the implementation. Or hurry.zoperesource, which uses the same pattern. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
Hi there, Roger Ineichen wrote: [snip] Why should someone use a global request if he has a request available? This package does nothing else then offer a request if non is available. And if you need a request if non is available there is something wrong with the application design. Or better let's say it's another pattern then we use in zope 3 right now. I don't think that's always true. Let me give you an example. I wrote a library called hurry.resource. This library is framework neutral. You can define a javascript or css resource and express that you need it to be included in the page in a certain code path: yui.datatable.need() I also have a library called hurry.zoperesource. This library provides integration of hurry.resource with Zope 3. When need() is called in a Zope 3 context, I need the request object as I chose the request object as the place to store the list of resources that are needed. So I need to get the request without having it. You could argue my library isn't designed right, and that instead I should require people to pass 'request' to the .need() method. But since hurry.resource is framework-neutral, what request should that be? And in a system like Pylons it makes no sense to have to pass in the request, as it's available globally everywhere. It only seems to put an implementation detail into the API. Besides the framework neutralness argument, which you can argue makes no sense, I think it's simply a nicer API to say '.need()' instead of having to pass the request. That's a weaker argument, however. That said, zc.resourcelibrary does the same strategy, as that's where I took it from. Anyway, I do believe there are cases of APIs that need the request internally but want to abstract it away as an implementation detail. I guess I might've been able to use the interaction directly in Zope 3's case and I shall study that. There are of course drawbacks (as mentioned) with testing and such when taking this approach. But I think one can make a reasonable case for such an API nonetheless, when used in moderation. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
On Sun, 18 Jan 2009 20:29:40 +0100 Dieter Maurer die...@handshake.de wrote: Tres Seaver wrote at 2009-1-18 11:38 -0500: ... I don't actually know how this package fits in with either Z2 or Z3: Z2 apps are always able to acquire the request, This is not the case for localsitemanager delivered local utilities and we therefore have had several problems. while Z3 apps use the separation of concerns pattern I just outlined. Nobody forces you to go this route. I've never wanted a 'get_request' method in production code: I would consider the need for it a sign that something in the application is factored wrongly. You could use the same arguments with respect to the global site ;-) But few people in Zope 3 land separate site dependent and site independent code despite some cases where the global site does make problems. Using the 'reversal of dependency' (not sure whether this is the accurate English term) you always end up with a few general concepts that act as mediators. Sites are badly named 'component registries' and are part of the central zope.component module which acts as the general plug-in point, thus the dependency. The ZCA is intended to be depended on and activating registries is a part of that. The comparison of a component registry versus a request does not hold IMHO. Depending on a request is generally not good and most people in this thread acknowledged this, pointing out that they still want the flexibility. I'd be happy with a reasonable documentation pointing out that accessing a request from anywhere is definitely not intended to be turned into an *everywhere* but needs careful though. For me, if my apps domain logic can't be used in `bin/zopectl debug` (or run) without faking a request, they're broken. Christian -- Christian Theune · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Salt-weakness in zope.app.authentication passwordmanagers?
Hi there, Uli Fouquet wrote: I'd be glad to provide a fix for this, but I am undecided how we could support administrators best to upgrade their password bases. I'm speaking here mostly from a position of ignorance of these affairs, but is it possible to upgrade the current passwords to a more secure version without knowing those passwords? Currently, three (not mutual exclusive) approaches come to my mind: 1) the fixed password managers could be registered under different names. Support of the old ones could slowly run out and users could be warned, if they still use the old password managers. If we were to fix the old password managers, would the old passwords break? If not, that would at least provide better security for newly stored passwords right away without having to change applications. The old password managers then could be used as a fallback. This would weaken security (as two different hashes would allow one to authenticate with the same password), but not very much (you get a chance of 2:8**20 instead of 1:8**20 in worst case). If it's not possible to update the existing password managers to the new behavior a new name + fallback sounds like the best way to go. Paranoid folks should be able to disable the fallback and expect complaints from their users. Default policy might be to disable fallback. Possibly simply register 2 new names then, one without fallback and one with. 2) A commandline tool should be available, that can at least get old (encrypted) passwords and tell how they look hashed proper. Administrators had to take care for storing them in site.zcml, their LDAP or wherever they store passwords. Why a commandline tool? Wouldn't it be better to just have an API to help upgrade passwords? 3) A commandline tool could also update existing ZCML files. This might fix the problems for most users. I don't think that would fix it for most users. In fact I think those few hashes that are stored in ZCML are not a great security risk; if malicious people can read those the risk to the application is far greater already. The risk is bigger for larger password databases that fall into the wrong hands, as far as I understand it. There might be smarter approaches. Any hints are very welcome. The most important part I think is to document well what people should be doing. I.e. use the new password managers (or tell them to upgrade and their old ones will be fine), and how they should go about upgrading existing passwords. I think we should ask people to write their own upgrade code as we do not know where these passwords are stored. I'm storing them in a relational database in some cases, for instance. We could provide upgrade code for some common scenarios, but I'd be fine if we had a good document with instructions instead. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
On Monday 19 January 2009, Christian Theune wrote: Using the 'reversal of dependency' (not sure whether this is the accurate English term) I think it is called dependency injection. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Salt-weakness in zope.app.authentication passwordmanagers?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Hi there, Uli Fouquet wrote: I'd be glad to provide a fix for this, but I am undecided how we could support administrators best to upgrade their password bases. I'm speaking here mostly from a position of ignorance of these affairs, but is it possible to upgrade the current passwords to a more secure version without knowing those passwords? If that is possible, then we have a worse problem on hand. :) Passwords aren't meant to be stored in a reversible / recoverable manner. Currently, three (not mutual exclusive) approaches come to my mind: 1) the fixed password managers could be registered under different names. Support of the old ones could slowly run out and users could be warned, if they still use the old password managers. If we were to fix the old password managers, would the old passwords break? If not, that would at least provide better security for newly stored passwords right away without having to change applications. In a PAS environment, the way to do this is to add a new authentication plugin, which imposes the new scheme, and be williing to fall back to the old one. You also need to replace the plugin which is responsible for the update credentials bit, so that when the user updates her password, it gets stored in the new way. Finally, the admin might want to ask all users to change passwords in order to clear out the weaker set. There isn't going to be any easy way to automate this kind of upgrade. The old password managers then could be used as a fallback. This would weaken security (as two different hashes would allow one to authenticate with the same password), but not very much (you get a chance of 2:8**20 instead of 1:8**20 in worst case). If it's not possible to update the existing password managers to the new behavior a new name + fallback sounds like the best way to go. Paranoid folks should be able to disable the fallback and expect complaints from their users. Default policy might be to disable fallback. Possibly simply register 2 new names then, one without fallback and one with. 2) A commandline tool should be available, that can at least get old (encrypted) passwords and tell how they look hashed proper. Administrators had to take care for storing them in site.zcml, their LDAP or wherever they store passwords. Why a commandline tool? Wouldn't it be better to just have an API to help upgrade passwords? 3) A commandline tool could also update existing ZCML files. This might fix the problems for most users. I don't think that would fix it for most users. In fact I think those few hashes that are stored in ZCML are not a great security risk; if malicious people can read those the risk to the application is far greater already. The risk is bigger for larger password databases that fall into the wrong hands, as far as I understand it. An attacker who can get to your password database is already well past our ordinary security measures: given filesystem access, he can steal, or even modify, any of the data those passwords are aimed at protecting. Because many users reuse passwords across systems, there is a second-order effect: being able to crack the Phred's password on one system might give access to Phred's accounts on *other* systems. Making the hash stronger really only defends against this second-order attack. There might be smarter approaches. Any hints are very welcome. The most important part I think is to document well what people should be doing. I.e. use the new password managers (or tell them to upgrade and their old ones will be fine), and how they should go about upgrading existing passwords. I think we should ask people to write their own upgrade code as we do not know where these passwords are stored. I'm storing them in a relational database in some cases, for instance. We could provide upgrade code for some common scenarios, but I'd be fine if we had a good document with instructions instead. Agreed: no general solution seems possible. I wouldn't suggest anything more than a code snippet: anything shipped as actual software is likely to be an attractive nuisance. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJdLje+gerLs4ltQ4RAhEvAJ4gmbqOegwWs/nnshG2ZdXI07AzwQCfQaD7 cSN7/TxRxXTjuYwiuUROaxE= =CpNh -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists -
Re: [Zope-dev] zope.globalrequest?
On Mon, 19 Jan 2009 09:24:09 -0800 Stephan Richter srich...@cosmos.phy.tufts.edu wrote: On Monday 19 January 2009, Christian Theune wrote: Using the 'reversal of dependency' (not sure whether this is the accurate English term) I think it is called dependency injection. Thanks. Now, that you mention it ... Christian -- Christian Theune · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: On Monday 19 January 2009, Christian Theune wrote: Using the 'reversal of dependency' (not sure whether this is the accurate English term) I think it is called dependency injection. I think maybe inversion is the term desired.. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJdNbR+gerLs4ltQ4RAl5CAKCH7xJXGKqHVEUG9WMcsWyHwtnlXwCgz9Pd rQO99ttrtgb/WulLn375YaA= =issy -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
On Mon, Jan 19, 2009 at 09:24:09AM -0800, Stephan Richter wrote: On Monday 19 January 2009, Christian Theune wrote: Using the 'reversal of dependency' (not sure whether this is the accurate English term) I think it is called dependency injection. There's the Dependency Inversion Principle (DIP), which says that high-level modules shouldn't depend on low-level modules; instead they both should depend on an abstraction. - http://en.wikipedia.org/wiki/Dependency_inversion_principle And then there's the Dependency Injection Pattern, which is, I suppose, an implementation of the DIP, where classes don't instantiate their dependencies directly, and instead expect the client to supply them. - http://en.wikipedia.org/wiki/Dependency_injection Then there's also Inversion of Control, which is a principle advocating framework-ish behaviour (you supply callbacks, we call them when we want) over library-ish behaviour (we supply utilities, you call them when you want), and could be called an abstract principle behind both DIP and DI -- http://en.wikipedia.org/wiki/Inversion_of_control Oh dear, now I'm confused. ;-) Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope] ztp and dollars-and-cents
2009/1/15 Tres Seaver tsea...@palladion.com -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Miguel Beltran R. wrote: dtml-var have dollars-and-cents to made show numbers this way 0,000,000.00 exist something to do the same with zpt tal:content ? You can use the same function, because it is imported into a safe for import by untrusted code module (Products.PythonScripts.standard). E.g.: p tal:define=std modules/Products/PythonScripts/standard; tal:content=python: std.dollars_and_cents(value)1.00/p Thanks. I just modify to python: 'strong' + std.thousands_commas(std.dollars_and_cents(item.saldo))+ '/strong' and work excellent ___ 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 )
