[Zope3-dev] Re: running tests from src as opposed to an instance
Chris Withers wrote: Philipp von Weitershausen wrote: $ svn co .../trunk Zope3 $ cd Zope3 $ make $ python test.py -s zope.i18n Ah cool, didn't notice that test.py lived there in Zope 3... Now, what about Zope 2, Zope 2 checkouts ship with pretty much the same test.py script. more specifically Zope 2 releases for Windows? Zope 2 releases should ship with bin/test.py (probably Scripts\test.py on Windows). Though the one shipping with Zope 2.9.3 doesn't properly set up PYTHONPATH to include the Zope 2.9.3 SOFTWARE_HOME. Perhaps that's going to be fixed in Zope 2.9.4 which won't be built using zpkg. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] What are zope.generic, z3c, ldapauth, et.al.?
Excuse my abscence. I'm a little busy and cannot find the time to track
the list daily.
Small summary of zope.generic:
it's a not-yet-fully-implemented, experimental prototype trying to find
a high-level-usage pattern or framework for zope 3.
During the easter-sprint I decided to put the code into the zope
repository. We came up with the name
zope.generic and Stephan told us it would be ok to put the stuff into a
dotted-named top level package.
We are using this code within two customer projects. We like the main
direction, but there is a lot stuff that has to be refactored (as usual)
and a lot of missing stuff that has to be implemented before we would
announce anything. We plan the first alpha-release in december.
Regards,
Dominik
Target
--
The zope.generic package should provide a higher level abstraction or
usage of the ca.
It should empower people with a analytical and technical background
(none- or fun-programmer) use the zope infrastructure.
Therefore the abstraction should allow to configurate components using a
generic logical pattern, to reuse features and a way to extend the
functionality with simple python function without knowing a lot about
the whole ca.
The behavior of those components (logical pattern) should be abstract,
but highly derived from object-orientation too, because the target
audience is pretty comfortable with that model (- comparable
abstraction would be ZClasses or object-oriented Requirement Analysis).
The application domain should be composed individually, that means
people should declare their own domain types rather than using a fix
domain types (- cms application - document, news, event, etc.)
The domain types itself should be composed using generic sub-component
and features.
Those features should be developed and implemented orthogonal and
generic manner. Such a feature implements technical functionalitiy. For
example there might be a document feature. You can enable the document
feature for a certain domain type. Afterward this domain type should
provide the feature. A feature requires some configuration of the
underlying domain type or an instance and it provides a certain api by
adaption. This configuration aspect should be solved generically using a
memento pattern.
Simplify by automation (- provide a complementary option to phillips
simplification-direction).
Design Goals
-
After the experiences with tiks. We decided to base the implementation
heavily on a marker interface pattern. That means there are only a few
generic base implementation (such as Object, Contained, Container,
Folder,...) that can be decorated by domain-specific
marker-interfaces.We decided to provide a mechanism that declares the
most important interface (key interface - keyface). This keyface is an
equivalent to class. The keyface can be used to look up the
corresponding configurations of a marked component. Those configurations
can be annotated directly to the object itself or might be provided by a
corresponding information providers (utilities) globally. We introduced
a new memento-implemenation called configuration. This is similar to
annotation but it is using configuration interfaces as keys instead of
id-string. Those configuration interfaces allows us to introspect
annonations more efficiently and to implement any configuration with a
generic base implementation.
Example
-
Step 1: Define your Key Interfaces: interfaces.py
class IMeasuringSystem(IWebApplication):
Mark the measuring system application.
contains('bopp.ms.measuringsystem.IProductionOrder')
containers(IWebPlatform)
class IOrder(Interface):
Mark an abstract order of the measuring-system.
class IProductionOrder(IOrder):
Mark a production order of the measuring-system.
contains('bopp.ms.measuringsystem.IProductionBatch')
containers(IMeasuringSystem)
class IProductionBatch(IOrder):
Mark a production batch of production order.
containers(IProductionOrder)
Step 2: Define dedicated configuration interfaces if necessary:
interfaces.py
class IMeasuringSystemConfiguration(Interface):
Input configuration of a messuringsystem.
data = TextLine(title=_(u'Data Directory'),
description=_(u'Main data directory.'),
required=True,
constraint=os.path.isdir,
max_length=255)
class IOrderConfiguration(Interface):
Abstract order.
aufnr = OrderID(title=_(u'Auftrag-Nr. (FAUF)'),
description=_(u'Fertigungs-Auftrag-Nummer der Charge'))
class AnyBatchEvent(ObjectEvent):
Notify any batch event
Step 3: Implement dedicated handlers in python if necessary: app.py
orderConfiguration = {'aufnr': u'9'}
def setup(context, *pos, **kws):
# make the folder to a site
ensureSite(context)
# add an int id utility
ensureIntIds(context)
ensureCatalog(context, IOrderConfiguration,
name=toDottedName(IMeasuringSystem), key=u'Catalog')
def anyBatchEventHandler(context, *pos,
Re: [Zope3-dev] Re: Comment on ITranslationDomain
On Friday 07 July 2006 05:18, Chris Withers wrote: Well, that was one of the most useless responses I've ever read ;-) Care to explain what, exactly, you were saying yes too? Sorry, it is not relevant and can be removed. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ 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: The bug fixing problem
On Jul 6, 2006, at 12:29 PM, Philipp von Weitershausen wrote: [EMAIL PROTECTED] wrote: Christian Theune wrote at 2006-7-5 11:46 +0200: ... Another thing are the rules about unit tests. Some bugs touch areas that are poorly tested. When I fix a bug over there, do I have to work harder to introduce the fix because I have to start introducing tests? We should find and announce a reasonable answer for the procedure in this case. Although I have (so far) never fixed a bug in Zope 3 (but posted several patches for Zope 2), I can confirm this: There are bugs that do not need a test once they are fixed. All kinds of NameError and AttributeError fall into this category. Requiring to write a unit test for these or similarly trivial bugs is silly -- especially if there is not yet a testing file for the module (such that a trivial test would suffice). I disagree. How would you make sure that your fix for even a trivial NameError actually works? Perhaps you introduced another typo in the bugfix? Or perhaps another problem pops up in the same codepath. Clearly, since the NameError didn't occur in any other tests, the codepath hasn't been tested yet, so it should be no matter what. There's another aspect to tests for bugs: reproduceability. Especially when fixing bugs I tend to write tests first in order to be absolutely sure that I can reproduce the problem in an automated manner. Then fixing the bug is easy: Just make the test pass... Well said. I agree 100% 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: running tests from src as opposed to an instance
Philipp von Weitershausen wrote: Zope 2 releases should ship with bin/test.py (probably Scripts\test.py on Windows). Though the one shipping with Zope 2.9.3 doesn't properly set up PYTHONPATH to include the Zope 2.9.3 SOFTWARE_HOME. Perhaps that's going to be fixed in Zope 2.9.4 which won't be built using zpkg. Ah, that's likely the source of the problem... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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: The bug fixing problem
On Jul 6, 2006, at 2:03 PM, Lennart Regebro wrote: On 7/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: When I have introduced secondary bugs in my fixes (which occasionally happened), then a unit test would not have helped. The reason was then that the affected code was used in unanticipated ways -- and because it was unanticipated, I would not have written a test for it. Sure. The point of the tests is not to prevent this. The point of them is mainly to make sure that the thing you fixed says fixed. Or that you actually fixed the thing you set out to fix, because, as part of the test writing process you has to actually reproduce the problem. I often learn quite a bit about bugs when trying to reproduce them. Bugs that appear shallow often turn out to be much deeper during this process. The security problem we dealt with the other day turned out this way. It was only through testing that Tres found out that the problem was much different than it appeared on the surface. Also, I think the habit of testing is as important as anything else. We should always feel a bit queasy about making a change without tests. 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
Re: [Zope3-dev] Re: The bug fixing problem
On Jul 6, 2006, at 10:11 PM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Theune wrote: Hi, Marius Gedminas wrote: I do not think that the requirements to 4. Write unit tests 5. Merge bugfixes from trunk to the release branch 6. Wait for the incredibly slow updates on the collector discourage me all that much. Right. They don't discourage me either, but there is a special case in 4) which I hit several times lately, where the unit tests need very special effort. I think that if more bug reports had a solution outlined in English, I'd be more likely to go fix them every now and them. Indeed! I would say that there are two bugs in the case you are describing: the one you meant to fix and the one which is the lack of any tests for the module / class / whatever. I would bet that spending your thirty minutes adding minimal tests to such a module is a *higher* value activity than fixing most bugs, because it makes it easier for you (or someone else) to fix that bug and others in that module. Good point. OTOH, well I'll mention the other hand in a separate post. :) 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
Re: [Zope3-dev] The bug fixing problem
Jim Fulton wrote: I think we need to be more draconian about quality. Because we are late for this release, we will need to take the usual shortcuts, however, if we find missing tests, we should report them as non-critical bugs. In addition, we should disallow any new features that would affect a release until all outstanding bugs, including missing tests have been resolved. I agree on that. Quality is why we fix the bugs in first place, isn't it? :) Finally, I'll note that, IMO, Zope is too big. This refers to both Zope 2 and Zope 3. We have too many batteries included and they are starting to leak acid because they aren't being properly maintained. :) I'm very hopeful that we can move to a more agile package-based release system in the coming months. Right. I agree on that. Especially on the idea to distribute the maintainership amongs more people so that taking over responsibility for an individual package does not become too much of a burden for the individual. This also goes along the ZF effort to communicate about the reusability of Zope 3's packages. I would actually love to see a distribution-oriented sprint early this fall to look at: 1. How to better leverage eggs in managing and making distributions 2. How to improve the user experience for installing distributions, especially for Zope 3. 3. Get rid of zpkg. :) 4. Find a better way to manage the distribution process. My hope is that distributions become more about assembling packages, much like linux distributions. My thought is that core developers would no-longer be responsible for making distributions. There might even be alternate distributions aimed at different audiences. This sounds good and is very interesting for me. The DZUG has a meeting on 14th and 15th of September. We could organize a sprint around that easily. 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 ___ 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: The bug fixing problem
Hi, Jim Fulton wrote: On Jul 6, 2006, at 12:29 PM, Philipp von Weitershausen wrote: [EMAIL PROTECTED] wrote: Christian Theune wrote at 2006-7-5 11:46 +0200: ... Another thing are the rules about unit tests. Some bugs touch areas that are poorly tested. When I fix a bug over there, do I have to work harder to introduce the fix because I have to start introducing tests? We should find and announce a reasonable answer for the procedure in this case. Although I have (so far) never fixed a bug in Zope 3 (but posted several patches for Zope 2), I can confirm this: There are bugs that do not need a test once they are fixed. All kinds of NameError and AttributeError fall into this category. Requiring to write a unit test for these or similarly trivial bugs is silly -- especially if there is not yet a testing file for the module (such that a trivial test would suffice). I disagree. How would you make sure that your fix for even a trivial NameError actually works? Perhaps you introduced another typo in the bugfix? Or perhaps another problem pops up in the same codepath. Clearly, since the NameError didn't occur in any other tests, the codepath hasn't been tested yet, so it should be no matter what. There's another aspect to tests for bugs: reproduceability. Especially when fixing bugs I tend to write tests first in order to be absolutely sure that I can reproduce the problem in an automated manner. Then fixing the bug is easy: Just make the test pass... Well said. I agree 100% Just to make sure nobody got me wrong: I'm not arguing that tests are a bad thing. They belong to the best thing that came up in the last years. :) I was merely pointing to a small edge-case in bugfixing, that might be even smaller then anticipated, where I got frustrated in the last time. +1 for the tests-are-good-recap :) 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 ___ 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: The bug fixing problem
On Jul 7, 2006, at 7:52 AM, Christian Theune wrote: Hi, Jim Fulton wrote: On Jul 6, 2006, at 12:29 PM, Philipp von Weitershausen wrote: [EMAIL PROTECTED] wrote: Christian Theune wrote at 2006-7-5 11:46 +0200: ... Another thing are the rules about unit tests. Some bugs touch areas that are poorly tested. When I fix a bug over there, do I have to work harder to introduce the fix because I have to start introducing tests? We should find and announce a reasonable answer for the procedure in this case. Although I have (so far) never fixed a bug in Zope 3 (but posted several patches for Zope 2), I can confirm this: There are bugs that do not need a test once they are fixed. All kinds of NameError and AttributeError fall into this category. Requiring to write a unit test for these or similarly trivial bugs is silly -- especially if there is not yet a testing file for the module (such that a trivial test would suffice). I disagree. How would you make sure that your fix for even a trivial NameError actually works? Perhaps you introduced another typo in the bugfix? Or perhaps another problem pops up in the same codepath. Clearly, since the NameError didn't occur in any other tests, the codepath hasn't been tested yet, so it should be no matter what. There's another aspect to tests for bugs: reproduceability. Especially when fixing bugs I tend to write tests first in order to be absolutely sure that I can reproduce the problem in an automated manner. Then fixing the bug is easy: Just make the test pass... Well said. I agree 100% Just to make sure nobody got me wrong: I'm not arguing that tests are a bad thing. They belong to the best thing that came up in the last years. :) I was merely pointing to a small edge-case in bugfixing, that might be even smaller then anticipated, where I got frustrated in the last time. +1 for the tests-are-good-recap :) And just to make sure that I was clear, when trying to urgently go through bugs for a release, I think it's OK to provide a test for just the fix. If, in the course of a fix, you notice that a package is short of tests, it would be great to add more then, but it would be OK to just turn that lack of tests into a separate non-urgent bug entry. 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
Re: [Zope3-dev] The bug fixing problem
Hi there, Jim Fulton wrote: On Jul 5, 2006, at 5:46 AM, Christian Theune wrote: I'm sitting at EuroPython right now, and a small discussion came up, trying to find out why nobody seems motivated to fix bugs came up. Martijn Fassen noted that the tools we use should be better (I agree on that, especially making it easy to find which bugs need to be urgently fixed for the next release). Obviously that isn't a pure problem on it's own. There are certainly many problems with the current bug trackers, which were written several years ago. Finding out quickly which bugs need to be fixed for the next release isn't one of them. (Although discovering how to do this isn't obvious and could be trivially improved through configuration.) I tried to raise the discussion last year about this topic : http://mail.zope.org/pipermail/zope3-dev/2005-May/014588.html ... but didn't go far. I believe the bug tracker is certainly the most important tool for a project like Zope3. Nowadays, to know what bugs need to big fixed I need to : - Consult a TODO.txt file within the trunk (like in the good old days...) And hope nobody forgot any bug. - Then go the issue tracker to get the description and possible comments. It's painful but as a commiter I could do it. Now imagine someone that would like to participate outside of the Zope community. It means basically that we are dealing with the Zope3 *releases* using text files... Bug trackers such as Trac, Bugzilla, Mantis or the really best one Jira are doing that properly for you using milestone or releases. So finding bugs that need to be fixed can be done easily but finding bugs that need to be fixed *for* a given release is another story. Even with critical or important issues (or whatever they are called within the issue tracker) we might want to re-target them to aonther release / milestone etc... to meet the release deadline. As well, it's important to let non developers the ability to vote / comment on the issues since they are the consumers. *Every* serious open source projects are using one of the trackers above. Why not Zope ? Other problems with the Issue Tracker are: - Notifications sucks : a user can't be notified if he wants to (except if he's asking Jim or granted people), no rss available etc - Zope.org is really slow and buggy. - You want to avoid using it as much as you can ;) Trac for instance is really well integrated with subversion an would certainly be a sane option for the Zope development. (it's not as good as Jira but it's free) Currently, CPS, Plone, twisted to talk about the projects we know the best are using it with success. I believe this is an error to underestimate the importance of the bug tracking system for a project like Zope. At Nuxeo, we tried in order : bugzilla, mantis, trac and now we are switching to Jira because it really really improves the development process. As well, dog food is interesting (meaning issue tracker) when the food is not terrible [...] Another thing are the rules about unit tests. Some bugs touch areas that are poorly tested. When I fix a bug over there, do I have to work harder to introduce the fix because I have to start introducing tests? See Tres' answer. I think there is a deeper issue, or set of issues. 1. Most people don't like to fix bugs. :) You're right on this. 2. We generally fix bugs when we want to make a release. There is tremendous pressure to take shortcuts like downgrading bugs from critical, pushing them off to later releases, or not writing missing tests. yep that's a fact. I guees the main problem is that almost nobody is using Zope3 for productions compared to Zope2. So bugs are not critical for production projects which doesn't ease the allocation of resources in the various companies... I think we need to be more draconian about quality. Because we are late for this release, we will need to take the usual shortcuts, however, if we find missing tests, we should report them as non-critical bugs. In addition, we should disallow any new features that would affect a release until all outstanding bugs, including missing tests have been resolved. That's probably the best way to get bugs fixed. ;) [...] My 2 cents. Cheers, J. -- Julien Anguenot | Nuxeo RD (Paris, France) Open Source ECM - www.nuxeo.com CPS Platform - http://www.cps-project.org Mobile: +33 (0) 6 72 57 57 66 signature.asc Description: OpenPGP digital 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] The bug fixing problem
On Jul 7, 2006, at 9:45 AM, Julien Anguenot wrote: Hi there, Jim Fulton wrote: On Jul 5, 2006, at 5:46 AM, Christian Theune wrote: I'm sitting at EuroPython right now, and a small discussion came up, trying to find out why nobody seems motivated to fix bugs came up. Martijn Fassen noted that the tools we use should be better (I agree on that, especially making it easy to find which bugs need to be urgently fixed for the next release). Obviously that isn't a pure problem on it's own. There are certainly many problems with the current bug trackers, which were written several years ago. Finding out quickly which bugs need to be fixed for the next release isn't one of them. (Although discovering how to do this isn't obvious and could be trivially improved through configuration.) I tried to raise the discussion last year about this topic : http://mail.zope.org/pipermail/zope3-dev/2005-May/014588.html ... but didn't go far. I believe the bug tracker is certainly the most important tool for a project like Zope3. I wasn't suggesting that we couldn't use a better bug tracker. I was just saying that it's not hard to find out what bugs need to be fixed for the next release. Nowadays, to know what bugs need to big fixed I need to : - Consult a TODO.txt file within the trunk (like in the good old days...) And hope nobody forgot any bug. - Then go the issue tracker to get the description and possible comments. No. you just go to the collector and search for accepted or pending bugs or bugs with solutions. That's it. If we are focussed on a release, you should further limit this to critical items. All of this is easy to do with the existing UI. It's painful but as a commiter I could do it. Now imagine someone that would like to participate outside of the Zope community. It means basically that we are dealing with the Zope3 *releases* using text files... Bug trackers such as Trac, Bugzilla, Mantis or the really best one Jira are doing that properly for you using milestone or releases. No. they use the collector. The to-do file was checked in by accident. :( So finding bugs that need to be fixed can be done easily but finding bugs that need to be fixed *for* a given release is another story. No. Bugs that need to be fixed for the next release are marked critical. As I mentioned, this can and probably should be improved. Snipping further collector complaints. The bug fiing problem is *not* a tool issue. 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: What are zope.generic, z3c, ldapauth, et.al.?
Tres Seaver wrote: [EMAIL PROTECTED] wrote: no problem, I agree to have a place for such infos. The README.txt files are not good enough for give a overview because you have to checkout first or browse the really slow repos with a browser. Tell me where is somewhere and I can write something ;-) snip Maybe there should be a top-level README (a peer of the 'src' directory) which outlines the overall architecture and points to the individual sub-packages as they fit into that concept. Then, anybody who checks out the trunk, or a tag, or a branch, will get that overview in the top of their checkout. Yes, that's a good start. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Through-the-web reStructuredText
Zope 3, as releases is not affected by the security hole that has plagued Zope 2, however, Michael Haubenwallner has pointed out that some add-on-products, such as zwiki and bugtracker, may provide TTW reST. There are 2 issues here: 1. That we need to warn anyone using these that there is an issue, including anyone who might be using a Zope 3 checkout in production. 2. I want to move these out of the main subversion tree. For those of you on this list, consider yourself warned. We should probably send out a warning more broadly though. Thoughts? 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: The bug fixing problem
Philipp von Weitershausen wrote at 2006-7-6 21:35 +0200: ... If you follow the argument that untested code is broken by definition, I do not follow it. then you essentially have no fix if you get a fix without knowing whether it actually works. In many cases, I can convince myself that a fix does actually work without performing a test -- at least in the sense that it removes one bug. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Through-the-web reStructuredText
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Zope 3, as releases is not affected by the security hole that has plagued Zope 2, however, Michael Haubenwallner has pointed out that some add-on-products, such as zwiki and bugtracker, may provide TTW reST. They appear to be safe for the moment, but not because they intentionally disable file inclusion: rather, they have a bug (they set the 'encoding' to 'unicode', which then causes an exception). DTML Page was another possible culprit: it too is safe for the moment, because Z3's DTML does not have a handler for 'fmt=restructured-text'. That is not really a comfort, because someday somebody is going to harmonize Zope2's DTML features into Zope3's DTML; at that point we are hosed again. There are 2 issues here: 1. That we need to warn anyone using these that there is an issue, including anyone who might be using a Zope 3 checkout in production. 2. I want to move these out of the main subversion tree. For those of you on this list, consider yourself warned. We should probably send out a warning more broadly though. Thoughts? I think the benefit of leaving file inclusion lying around in the main python path's version of docutils (for benefit of notional filesystem ResT users) is far outweighed by the risks associated with it. TTW ReST is *valuable* to people: it gets used by content authors, among others. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFErsYB+gerLs4ltQ4RAjeCAKC20y9dt1CLJNzYH/QC3suafMdeoACfV1O7 C/2DHO5D+8hwacuMcvw8w5U= =qCze -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: Through-the-web reStructuredText
On Jul 7, 2006, at 4:37 PM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Zope 3, as releases is not affected by the security hole that has plagued Zope 2, however, Michael Haubenwallner has pointed out that some add-on-products, such as zwiki and bugtracker, may provide TTW reST. They appear to be safe for the moment, but not because they intentionally disable file inclusion: rather, they have a bug (they set the 'encoding' to 'unicode', which then causes an exception). DTML Page was another possible culprit: it too is safe for the moment, because Z3's DTML does not have a handler for 'fmt=restructured- text'. That is not really a comfort, because someday somebody is going to harmonize Zope2's DTML features into Zope3's DTML; at that point we are hosed again. Yup, unless someone does the reST integration correctly. There are 2 issues here: 1. That we need to warn anyone using these that there is an issue, including anyone who might be using a Zope 3 checkout in production. 2. I want to move these out of the main subversion tree. For those of you on this list, consider yourself warned. We should probably send out a warning more broadly though. Thoughts? I think the benefit of leaving file inclusion lying around in the main python path's version of docutils (for benefit of notional filesystem ResT users) is far outweighed by the risks associated with it. TTW ReST is *valuable* to people: it gets used by content authors, among others. I hear you. I find it a hard call. It should be possible to use reST safely without removing the feature, yet we have shown ourselves unable to over and over again. :( I think we need tests for any TTW reST code and those tests need to demonstrate that file/url inclusion is disabled. 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: Through-the-web reStructuredText
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Zope 3, as releases is not affected by the security hole that has plagued Zope 2, however, Michael Haubenwallner has pointed out that some add-on-products, such as zwiki and bugtracker, may provide TTW reST. They appear to be safe for the moment, but not because they intentionally disable file inclusion: rather, they have a bug (they set the 'encoding' to 'unicode', which then causes an exception). Both restructuredText directives 'include' and 'raw' have an 'encoding' option to set the name of text encoding of the external data file/raw data (file or URL), it defaults to the document's encoding (if specified). .. include:: filename.ext :encoding: utf-8 .. raw:: html :file: filename.ext :encoding: utf-8 should work as expected Michael -- http://zope.org/Members/d2m http://planetzope.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: Through-the-web reStructuredText
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Haubenwallner wrote: Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Zope 3, as releases is not affected by the security hole that has plagued Zope 2, however, Michael Haubenwallner has pointed out that some add-on-products, such as zwiki and bugtracker, may provide TTW reST. They appear to be safe for the moment, but not because they intentionally disable file inclusion: rather, they have a bug (they set the 'encoding' to 'unicode', which then causes an exception). Both restructuredText directives 'include' and 'raw' have an 'encoding' option to set the name of text encoding of the external data file/raw data (file or URL), it defaults to the document's encoding (if specified). .. include:: filename.ext :encoding: utf-8 .. raw:: html :file: filename.ext :encoding: utf-8 should work as expected Michael Verified. Both wikis and bugtracker issues are capable of including arbitrary files using that spelling (in an instance created from today's Zope3 trunk, anyway). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFErzS3+gerLs4ltQ4RAhboAKC0oxRwqZKBOiZxYEEPXoPi1NE0tACbBepr f5qWSi/OFDafP05XGXaOqxI= =x4ny -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
