Re: [Zope3-dev] Zope 3.4, eggs and windows
On 4/21/07, Martijn Faassen <[EMAIL PROTECTED]> wrote: It is therefore important that binary Windows eggs are indeed available for the appropriate Zope 3 and ZODB packages. Is there a plan for providing these? I'm hoping Sidnei will pop up and say, oh, yeah, all taken care of. :) Jim has been building eggs for Windows himself. So, yeah, all taken care of I guess. :) -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Zope 3.4, eggs and windows
Hi there, I have some questions about the Zope 3.4 release. My apologies if this information is already available somewhere else. I've just uploaded z3c.widget to download.zope.org/distribution, but ran into a new snag: it properly lists a whole bunch of dependencies in its setup.py that are currently Zope core packages, and thus post-3.3. I'm still developing against Zope 3.3 and using z3c.widget would therefore lead to a mix of Zope 3.3 and post 3.3 (3.4) packages in my installation. It's like to avoid this. Is there is a way to suppress the automatic download of dependencies for a particular egg in buildout? A manual hack is to upload a private version of z3c.widget somewhere that has a different dependency list and then refer to that. Instead of hacking, I could also decide to start relying on an eggified Zope 3.4 right away. I've heard some discussion though that makes me wonder whether an eggified release of Zope 3.4 will be fully cooked. This leads to some questions: * I don't believe the 3.4 alpha eggs have been uploaded anywhere yet, right? * my application needs to run on Windows as well as Linux. This is one of the reasons using an eggified Zope 3 is in fact attractive, as *if* there are Windows eggs available, everything should work all right on Windows automatically. It is therefore important that binary Windows eggs are indeed available for the appropriate Zope 3 and ZODB packages. Is there a plan for providing these? I'm hoping Sidnei will pop up and say, oh, yeah, all taken care of. :) Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Autoconfiguring a site.zcml
Hello, Tres Seaver wrote: David Pratt wrote: On the basis that eggs spell out dependencies, I am thinking the inclusion of packages and their dependencies should be enough to dictate the sequence of inclusion for package configuration (and creation of the site.zcml) for the app buidout recipe. This could be a option to the current manual configuration. - -1. Configuration is *policy*; implicitly wiring in the default configuration for every egg on the path is not going to be an acceptable default. In the path? David didn't say in the path, did we? What about in the buildout? Since my buildout already says explicitly it wants egg foo, and egg foo needs egg bar, it is a major pain to have to specify the ZCML for bar manually. I don't think something being policy means it's automatically a bad candidate for automation. Information about the policy may after all be elsewhere in the system, for instance in a buildout.cfg. Presumably, the reason folks would use this recipe is to configure one or more of the same app. I know attempting to do this manually is prone to errors if packages are not in the correct sequence or if you miss the configuration of a package. Any thoughts on this. Many thanks. Not necessarily. There are really two kinds of packages in play here: "libraryish" packages, which supply mechanisms, and "applicationish" packages, which use the mechanism according to some policy. I would argue that the only things you can safely auto-include would be the 'meta.zcml', because it is policy-free. Reusable packages need to avoid imposing policy (they may *suggest* it, but they shouldn't insist). That's where we have the concept of overridable defaults. So the default should be to follow the suggestions, and there should be an option in the system to override this suggestion. I would cheer if somebody proposed writing a UI which introspcts packgaes for such suggestions, and allows the site manager to merge / override them to create an appropriate 'site.zcml'. Until then, I don't want package authors dictating to site managers. Who are these ZCML-using site managers you are speaking of? Anyway, are you saying you want some form of ZCML UI to be created before *any* automation can be implemented? Asking for the creation of a UI on the Zope 3 mailing list is paramount to waiting forever... If you never automate policy, you'll be writing a lot of stuff by hand. That may be fine for you, but I myself would prefer to write less boring code and focus on more interesting problems. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: z3c.widget(.tiny) widget available to easy_install anywhere?
Christian Theune wrote: Am Samstag, den 21.04.2007, 19:12 +0200 schrieb Martijn Faassen: Hey, Anyone, can I conclude that z3c.widget is not available anywhere? Who would like to upload a version? Can I help? Where shall we upload it? You should be able to make an sdist and scp it to download.zope.org:/distribution/ Just in case you don't want to register it with cheeseshop yourself. When I'm in that situation I either talk to the maintainer offering them help to get it on PyPI or, if I have time pressure, just make a snapshot release to download.zope.org Yeah, I was about to do the latter and just came back to the thread to make sure nothing new appeared. :) Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Autoconfiguring a site.zcml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Pratt wrote: > On the basis that eggs spell out dependencies, I am thinking the > inclusion of packages and their dependencies should be enough to dictate > the sequence of inclusion for package configuration (and creation of the > site.zcml) for the app buidout recipe. This could be a option to the > current manual configuration. - -1. Configuration is *policy*; implicitly wiring in the default configuration for every egg on the path is not going to be an acceptable default. > Presumably, the reason folks would use this recipe is to configure one > or more of the same app. I know attempting to do this manually is prone > to errors if packages are not in the correct sequence or if you miss the > configuration of a package. Any thoughts on this. Many thanks. Not necessarily. There are really two kinds of packages in play here: "libraryish" packages, which supply mechanisms, and "applicationish" packages, which use the mechanism according to some policy. I would argue that the only things you can safely auto-include would be the 'meta.zcml', because it is policy-free. Reusable packages need to avoid imposing policy (they may *suggest* it, but they shouldn't insist). I would cheer if somebody proposed writing a UI which introspcts packgaes for such suggestions, and allows the site manager to merge / override them to create an appropriate 'site.zcml'. Until then, I don't want package authors dictating to site managers. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGKk8D+gerLs4ltQ4RAs+UAJwLA3ek+JiOq0uRsngZlNCE7IwG8ACg3B5k Y+XVfMoyN+cJhLE70j2b638= =aLQy -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: z3c.widget(.tiny) widget available to easy_install anywhere?
Am Samstag, den 21.04.2007, 19:12 +0200 schrieb Martijn Faassen: > Hey, > > Anyone, can I conclude that z3c.widget is not available anywhere? Who > would like to upload a version? Can I help? Where shall we upload it? You should be able to make an sdist and scp it to download.zope.org:/distribution/ Just in case you don't want to register it with cheeseshop yourself. When I'm in that situation I either talk to the maintainer offering them help to get it on PyPI or, if I have time pressure, just make a snapshot release to download.zope.org Christian -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] WebDAV Future
Hi All, I want to move the webdav implementation on by releasing it to cheeseshop, supporting more content types and then working on some more interesting aspects of the protocol itself, and maybe even supporting other applications like Plone if there is interest. First I need to rename it out of the zope namespace, which was a mistake on my part in calling it this. But this brings up some packaging issues for me that I am not sure how best to do this in a consistent fashion that I can build on. Hence why I have delayed doing anything about this. Currently everything is in zope.webdav. Which includes support for the zope.app.file & zope.app.folder content types. Using zope.locking as a locking mechanism and using zope.copypastemove for copying and moving content. Each of the packages just mentioned should be optional (but aren't because of the current setup, which I want to fix). Now into future. I want to split this up into a core Zope3 WebDAV implementation, which will handle registering the different WebDAV methods, their implementation, declaring properties, exception handing which I could call z3c.webdav. This module / egg on it own will be pretty useless, as it doesn't know about any of the content or services in Zope3. Then I want for each content type and services in Zope its own egg so to speak, for example z3c.webdav.zopeappfolder, z3c.webdav.zopeappfile, z3c.webdav.zopefile, z3c.webdav.zopelocking. A lot of these extra eggs will be small and easy to write, and as more content types are supported by Zope3 I would like more webdav modules to be written for them. An other two options I can think of, instead of the naming convention above: 1. create a webdav namespace, webdaz (WebDAv for Zope), which would contain webdaz.core, webdaz.zopefile, webdaz.zopelocking etc 2. Name the core webdav implementation z3c.webdav and then create eggs that are named like zope.file.webdav (for zope.file), zope.app.file.webdav, z3c.extfile.webdav, zope.locking.webdav etc. but which are separate from the underlying module. Does any one have any experience with this type of problem or does any one of a preference to which one they like best. Or is there other options that I have missed that is worth considering, in order for me to move this forward. Thanks, Michael P.S. after writing all this down my preference is moving towards the last zope.file.webdav, etc. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: z3c.widget(.tiny) widget available to easy_install anywhere?
Hey, Anyone, can I conclude that z3c.widget is not available anywhere? Who would like to upload a version? Can I help? Where shall we upload it? Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Bug 98024] Re: Add big files
On Apr 21, 2007, at 11:47 AM, Christian Theune wrote: Hi, (moving it to zope3-dev for discussion) Am Samstag, den 21.04.2007, 13:50 + schrieb Jim Fulton: On Apr 21, 2007, at 9:24 AM, Christian Theune wrote: *sigh* This is a can of worms. It looks like email.FeedParser.FeedParser is probably what we want to use. Why? Ah. I was working on the integration of Blobs in Zope 3 and noticed that we should try harder at some points to allow a more time-efficient handling of large data. As soon as a file is available as a NamedTemporaryFile today, a Blob can consume them doing a rename which works in O(1). Only if it is on the same file system. Of course, if not, it is no worse than the current situation. The only remaining issue is during the upload of large data via HTTP. What happens there is that the upload is first streamed to a temporary file in the server and then handed over to the publisher. The publisher then parses the mime data and creates new files. This takes up the application thread for a task that doesn't require application resources, so this could be done before handing the request into the publisher. For files of about 50 MB this already takes 5-10 seconds, eventually slower, depending on the machine. You likely don't want to use the select-lope thread (aka reactor thread) for this either. Trying to improve this is likely to involve a tricky thread dance. Typically, the upload speed is relatively slow compared to the CPU time required to unpack the mime data. IMHO we can make good use of that time by unpacking it as early as possible. I don't understand this. While uploads are occurring, select threads and application threads can be doing other work. To avoid blocking, the server could feed the body into something like the feedparser while getting the data from the client. The publisher then can build on what was parsed already. That's a huge change and one I'm dubious of without some additional thread gymnastics. I think there are simpler alternatives, although they to require a different thread-management strategy to get what I think you want. Dieter Maurer earlier pointed out an alternative (that would actually work with the current cgi module): just introduce a new thread that pre-processes the request before handing it into the publisher. Right. I also think we could adjust thread management in other ways to provide better application control. For example, I suspect that something interesting could be done at the publication layer. There are really two different sets of resources: 1. Threads 2. "application resources" such as database conections. Historically, we've limited application resources by limiting threads. We could decouple these, allowing more threads, but making threads queue up to get application resources. That way we can free up the application threads for smaller requests to go through in between. However, the user would still see the lag after uploading. It's not clear to me that the user would see any longer delay with this strategy, although the strategy would need to be fleshed out more to be sure. And the Python guys have been talking about getting rid of cgi.FieldStorage in it's current implementation since 2005 but nothing has happened. :( Some issues that would be nice as a preparation: - make a cleaner alternative interface as a replacement for FieldStorage Could you describe the problems you percieve with FieldStorage. I'm not necessarily opposed to a change, but you need to present the technical reasons. I'm trying hard, but it takes a lot of time to understand what's happening there. The public interface is badly underdocumented and a lot of implicit behaviour is happening all over the place. I find it unmaintainable - and as I'd like to adjust it to my needs, I feel like rewriting would be better. I'm not so sure about the implicit part. I agree it's complex. Unfortunately, a lot of that complexity is essential so it's unattractive to do it over since it works. Of course, better tests would help a lot. ... Hmm. I assume you're pointing out it's hairy but it works so nobody really got down to it. I see that when reading through various old discussions on the lists too. Yup Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Bug 98024] Re: Add big files
Hi, (moving it to zope3-dev for discussion) Am Samstag, den 21.04.2007, 13:50 + schrieb Jim Fulton: > On Apr 21, 2007, at 9:24 AM, Christian Theune wrote: > > > *sigh* > > > > This is a can of worms. It looks like email.FeedParser.FeedParser is > > probably what we want to use. > > Why? Ah. I was working on the integration of Blobs in Zope 3 and noticed that we should try harder at some points to allow a more time-efficient handling of large data. As soon as a file is available as a NamedTemporaryFile today, a Blob can consume them doing a rename which works in O(1). The only remaining issue is during the upload of large data via HTTP. What happens there is that the upload is first streamed to a temporary file in the server and then handed over to the publisher. The publisher then parses the mime data and creates new files. This takes up the application thread for a task that doesn't require application resources, so this could be done before handing the request into the publisher. For files of about 50 MB this already takes 5-10 seconds, eventually slower, depending on the machine. Typically, the upload speed is relatively slow compared to the CPU time required to unpack the mime data. IMHO we can make good use of that time by unpacking it as early as possible. To avoid blocking, the server could feed the body into something like the feedparser while getting the data from the client. The publisher then can build on what was parsed already. Dieter Maurer earlier pointed out an alternative (that would actually work with the current cgi module): just introduce a new thread that pre-processes the request before handing it into the publisher. That way we can free up the application threads for smaller requests to go through in between. However, the user would still see the lag after uploading. > > And the Python guys have been talking > > about getting rid of cgi.FieldStorage in it's current implementation > > since 2005 but nothing has happened. :( > > > > Some issues that would be nice as a preparation: > > > > - make a cleaner alternative interface as a replacement for > > FieldStorage > > Could you describe the problems you percieve with FieldStorage. I'm > not necessarily opposed to a change, but you need to present the > technical reasons. I'm trying hard, but it takes a lot of time to understand what's happening there. The public interface is badly underdocumented and a lot of implicit behaviour is happening all over the place. I find it unmaintainable - and as I'd like to adjust it to my needs, I feel like rewriting would be better. > > - use a parsed email.Message as input for the storage so that the > > publisher can blindly use the feedparser to push the uploaded body to. > > Ditto. I was trying to find something that can parse mime data already and the Python docs refer to email.Message and discourage the use of the deprecated packages. > > I think writing up a spec would be a good thing, maybe we can do > > something about this at a next sprint. I'm pretty sure this won't land > > in Zope 3.4 > > Some notes: > > - I'm 98% sure that when using ZServer or Twisted, the CGI module is > invoked by the publisher and, therefore, in the application thread, > not the reactor thread. Blocking the select thread should not be an > issue. That is right. However, blocking application threads is the issue I'm trying to hunt down. > - AFAIK, recent changes to FieldStorage use a max size on readline > calls that should prevent large memory consumption. In the case of a > file upload, data are simply copied between temporary files. True. I want to avoid the copy because of time issues, not memory. > A small optimization would be arrange to avoid the copy if the input > stream happens to be a file. I have already done that. However, currently a copy happens when parsing and we can't avoid that. But I want to do it before the request enters the application thread. > The reason efforts to replace or refactor the cgi module over the > years have languages is that it is big and complicated and works > pretty well for the most part. Hmm. I assume you're pointing out it's hairy but it works so nobody really got down to it. I see that when reading through various old discussions on the lists too. > If we are *really* going to do any > tinkering, it should be in cooperation with the wider Python > community, through the Web SIG. Good luck. :) I agree with that. I need to do some more research how other frameworks handle this and probably gonna raise the question on the web sig list before starting any work (again). Thanks for reminding. Christian -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil _
[Zope3-dev] Autoconfiguring a site.zcml
On the basis that eggs spell out dependencies, I am thinking the inclusion of packages and their dependencies should be enough to dictate the sequence of inclusion for package configuration (and creation of the site.zcml) for the app buidout recipe. This could be a option to the current manual configuration. Presumably, the reason folks would use this recipe is to configure one or more of the same app. I know attempting to do this manually is prone to errors if packages are not in the correct sequence or if you miss the configuration of a package. Any thoughts on this. Many thanks. Regards, David ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] buildbot failure in Zope3 trunk 2.4 Linux zc-buildbot
Hmm. Up until now those failures where spurious on my machine. I'm somewhat happy those turned up. Jim mentioned to me those would be problems with exit handlers in the test runner, however one testrunner that was breaking on my machine didn't get fixed by switching to `os._exit()` :/ Am Samstag, den 21.04.2007, 06:25 -0400 schrieb [EMAIL PROTECTED]: > The Buildbot has detected a failed build of Zope3 trunk 2.4 Linux zc-buildbot. > > Buildbot URL: http://buildbot.zope.org/ > > Build Reason: changes > Build Source Stamp: 189 > Blamelist: ctheune > > BUILD FAILED: failed test > > sincerely, > -The Buildbot > > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: http://mail.zope.org/mailman/options/zope3-dev/ct%40gocept.com > -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] buildbot failure in Zope3 branches 3.3 2.4 Linux remy
That was a spurious ZEO error. Am Samstag, den 21.04.2007, 06:08 -0400 schrieb [EMAIL PROTECTED]: > The Buildbot has detected a failed build of Zope3 branches 3.3 2.4 Linux remy. > > Buildbot URL: http://buildbot.zope.org/ > > Build Reason: changes > Build Source Stamp: 187 > Blamelist: > alecm,alga,andreasjung,baijum,ctheune,darrylcousins,dobe,faassen,gary,jacobholm,jim,jukart,jvloothuis,ksmith_mcweekly,mj,philikon,rocky,rogerineichen,schwendinger,srichter,stmartin,tseaver,wichert,zagy > > BUILD FAILED: failed test > > sincerely, > -The Buildbot > > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: http://mail.zope.org/mailman/options/zope3-dev/ct%40gocept.com > -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3.4.0a1 released
Hi, Am Freitag, den 20.04.2007, 16:25 +0200 schrieb Martijn Faassen: > Hey, > > > Compatibility with Zope 2 > > -- > > > > We continue to work on the transition from Zope 2 to Zope 3 by making > > Zope 2 use more and more of the Zope 3 packages. But we're not there > > yet. **You can't run Zope 2 applications in Zope 3.** > > I just realized that this text could easily be misread to imply that we > are working on making Zope 2 applications work in Zope 3 (we're just not > there yet). That is not the case - we do not expect ever to have a > version of Zope 3 that can run Zope 2 code. > > I'd suggest a rewrite to say: > > Compatibility with Zope 2 > -- > > Zope 3 is not upwards compatible with Zope 2. This means you cannot run > Zope 2 applications in Zope 3. > > We continue to work on the transition from Zope 2 to Zope 3 by making > Zope 2 use more and more of the Zope 3 infrastructure. This means that > new code written in Zope 2 can benefit from Zope 3 technology. Also, > with care, code can be written that works in both Zope 3 and Zope 2. > This allows a Zope 2 application to slowly evolve towards Zope 3. > Unchanged Zope 2 applications are never expected to work in Zope 3, however. Thanks. I'll change the template to include this. -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] buildbot failure in Zope3 trunk 2.4 Linux zc-buildbot
The Buildbot has detected a failed build of Zope3 trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 189 Blamelist: ctheune BUILD FAILED: failed test sincerely, -The Buildbot ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] possible bug in z.a.password?
Adam Groszer wrote: Ugh, my bad I didn't notice that passwords may be Unicode strings. I think password should be encoded to UTF-8 before processing but I don't know that to do with backward compatibility. As an option we can introduce new Unicode-aware password managers. Opinions? Thinking it further, I think that nobody was able to enter accented passwords until today :-) I want to believe that most use more secure password managers which fit their needs. :-) and UTF-8 is encoding ASCII to ASCII (does it change anything???). I think it's OK. IMHO it would not hurt adding an UTF-8 encoding to the current password manager. Anybody against that? +1 I can commit the changes if nobody objects. -- Dmitry Vasiliev http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] buildbot failure in Zope3 branches 3.3 2.4 Linux remy
The Buildbot has detected a failed build of Zope3 branches 3.3 2.4 Linux remy. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 187 Blamelist: alecm,alga,andreasjung,baijum,ctheune,darrylcousins,dobe,faassen,gary,jacobholm,jim,jukart,jvloothuis,ksmith_mcweekly,mj,philikon,rocky,rogerineichen,schwendinger,srichter,stmartin,tseaver,wichert,zagy BUILD FAILED: failed test sincerely, -The Buildbot ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] SHA1Password manager, add a pinch of salt
Giovannetti, Mark wrote: I've been researching authentication and whatnot in Zope 3 and was looking at the password management implementations. I don't like the fact that the SHA1 password manager doesn't use a random salt value when encoding and storing a password. Salts are commonly used in /etc/passwd and friends to eliminate the identification of passwords that are the same among users, as well as to make the brute forcing space a little larger. Actually I've always thought about z.a.authentication.password as a simple reference implementation which you can use if you don't care much about security. However in production it always preferred to use more secure password managers. I'm not sure we need to apply the proposed patch but rather add note about reference implementation at the top of the z.a.a.password. -- Dmitry Vasiliev http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re[2]: [Zope3-dev] possible bug in z.a.password?
Hello Dmitry, Saturday, April 21, 2007, 10:57:07 AM, you wrote: > Ugh, my bad I didn't notice that passwords may be Unicode strings. I > think password should be encoded to UTF-8 before processing but I don't > know that to do with backward compatibility. As an option we can > introduce new Unicode-aware password managers. Opinions? Thinking it further, I think that nobody was able to enter accented passwords until today :-) and UTF-8 is encoding ASCII to ASCII (does it change anything???). IMHO it would not hurt adding an UTF-8 encoding to the current password manager. Anybody against that? -- Best regards, Adammailto:[EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Tests lost
Hi, I think we lost tests at some point. When moving code around some doc tests have not been added to the test suites again. I noticed because we received some bug reports about zope.app.component.vocabulary. This module contains doctests but those are never run (and obviously they are broken). I have no idea how many modules are affected, but I guess we'd need to do some substantial gardening to raise confidence that we're actually executing our tests. Does anybody have an idea of how to automate this reasonably? Christian -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] possible bug in z.a.password?
Adam Groszer wrote: Using the current trunk I experienced that using the PAU with a user folder and users passwords stored with MD5, entering accented characters as passwords causes an exception. That happens either at adding the principal or at Z3's stock login form. I think this is not my fault, but could somebody crosscheck that please? Traceback from the login form, I entered "éá" as password: File "U:\zope\svn_zope34\src\zope\publisher\publish.py", line 130, in publish File "U:\zope\svn_zope34\src\zope\app\authentication\password.py", line 77, in [skip] encodePassword return md5.new(password).hexdigest() UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-1: ordin al not in range(128) Ugh, my bad I didn't notice that passwords may be Unicode strings. I think password should be encoded to UTF-8 before processing but I don't know that to do with backward compatibility. As an option we can introduce new Unicode-aware password managers. Opinions? -- Dmitry Vasiliev http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Bug mangling for Zope 3.4
Hi, I'm doing a bit of bug mangling for Zope 3.4 everybody who wants to just go ahead and fix a bug for Zope 3.4 can go to https://bugs.launchpad.net/zope3/3.4/ and see what bugs need to be handled. Christian -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] GSoC project: Run Zope 3 using Python 2.5
On Apr 13, 2007, at 10:44 AM, Baiju M wrote: Hi, I would like to introduce Nikhil N a student from Kerala (India) who will be porting Zope 3 to work on Python 2.5. I am looking for your help and feedback to complete this project. He had already joined in this list, and I will ask him to send mails here before committing anything to svn. I am looking for a co-mentor for this project, anyone interested? i contacted philipp already one or two weeks ago and wanted to join the GSoC efforts (with a student and a project). unfortunately it was too late. but my (and lovelysystems's) offer to help out with GSoC is still valid :) jodok Regards, Baiju M ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/batlogg.lists% 40lovelysystems.com -- Lovely Systems, Partner phone: +43 5572 908060, fax: +43 5572 908060-77 Schmelzhütterstraße 26a, 6850 Dornbirn, Austria ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] SHA1Password manager, add a pinch of salt
On 4/20/07, Giovannetti, Mark <[EMAIL PROTECTED]> wrote: +def checkPassword(self, storedPassword, password): +if len(storedPassword) == 48: +salt = storedPassword[0:8] +else: +salt = '' +return storedPassword == self.encodePassword(password, salt) Because you allow the passing in of an arbirtary salt on encoding, you should either check the salt length on encoding (ensuring len 8) or, better, do the following: def checkPassword(self, storedPassword, password): salt = storedPassword[:len(storedPassword)-40] return storedPassword == self.encodePassword(password, salt) That'll capture any salt length as the sha.hexdigest output is always 40 characters long. -- Martijn Pieters ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
