DISCUSS: Import from the web
I need you folks to help us figure out how to add a sweet little feature: import from the web. Scenario: you work from home on a bunch of information in a Zope folder, like documents, images, Z Tables, etc. You get into work and want to blast it onto your remote Zope-based website. With Zope 1.10.2, you now have an interface to do this: you first export your folder on your laptop, move the export file to the filesystem of your webserver, and import the folder on the webserver. There are certainly some scripting things you could do in Python to make this a bit more seamless. But wouldn't it be nice if you could tell the two Zopes to swap information directly? To date we haven't done this for security reasons. Since export files are series of records containing pickles, the unpickler could be tricked into doing something unpleasant. While this could still happen under the current scheme, at least you know the person was trusted enough to log into the OS and be allowed to write to the directory. Thus, the current import/export scheme isn't about preventing damage, it (like External Methods) is about proving someone is trustworthy. Let's say we leave off the table right now consideration of making the import more immune to hijinx. Let's also leave off the table related issues (like synchronization or replication conflicts). Let's just ask the question: "Can we make import-from-the-network have as acceptible a level of trust as the filesystem?" Here are some brainstorm ideas: 1) Make the import a pull rather than a push. Instead of pushing the data from your computer into a remote Zope, you go to the remote Zope and put in the URL to your local Zope. 2) Turn import from the web off by default but have a knob to turn it on. 3) Reading directly from a Zope as it outputs an export means you're less likely to get a hacked pickle. 4) Have a shared key system, then rotor the export file (this is what we do on the unreleased Zope Network Client software). That is, wrap the data in an envelope. Of course there is still the ultimate question: is this a compelling feature? --Paul Paul Everitt Digital Creations paul@digicool.com 540.371.6909
On Fri, Feb 26, 1999 at 12:16:02PM -0500, Paul Everitt wrote:
"Can we make import-from-the-network have as acceptible a level of trust as the filesystem?"
There are three potential problems here, as I see it, or vectors for assault.... 1. Malicious users creating bad pickles 2. MIM attack that inserts garbage in 3. Unauthorized use by sniffed password/etc #1 I think is the smallest, honesty, because if it's true, you've got other larger problems. #2 is relatively uncommon, but can be side-stepped with a precomputed checksum (MD5 signature) that is input along with the filename/browse feature. #3 is the hardest, and is also exposed to the whole "web admin" issue, it's no better/worse because it's an import than going through an messing it up manually.
Here are some brainstorm ideas:
1) Make the import a pull rather than a push. Instead of pushing the data from your computer into a remote Zope, you go to the remote Zope and put in the URL to your local Zope.
No no, this is just too painful for words, breaks all kinds of security things that people have in place for "diodes" in their network.
2) Turn import from the web off by default but have a knob to turn it on.
This I like, make people conciously think about turning it on... everyone has differnt security policies. Provide the flexibility ot provide features with a known risk.
3) Reading directly from a Zope as it outputs an export means you're less likely to get a hacked pickle.
well, yeah, but it's also a pain in the butt, and perhaps hsould wait until replication itself is there, no? Then you can use the replication framework for this.
4) Have a shared key system, then rotor the export file (this is what we do on the unreleased Zope Network Client software). That is, wrap the data in an envelope.
WEll, see above. You really have to identify the vectors you're most concerned with. This system won't necessarily give you anything except "privacy" unless you also provide some tamper-resistance through hashing.
Of course there is still the ultimate question: is this a compelling feature?
IT's a "MUST HAVE" for me... I do a ton of prototyping at home, and then move it to a remote system as a big batch. Works great, it's a bit painful, but... much easier than before. Chris -- | Christopher Petrilli ``Television is bubble-gum for | petrilli@amber.org the mind.''-Frank Lloyd Wright
On Fri, 26 Feb 1999, Paul Everitt wrote:
I need you folks to help us figure out how to add a sweet little feature: import from the web.
Scenario: you work from home on a bunch of information in a Zope folder, like documents, images, Z Tables, etc. You get into work and want to blast it onto your remote Zope-based website.
Of course there is still the ultimate question: is this a compelling feature?
Yes -- other scenario -- you're a zope user on the starship. You want to upload stuff to your particular area of the Zope server. You don't have write access to the right directory. One issue w/ requiring it to be a pull is that e.g. in my case I can push to a server through the firewall, but my Zope is unaccessible from outside the firewall. --david
Paul Everitt wrote:
"Can we make import-from-the-network have as acceptible a level of trust as the filesystem?"
Here are some brainstorm ideas:
1) Make the import a pull rather than a push. Instead of pushing the data from your computer into a remote Zope, you go to the remote Zope and put in the URL to your local Zope.
This would work well, I believe, except when the 'pulled from' system is behind a firewall. Perhaps some sort of 'trusted third party' arangement would work for these situations.
2) Turn import from the web off by default but have a knob to turn it on.
Add another knob as to whether the system allows itself to be pulled from(and who by). Ensure this doesn't become an avenue for denial-of-service attacks on the pulled from system.
3) Reading directly from a Zope as it outputs an export means you're less likely to get a hacked pickle.
4) Have a shared key system, then rotor the export file (this is what we do on the unreleased Zope Network Client software). That is, wrap the data in an envelope.
Of course there is still the ultimate question: is this a compelling feature?
Absolutely. Anything that you can do to increase Zope's 'Network Effect' is a Good Thing(tm). While increasing the functionality of individual Zope installations is obviously nothing to sneer at, any feature (like this one) that adds value to the network as a function of the network size is going to be a killer app. <OT> As a minor example, how about a product that creates the sort of file that slashdot.py consumes? For that matter, how about a version of slashdot.py that is more generalized? Both of these examples are much more limited than 'Remote Import' or the 'Network Client', yet still have a significant ability to promote and popularize Zope. I realize that I am talking through my hat here, as I am not capable of creating either of these products on my own. </OT> Michael Bernstein.
participants (4)
-
Christopher G. Petrilli -
David Ascher -
Michael Bernstein -
Paul Everitt