On Wednesday 21 January 2004 03:21 pm, Jamie Heilman wrote:
> Hiding the bugs doesn't avoid anything, it just leaves zope
> administrators helpless in the dark. I'm not going to rehash the
> arguments for and against full dislosure, but seriously--don't delude
> yourself into thinking that a probl
Hi,
I would like to stop developing with JBoss and convert to Zope.
I have been able to figure most things out using the Zope website but I have
a few questions...
The majority of my code was in EJB's. So I am trying to create Zope products
to replace them.
What kind of naming service is availa
On Wed, 21 Jan 2004 16:16:15 -0800
Jamie Heilman <[EMAIL PROTECTED]> wrote:
> Maik Jablonski wrote:
> > There are many admins / users out there who aren't able to do this
> > (maybe they should learn it, but that's another point). Installing
> > Zope 2.6.3 was a big mess (even renaming in the ZMI
> Maik Jablonski wrote:
> > Normaly security-related stuff is not visible for the public... and
> > this seems to be good to avoid exploits etc.
>
> Jamie Heilman wrote:
> Hiding the bugs doesn't avoid anything, it just leaves zope
> administrators helpless in the dark. I'm not going to rehash the
>>> Jamie Heilman wrote
> Given that ZC clearly doesn't have the resources available to do (a),
> irrespective of if its even technically feasible, we can rule it out.
> And (b), well (b) just screws everybody. Exploits are a byproduct of
> understanding the vulnerability, they're a natural part
Maik Jablonski wrote:
> There are many admins / users out there who aren't able to do this
> (maybe they should learn it, but that's another point). Installing Zope
> 2.6.3 was a big mess (even renaming in the ZMI was broken) and most
> people rolled back to 2.6.2. Some people run even 2.5.1 (lo
Hi Jamie,
Jamie Heilman wrote:
Hiding the bugs doesn't avoid anything, it just leaves zope
administrators helpless in the dark.
...
> How exactly was ZC
supposed to release a new version of Zope with the fixes but at the
same time not divulge the nature of the security flaws? Release an
obsfucate
Maik Jablonski wrote:
> Normaly security-related stuff is not visible for the public... and
> this seems to be good to avoid exploits etc.
Hiding the bugs doesn't avoid anything, it just leaves zope
administrators helpless in the dark. I'm not going to rehash the
arguments for and against full di
Jeremy Hylton wrote at 2004-1-21 11:44 -0500:
>On Wed, 2004-01-21 at 10:42, Brian Lloyd wrote:
>> What I don't like is that it is somewhat magical, and now the
>> error you would get (probably 'None has no attribute xxx') if
>> the user doesn't have access to the container doesn't tell you
>> th
Brian Lloyd wrote:
Jeremy Hylton wrote:
What if you used a special object that would produce a useful error
message if the user tries to access the container.
I like this. Make it a singleton, and put it in the global namespace
for Scripts, so that we can write:
if context is Inac
Hi,
there were several security-related fixes in the collector (and the
collector-mailing-list) in the last days. Normaly security-related stuff is
not visible for the public... and this seems to be good to avoid exploits
etc.
Lots of security-stuff is fixed now, but I don't think that all people
On Wed, Jan 21, 2004 at 02:06:24PM -0500, Brian Lloyd wrote:
> I've checked in the changes to the 2.6 branch, 2.7 branch and the head
> to change the binding behavior for 'container' and 'context':
>
> - If the user does not have access to the item, the script
> will bind an UnauthorizedBin
> > These two facts did not cause a problem before, because the security
> > check for the 'container' binding was not being performed at bind-time.
>
> One question - what *is* bind time?
> Is the container bound when the script is called?
Yes - all of the bindings are figured out at the time the
> Jeremy Hylton wrote:
> > What if you used a special object that would produce a useful error
> > message if the user tries to access the container.
>
> I like this. Make it a singleton, and put it in the global namespace
> for Scripts, so that we can write:
>
>if context is Inaccessible:
On Wed, Jan 21, 2004 at 10:42:11AM -0500, Brian Lloyd wrote:
> These two facts did not cause a problem before, because the security
> check for the 'container' binding was not being performed at bind-time.
One question - what *is* bind time?
Is the container bound when the script is called?
--
Jeremy Hylton wrote:
What if you used a special object that would produce a useful error
message if the user tries to access the container.
I like this. Make it a singleton, and put it in the global namespace
for Scripts, so that we can write:
if context is Inaccessible:
# Do without acces
On Wed, 2004-01-21 at 10:42, Brian Lloyd wrote:
> What I don't like is that it is somewhat magical, and now the
> error you would get (probably 'None has no attribute xxx') if
> the user doesn't have access to the container doesn't tell you
> the real problem.
What if you used a special object
I'm no big shell scripter, some suggestions anyway...
* I think you might be missing an INSTANCE_HOME parameter here,
something like
# what we'd like but won't recognize instance home
# exec /usr/bin/python $ZOPE_BASE/z2.py -z $ZOPE_BASE -u $USER \
# -w $HTTP_PORT -f $FTP_PORT -t
Hi!
Brian Lloyd wrote:
What I don't like is that it is somewhat magical, and now the
error you would get (probably 'None has no attribute xxx') if
the user doesn't have access to the container doesn't tell you
the real problem.
Could we add a ContainerDummy object instead of None that raises a
Hi all -
We recently made Zope 2.6.4-rc1 and 2.7.0-rc1 releases which fix
a number of issues that were introduced in the Q4 security audit
work and the resulting 2.6.3 and 2.7.0-b4 releases.
The initial feedback is very good, and at this point I am aware of
only one outstanding issue - but it
Hi,
These are probably more shell scripting issues, but I'm hoping that
some scripter with an agile mind will show me the error of my ways,
so here goes.
I have borrowed a script from the zope site and modified it for my
purposes, and it 'sort of' works. The issues are:
Can't seem to get the
robert rottermann wrote:
Note from the subject: 2.6.4rc1 did *not* contain changes which were
expected to fix your issue; in fact, I can't think of any reasonable
change (to the Zope core, at least) which would both restore the
behavior you want and close the hole.
Hi there,
the new securit
Hi there,
the new security regime that changed the rules to acces scripts still
prevent my workflow to work.
Tres suggestion to give the scripts a proxy role of 'Manager' or
clearing the parent parameter in the scripts binding did not help.
I have the impressen, that DCWorkflow does not take th
> Can anyone shed light on all of these? I know about some of them, but this
> is quite a disturbingly long list...
These fixes were mentioned in the last few announcements Brian made,
as well as an explanation how several of the issues came to be found.
The particular security focus message you'
Hi,
Can anyone shed light on all of these? I know about some of them, but this is
quite a disturbingly long list...
cheers,
Chris
-- Forwarded Message --
Date: Tuesday, January 20, 2004 2:45 PM -0700
From: Kelly Martin <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Security
25 matches
Mail list logo