Martin v. Löwis | 1 Apr 01:11 2003

Re: iconv codec

Guido van Rossum <guido <at>> writes:

> But given that it's only got a small audience, a 3rd party module
> would satisfy the need just as well, right?

The audience is actually quite large: any call to <unicodestr>.encode
could invoke this codec, if Python does not provide a builtin codec.

This includes, in particular, all CJK codecs. 

Together with a platform-specific codec wrapper for Windows and OS X,
the need to package Python-specific CJK codecs (with the size and
maintenance issues that come with them) might vanish.

Ka-Ping Yee | 1 Apr 01:15 2003

Re: Capabilities

On Sun, 30 Mar 2003, Paul Prescod wrote:
> I'm not clear (because I've been following the thread with half my
> brain, over quite a few days) whether you are making or have made some
> specific proposal. I guess you are proposing a restricted mode that
> would make this example actually secure as opposed to almost secure. Are
> you also proposing any changes to the syntax?

Not yet.  Although it's certainly tempting to propose syntax changes,
it makes more sense to really understand what we want first.  We can't
know that until we've actually tried programming in the capability style
in Python.  That's why i want to explore the possibilities and try these
exercises -- it will help us discover the shortest path from here to there.

> Also, is restricted mode an interpreter mode or is it scoped by module?

Whether restricted mode is activated depends on the __builtins__ of the
current namespace.  So the short answer is "by module".

> Yes, but why workaround rather than fix? Is there a deep reason Python
> objects can't write to intermediate namespaces?

No.  There's just no syntax for it yet.  But let's figure out what we
can get away with first.

> > It would be cool if you could suggest little "security challenges"
> > to work through.  Given specific scenarios requiring things like
> > mutability or friend classes, i think trying to implement them in
> > this style could be very instructive.
> Unfortunately, most of the examples I can come up with seem to be hacks,
(Continue reading)

Greg Ewing | 1 Apr 02:43 2003

Distutils documentation amputated in 2.2 docs?

I was looking at the Distributing Python Modules section of the
distutils docs for 2.2 the other day, and it mentioned a section about
extending the distutils, but there did not appear to be any such

Further investigation revealed that the 1.6 version of the docs *does*
have this section, as section 8, but somewhere between the 1.6 and 2.2
docs, this section has disappeared, along with almost all of section
9, "Reference", which now appears as section 7, but with only a small
part of what it should contain.

What's the proper way of submitting a bug report about this?

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg <at>	   +--------------------------------------+
Paul Prescod | 1 Apr 02:52 2003

Re: Capabilities

Ka-Ping Yee wrote:
> Hmm, i'm not sure you understood what i meant.  The code example i posted
> is a solution to the design challenge: "provide read-only access to a
> directory and its subdirectories, but no access to the rest of the filesystem".
> I'm looking for other security design challenges to tackle in Python.
> Once enough of them have been tried, we'll have a better understanding of
> what Python would need to do to make secure programming easier.

Okay, how about allowing a piece of untrusted code to import modules 
from a selected subset of all modules. For instance you probably want to 
allow untrusted code to get access to regular expressions and codecs 
(after taming!) but not os or socket.

Speaking of sockets, web browsers often allow connections to sockets 
only at a particular domain. In a capabilities world, I guess the domain 
would be an object that you could request sockets from.

Are DOS issues in scope? How do we prevent untrusted code from just 
bringing the interpreter to a halt? A smart enough attacker could even 
block all threads in the current process by finding a task that is 
usually not time-sliced and making it go on for a very long time. 
without looking at the Python implementation, I can't remember an 
example off of the top of my head, but perhaps a large multiplication or 
search-and-replace in a string.

  Paul Prescod
Paul Prescod | 1 Apr 03:08 2003

Re: Capabilities

Guido van Rossum wrote:
>>In many classes, __init__ exercises authority.  An obvious C type with
>>the same problem is the "file" type (being able to ask a file object
>>for its type gets you the ability to open any file on the filesystem).
>>But many Python classes are in the same position -- they acquire
>>authority upon initialization.
> What do you mean exactly by "exercise authority"?  Again, I understand
> this for C code, but it would seem that all authority ultimately comes
> from C code, so I don't understand what authority __init__() can
> exercise.

Given that Zipfile("/tmp/") can read a zipfile, the zipfile class 
clearly has the ability to open files. It derives this ability from the 
fact that it can get at open(), etc. In a capabilities world, it 
should not have access to that stuff unless the caller specifically gave 
it access. And the logical way for the caller to give it that access is 
like this:


But in restricted code

> ...
> But is it really ZipFile.__init__ that exercises the authority?  Isn't
> its authority derived from that of the open() function that it calls?

(Continue reading)

Jonathan Riehl | 1 Apr 03:50 2003

PEP 269 once more.

Hey all,
	FYI, Guido closed the patch I had on SourceForge (599331), but I
have just put an updated patch there.  I have added some documentation on
how my pgen module may be used, and the interface is much more consistent
and useful than the prior upload.  If anyone is interested in playing with
pgen from Python, check it out and let me know what you think.

Martin v. Löwis | 1 Apr 08:12 2003

Re: Distutils documentation amputated in 2.2 docs?

Greg Ewing <greg <at>> writes:

> What's the proper way of submitting a bug report about this?

It would be best if you would provide a patch. Try to locate the
primary source of the missing documentation (i.e. a TeX snippet),
and integrate this into the current CVS, then do a cvs diff.

If you find that the text is still there in the primary source, and
just not rendered in the HTML version, submit a bug report pointing to
the precise file that does not get rendered.

Joel de Guzman | 1 Apr 10:56 2003

Re: How to suppress instance __dict__?

Dave Abrahams wrote:

>> I am generating extension types derived from a type which is derived
>> from int 'int' by calling the metaclass; in order to prevent instances
>> of the most-derived type from getting an instance _dict_ I am
>> putting an empty tuple in the class _dict_ as '_slots_'.  The
>> problem with this hack is that it disables pickling of these babies:
>>    "a class that defines _slots_ without defining _getstate_
>>     cannot be pickled"

Guido van Rossum wrote:

> Yes.  I was assuming you'd do this at the C level.  To do what I
> suggested in Python, I think you'd have to write this:
>     class M(type):
>         def __new__(cls, name, bases, dict):
>     C = type.__new__(cls, name, bases, dict)
>     del C.__getstate__
>     return C


Ok, I'm lost. Please be easy with me, I'm still learning the C API
interfacing with Python :) Here's what I have so far. Emulating the 
desired behavior in Python, I can do:

    class EnumMeta(type):
(Continue reading)

Zooko | 1 Apr 18:47 2003

Re: Capabilities (we already got one)

(I, Zooko, wrote the lines prepended with "> > ".)

 Guido wrote:
> Yes.  That may be why the demand for capabilities has been met with
> resistance: to quote the French in "Monty Python and the Holy Grail",
> "we already got one!" :-)


Such skepticism is of course perfectly appropriate for proposed changes to your 
beautiful language.

More on the one you already got below.  (I agree: you already got one.)

> > Here's a two sentence definition of capabilities:
> I've heard too many of these.  They are all too abstract.

There may have been a terminological problem.  The word "capabilities" has been 
used for three different systems -- "capabilities-as-rows-of-the-Lampson-access-
control-matrix", "capabilities-as-keys", and "capabilities-as-references".  
Unfortunately, the distinction is rarely made explicit, so people often assert 
things about "capabilities" which are untrue of capabilities-as-references.  
(Ping has just written a paper about this.)

The former two kinds of capabilities have major problems and are disliked by 
almost everybody.  The last one is the one that Ping, Ben Laurie and I are 
advocating, and the one that you already got.
(Continue reading)

Jeremy Hylton | 1 Apr 19:10 2003

Re: Capabilities (we already got one)

On Tue, 2003-04-01 at 11:47, Zooko wrote:
> I think that in restricted-execution-mode (hereafter: "REM", as per Greg Ewing's 
> suggestion [1]), Python objects have encapsulation -- one can't access their 
> private data without their permission.
> Once this is done, Python references are capabilities.

REM does not provide object encapsulation, but it disables enough
introspection that it is possible to provide encapsulation.  The REM
implementation provides a Bastion function that creates private state by
storing the state in func_defaults, which is inaccessible in REM.