This file is indexed.

/usr/share/pyshared/zope.security-3.8.3.egg-info/PKG-INFO is in python-zope.security 3.8.3-2ubuntu1.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
Metadata-Version: 1.0
Name: zope.security
Version: 3.8.3
Summary: Zope Security Framework
Home-page: http://pypi.python.org/pypi/zope.security
Author: Zope Foundation and Contributors
Author-email: zope-dev@zope.org
License: ZPL 2.1
Description: The Security framework provides a generic mechanism to implement security
        policies on Python objects.
        
        .. contents::
        
        ==============
        Zope3 Security
        ==============
        
        Introduction
        ------------
        
        The Security framework provides a generic mechanism to implement security
        policies on Python objects.  This introduction provides a tutorial of the
        framework explaining concepts, design, and going through sample usage from the
        perspective of a Python programmer using the framework outside of Zope.
        
        Definitions
        -----------
        
        Principal
        ~~~~~~~~~
        
        A generalization of a concept of a user.
        
        Permission
        ~~~~~~~~~~
        
        A kind of access, i.e. permission to READ vs. permission to WRITE.
        Fundamentally the whole security framework is organized around checking
        permissions on objects.
        
        Purpose
        -------
        
        The security framework's primary purpose is to guard and check access to
        Python objects.  It does this by providing mechanisms for explicit and
        implicit security checks on attribute access for objects.  Attribute names are
        mapped onto permission names when checking access and the implementation of
        the security check is defined by the security policy, which receives the
        object, the permission name, and an interaction.
        
        Interactions are objects that represent the use of the system by one or more
        principals.  An interaction contains a list of participations, which
        represents the way a single principal participates in the interaction.  An
        HTTP request is one example of a participation.
        
        Its important to keep in mind that the policy provided is just a default, and
        it can be substituted with one which doesn't care about principals or
        interactions at all.
        
        Framework Components
        --------------------
        
        Low Level Components
        ~~~~~~~~~~~~~~~~~~~~
        
        These components provide the infrastructure for guarding attribute access and
        providing hooks into the higher level security framework.
        
        Checkers
        ~~~~~~~~
        
        A checker is associated with an object kind, and provides the hooks that map
        attribute checks onto permissions deferring to the security manager (which in
        turn defers to the policy) to perform the check.
        
        Additionally, checkers provide for creating proxies of objects associated with
        the checker.
        
        There are several implementation variants of checkers, such as checkers that
        grant access based on attribute names.
        
        Proxies
        ~~~~~~~
        
        Wrappers around Python objects that implicitly guard access to their wrapped
        contents by delegating to their associated checker.  Proxies are also viral in
        nature, in that values returned by proxies are also proxied.
        
        High Level Components
        ---------------------
        
        Security Management
        ~~~~~~~~~~~~~~~~~~~
        
        Provides accessors for setting up interactions and the global security policy.
        
        Interaction
        ~~~~~~~~~~~
        
        Stores transient information on the list of participations.
        
        Participation
        ~~~~~~~~~~~~~
        
        Stores information about a principal participating in the interaction.
        
        Security Policy
        ~~~~~~~~~~~~~~~
        
        Provides a single method that accepts the object, the permission, and the
        interaction of the access being checked and is used to implement the
        application logic for the security framework.
        
        Narrative (agent sandbox)
        -------------------------
        
        As an example we take a look at constructing a multi-agent distributed system,
        and then adding a security layer using the Zope security model onto it.
        
        Scenario
        ~~~~~~~~
        
        Our agent simulation consists of autonomous agents that live in various agent
        homes/sandboxes and perform actions that access services available at their
        current home.  Agents carry around authentication tokens which signify their
        level of access within any given home.  Additionally agents attempt to migrate
        from home to home randomly.
        
        The agent simulation was constructed separately from any security aspects.
        Now we want to define and integrate a security model into the simulation.  The
        full code for the simulation and the security model is available separately;
        we present only relevant code snippets here for illustration as we go through
        the implementation process.
        
        For the agent simulation we want to add a security model such that we group
        agents into two authentication groups, "norse legends", including the
        principals thor, odin, and loki, and "greek men", including prometheus,
        archimedes, and thucydides.
        
        We associate permissions with access to services and homes.  We differentiate
        the homes such that certain authentication groups only have access to services
        or the home itself based on the local settings of the home in which they
        reside.
        
        We define the homes/sandboxes
        
          - origin - all agents start here, and have access to all
            services here.
        
          - valhalla - only agents in the authentication group 'norse
            legend' can reside here.
        
          - jail - all agents can come here, but only 'norse legend's
            can leave or access services.
        
        
        Process
        ~~~~~~~
        
        Loosely we define a process for implementing this security model
        
          - mapping permissions onto actions
        
          - mapping authentication tokens onto permissions
        
          - implementing checkers and security policies that use our
            authentication tokens and permissions.
        
          - binding checkers to our simulation classes
        
          - inserting the hooks into the original simulation code to add
            proxy wrappers to automatically check security.
        
          - inserting hooks into the original simulation to register the
            agents as the active principal in an interaction.
        
        
        Defining a Permission Model
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~
        
        We define the following permissions::
        
           NotAllowed = 'Not Allowed'
           Public = Checker.CheckerPublic
           TransportAgent = 'Transport Agent'
           AccessServices = 'Access Services'
           AccessAgents = 'Access Agents'
           AccessTimeService = 'Access Time Services'
           AccessAgentService = 'Access Agent Service'
           AccessHomeService = 'Access Home Service'
        
        and create a dictionary database mapping homes to authentication groups which
        are linked to associated permissions.
        
        
        Defining and Binding Checkers
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        
        Checkers are the foundational unit for the security framework.  They define
        what attributes can be accessed or set on a given instance.  They can be used
        implicitly via Proxy objects, to guard all attribute access automatically or
        explicitly to check a given access for an operation.
        
        Checker construction expects two functions or dictionaries, one is used to map
        attribute names to permissions for attribute access and another to do the same
        for setting attributes.
        
        We use the following checker factory function::
        
           def PermissionMapChecker(permissions_map={},
                                    setattr_permission_func=NoSetAttr):
               res = {}
               for k,v in permissions_map.items():
                   for iv in v:
                       res[iv]=k
               return checker.Checker(res.get, setattr_permission_func)
        
           time_service_checker = PermissionMapChecker(
                                          # permission : [methods]
                                          {'AccessTimeService':['getTime']}
                                          )
        
        with the NoSetAttr function defined as a lambda which always return the
        permission `NotAllowed`.
        
        To bind the checkers to the simulation classes we register our checkers with
        the security model's global checker registry::
        
           import sandbox_simulation
           from zope.security.checker import defineChecker
           defineChecker(sandbox_simulation.TimeService, time_service_checker)
        
        
        Defining a Security Policy
        ~~~~~~~~~~~~~~~~~~~~~~~~~~
        
        We implement our security policy such that it checks the current agent's
        authentication token against the given permission in the home of the object
        being accessed::
        
          class SimulationSecurityPolicy:
        
              implements(ISecurityPolicy)
        
              createInteraction = staticmethod(simpleinteraction.createInteraction)
        
              def checkPermission(self, permission, object, interaction):
        
                  home = object.getHome()
                  db = getattr(SimulationSecurityDatabase, home.getId(), None)
        
                  if db is None:
                      return False
        
                  allowed = db.get('any', ())
                  if permission in allowed or ALL in allowed:
                      return True
        
                  if interaction is None:
                      return False
                  if not interaction.participations:
                      return False
                  for participation in interaction.participations:
                      token = participation.principal.getAuthenticationToken()
                      allowed = db.get(token, ())
                      if permission not in allowed:
                          return False
        
                  return True
        
        There are no specific requirements for the interaction class, so we can just
        use `zope.security.simpleinteraction.Interaction`.
        
        Since an interaction can have more than one principal, we check that *all* of
        them are given the necessary permission.  This is not really necessary since
        we only create interactions with a single active principal.
        
        There is some additional code present to allow for shortcuts in defining the
        permission database when defining permissions for all auth groups and all
        permissions.
        
        
        Integration
        ~~~~~~~~~~~
        
        At this point we have implemented our security model, and we need to integrate
        it with our simulation model.  We do so in three separate steps.
        
        First we make it such that agents only access homes that are wrapped in a
        security proxy.  By doing this all access to homes and services (proxies have
        proxied return values for their methods) is implicitly guarded by our security
        policy.
        
        The second step is that we want to associate the active agent with the
        security context so the security policy will know which agent's authentication
        token to validate against.
        
        The third step is to set our security policy as the default policy for the
        Zope security framework.  It is possible to create custom security policies at
        a finer grained than global, but such is left as an exercise for the reader.
        
        
        Interaction Access
        ~~~~~~~~~~~~~~~~~~
        
        The *default* implementation of the interaction management interfaces defines
        interactions on a per thread basis with a function for an accessor.  This
        model is not appropriate for all systems, as it restricts one to a single
        active interaction per thread at any given moment.  Reimplementing the
        interaction access methods though is easily doable and is noted here for
        completeness.
        
        
        Perspectives
        ~~~~~~~~~~~~
        
        It's important to keep in mind that there is a lot more that is possible using
        the security framework than what's been presented here.  All of the
        interactions are interface based, such that if you need to re-implement the
        semantics to suite your application a new implementation of the interface will
        be sufficient.  Additional possibilities range from restricted interpreters
        and dynamic loading of untrusted code to non Zope web application security
        systems.  Insert imagination here ;-).
        
        
        Zope Perspective
        ~~~~~~~~~~~~~~~~
        
        A Zope3 programmer will never commonly need to interact with the low level
        security framework.  Zope3 defines a second security package over top the low
        level framework and authentication sources and checkers are handled via zcml
        registration.  Still those developing Zope3 will hopefully find this useful as
        an introduction into the underpinnings of the security framework.
        
        
        Code
        ~~~~
        
        The complete code for this example is available.
        
        - sandbox.py - the agent framework
        
        - sandbox_security.py - the security implementation and binding to the agent
          framework.
        
        
        Authors
        ~~~~~~~
        
        - Kapil Thangavelu <hazmat at objectrealms.net>
        - Guido Wesdorp <guido at infrae.com>
        - Marius Gedminas <marius at pov.lt>
        
        
        
        ======================
        Untrusted interpreters
        ======================
        
        Untrusted programs are executed by untrusted interpreters.  Untrusted
        interpreters make use of security proxies to prevent un-mediated
        access to assets.  An untrusted interpreter defines an environment for
        running untrusted programs. All objects within the environment are
        either:
        
        - "safe" objects created internally by the environment or created in
          the course of executing the untrusted program, or
        
        - "basic" objects
        
        - security-proxied non-basic objects
        
        The environment includes proxied functions for accessing objects
        outside of the environment.  These proxied functions provide the only
        way to access information outside the environment.  Because these
        functions are proxied, as described below, any access to objects
        outside the environment is mediated by the target security functions.
        
        Safe objects are objects whose operations, except for attribute
        retrieval, and methods access only information stored within the
        objects or passed as arguments.  Safe objects contained within the
        interpreter environment can contain only information that is already
        in the environment or computed directly from information that is
        included in the environment. For this reason, safe objects created
        within the environment cannot be used to directly access information
        outside the environment.
        
        Safe objects have some attributes that could (very) indirectly be used
        to access assets. For this reason, an untrusted interpreter always
        proxies the results of attribute accesses on a safe objects.
        
        Basic objects are safe objects that are used to represent elemental
        data values such as strings and numbers.  Basic objects require a
        lower level of protection than non-basic objects, as will be described
        detail in a later section.
        
        Security proxies mediate all object operations.  Any operation
        access is checked to see whether a subject is authorized to perform
        the operation.  All operation results other than basic objects are, in
        turn, security proxied.  Security proxies will be described in greater
        detail in a later section.  Any operation on a security proxy that
        results in a non-basic object is also security proxied.
        
        All external resources needed to perform an operation are security
        proxied.
        
        Let's consider the trusted interpreter for evaluating URLs.  In
        operation 1 of the example, the interpreter uses a proxied method for
        getting the system root object.  Because the method is proxied, the
        result of calling the method and the operation is also proxied.
        
        The interpreter has a function for traversing objects.  This function
        is proxied.  When traversing an object, the function is passed an
        object and a name.  In operation 2, the function is passed the result
        of operation 1, which is the proxied root object and the name 'A'.  We
        may traverse an object by invoking an operation on it.  For example,
        we may use an operation to get a sub-object. Because any operation on a
        proxied object returns a proxied object or a basic object, the result
        is either a proxied object or a basic object.  Traversal may also look
        up a component.  For example, in operation 1, we might look up a
        presentation component named "A" for the root object.  In this case,
        the external object is not proxied, but, when it is returned from the
        traversal function, it is proxied (unless it is a a basic object)
        because the traversal function is proxied, and the result of calling a
        proxied function is proxied (unless the result is a basic object).
        Operation 3 proceeds in the same way.
        
        When we get to operation 4, we use a function for computing the
        default presentation of the result of operation 3. As with traversal,
        the result of getting the default presentation is either a proxied
        object or a basic object because the function for getting the default
        presentation is proxied.
        
        When we get to the last operation, we have either a proxied object or a
        basic object.  If the result of operation 4 is a basic object, we
        simply convert it to a string and return it as the result page.  If
        the result of operation 4 is a non-basic object, we invoke a render
        operation on it and return the result as a string.
        
        Note that an untrusted interpreter may or may not provide protection
        against excessive resource usage.  Different interpreters will provide
        different levels of service with respect to limitations on resource
        usage.
        
        If an untrusted interpreter performs an attribute access, the trusted
        interpreter must proxy the result unless the result is a basic object.
        
        In summary, an untrusted interpreter assures that any access to assets
        is mediated through security proxies by creating an environment to run
        untrusted code and making sure that:
        
        - The only way to access anything from outside of the environment is
          to call functions that are proxied in the environment.
        
        - Results of any attribute access in the environment are proxied
          unless the results are basic objects.
        
        Security proxies
        ----------------
        
        Security proxies are objects that wrap and mediate access to objects.
        
        The Python programming language used by Zope defines a set of specific
        named low-level operations.  In addition to operations, Python objects
        can have attributes, used to represent data and methods.  Attributes
        are accessed using a dot notation. Applications can, and usually do,
        define methods to provide extended object behaviors.  Methods are
        accessed as attributes through the low-level operation named
        "__getattribute__".  The Python code::
        
           a.b()
        
        invokes 2 operations:
        
          1. Use the low-level `__getattribute__` operation with the name "b".
        
          2. Use the low-level '__call__' operation on the result of the first
             operation.
        
        For all operations except the `__getattribute__` and
        `__setattribute__` operations, security proxies have a permission
        value defined by the permission-declaration subsystem.  Two special
        permission values indicate that access is either forbidden (never
        allowed) or public (always allowed).  For all other permission values,
        the authorization subsystem is used to decide whether the subject has
        the permission for the proxied object.  If the subject has the
        permission, then access to the operation is allowed. Otherwise, access
        is denied.
        
        For getting or setting attributes, a proxy has permissions for getting
        and a permission for setting attribute values for a given attribute
        name.  As described above, these permissions may be one of the two
        special permission values indicating forbidden or public access, or
        another permission value that must be checked with the authorization
        system.
        
        For all objects, Zope defines the following operations to be always public:
        
          comparison
             "__lt__", "__le__", "__eq__", "__gt__", "__ge__", "__ne__"
        
          hash
             "__hash__"
        
          boolean value
             "__nonzero__"
        
          class introspection
             "__class__"
        
          interface introspection
            "__providedBy__", "__implements__"
        
          adaptation
            "__conform__"
        
          low-level string representation
            "__repr__"
        
        The result of an operation on a proxied object is a security proxy
        unless the result is a basic value.
        
        Basic objects
        -------------
        
        Basic objects are safe immutable objects that contain only immutable
        subobjects. Examples of basic objects include:
        
        - Strings,
        
        - Integers (long and normal),
        
        - Floating-point objects,
        
        - Date-time objects,
        
        - Boolean objects (True and False), and
        
        - The special (nil) object, None.
        
        Basic objects are safe, so, as described earlier, operations on basic
        objects, other than attribute access, use only information contained
        within the objects or information passed to them.  For this reason,
        basic objects cannot be used to access information outside of the
        untrusted interpreter environment.
        
        The decision not to proxy basic objects is largely an optimization.
        It allows low-level safe computation to be performed without
        unnecessary overhead,
        
        Note that a basic object could contain sensitive information, but such
        a basic object would need to be obtained by making a call on a proxied
        object.  Therefore, the access to the basic object in the first place
        is mediated by the security functions.
        
        Rationale for mutable safe objects
        ----------------------------------
        
        Some safe objects are not basic. For these objects, we proxy the
        objects if they originate from outside of the environment.  We do this
        for two reasons:
        
        1. Non-basic objects from outside the environment need to be proxied
           to prevent unauthorized access to information.
        
        2. We need to prevent un-mediated change of information from outside of
           the environment.
        
        We don't proxy safe objects created within the environment.  This is
        safe to do because such safe objects can contain and provide access to
        information already in the environment.  Sometimes the interpreter or
        the interpreted program needs to be able to create simple data
        containers to hold information computed in the course of the program
        execution.  Several safe container types are provided for this
        purpose.
        
        
        =======
        CHANGES
        =======
        
        3.8.3 (2011-09-24)
        ------------------
        
        - Fixed a regression introduced in 3.8.1: ``zope.location``\'s LocationProxy
          did not get a security checker if ``zope.security.decorator`` was not
          imported manually. Now ``zope.security.decorator`` is imported in
          ``zope.security.proxy`` without re-introducing the circular import fixed in
          3.8.1.
        
        3.8.2 (2011-05-24)
        ------------------
        
        - Fix a test that failed on Python 2.7.
        
        
        3.8.1 (2011-05-03)
        ------------------
        
        - Fixed circular import beween ``zope.security.decorator`` and
          ``zope.security.proxy`` which led to an ``ImportError`` when only
          importing ``zope.security.decorator``.
        
        
        3.8.0 (2010-12-14)
        ------------------
        
        - Added tests for our own ``configure.zcml``.
        
        - Added ``zcml`` extra dependencies, run related tests only if
          ``zope.configuration`` is available.
        
        - Run tests related to the ``untrustedpython`` functionality only if
          ``RestrictedPython`` is available.
        
        
        3.7.3 (2010-04-30)
        ------------------
        
        - Prefer the standard libraries doctest module to the one from zope.testing.
        
        - Fixed directlyProvides IVocabularyFactory for PermissionIdsVocabulary in
          Python code, even if it's unnecessary because IVocabularyFactory is provided
          in zcml.
        
        - Removed the dependency on the zope.exceptions package: zope.security.checker
          now imports ``DuplicationError`` from zope.exceptions if available, otherwise
          it defines a package-specific ``DuplicationError`` class which inherits from
          Exception.
        
        
        3.7.2 (2009-11-10)
        ------------------
        
        - Added compatibility with Python 2.6 abstract base classes.
        
        
        3.7.1 (2009-08-13)
        ------------------
        
        - Fix for LP bug 181833 (from Gustavo Niemeyer). Before "visiting" a
          sub-object, a check should be made to ensure the object is still valid.
          Because garbage collection may involve loops, if you garbage collect an
          object, it is possible that the actions done on this object may modify the
          state of other objects. This may cause another round of garbage collection,
          eventually generating a segfault (see LP bug). The Py_VISIT macro does the
          necessary checks, so it is used instead of the previous code.
        
        
        3.7.0 (2009-05-13)
        ------------------
        
        - Made ``pytz`` a soft dependency:  the checker for ``pytz.UTC`` is
          created / tested only if the package is already present.  Run
          ``bin/test_pytz`` to run the tests with ``pytz`` on the path.
        
        
        3.6.3 (2009-03-23)
        ------------------
        
        - Ensure that simple zope.schema's VocabularyRegistry is used for
          PermissionVocabulary tests, because it's replaced implicitly in
          environments with zope.app.schema installed that makes that tests
          fail.
        
        - Fixed a bug in DecoratedSecurityCheckerDescriptor which made
          security-wrapping location proxied exception instances throw
          exceptions on Python 2.5.
          See https://bugs.launchpad.net/zope3/+bug/251848
        
        
        3.6.2 (2009-03-14)
        ------------------
        
        - Add zope.i18nmessageid.Message to non-proxied basic types. It's okay, because
          messages are immutable. It was done by zope.app.security before.
        
        - Add "__name__" and "__parent__" attributes to list of available by default.
          This was also done by zope.app.security package before.
        
        - Added PermissionsVocabulary and PermissionIdsVocabulary vocabularies
          to the ``zope.security.permission`` module. They were moved from
          the ``zope.app.security`` package.
        
        - Add zcml permission definitions for most common and useful permissions,
          like "zope.View" and "zope.ManageContent", as well as for the special
          "zope.Public" permission. They are placed in a separate "permissions.zcml"
          file, so it can be easily excluded/redefined. They are selected part of
          permissions moved from ``zope.app.security`` and used by many zope.*
          packages.
        
        - Add `addCheckerPublic` helper function in ``zope.security.testing`` module
          that registers the "zope.Public" permission as an IPermission utility.
        
        - Add security declarations for the ``zope.security.permisson.Permission``
          class.
        
        - Improve test coverage.
        
        
        3.6.1 (2009-03-10)
        ------------------
        
        - Use ``from`` imports instead of ``zope.deferred`` to avoid circular
          import problems, thus drop dependency on ``zope.deferredimport``.
        
        - Raise NoInteraction when zope.security.checkPermission is called
          without interaction being active (LP #301565).
        
        - Don't define security checkers for deprecated set types from the
          "sets" module on Python 2.6. It's discouraged to use them and
          `set` and `frozenset` built-in types should be used instead.
        
        - Change package's mailng list address to zope-dev at zope.org as
          zope3-dev at zope.org is now retired.
        
        - Remove old zpkg-related files.
        
        
        3.6.0 (2009-01-31)
        ------------------
        
        - Install decorated security checker support on LocationProxy from the
          outside.
        
        - Added support to bootstrap on Jython.
        
        - Moved the `protectclass` module from `zope.app.security` to this
          package to reduce the number of dependencies on `zope.app.security`.
        
        - Moved the <module> directive implementation from `zope.app.security`
          to this package.
        
        - Moved the <class> directive implementation from `zope.app.component`
          to this package.
        
        
        3.5.2 (2008-07-27)
        ------------------
        
        - Made C code compatible with Python 2.5 on 64bit architectures.
        
        
        3.5.1 (2008-06-04)
        ------------------
        
        - Add `frozenset`, `set`, `reversed`, and `sorted` to the list of safe
          builtins.
        
        
        3.5.0 (2008-03-05)
        ------------------
        
        - Changed title for ``zope.security.management.system_user`` to be more
          presentable.
        
        
        3.4.3 - (2009/11/26)
        --------------------
        
        - Backported a fix made by Gary Poster to the 3.4 branch:
          Fix for LP bug 181833 (from Gustavo Niemeyer). Before "visiting" a
          sub-object, a check should be made to ensure the object is still valid.
          Because garbage collection may involve loops, if you garbage collect an
          object, it is possible that the actions done on this object may modify the
          state of other objects. This may cause another round of garbage collection,
          eventually generating a segfault (see LP bug). The Py_VISIT macro does the
          necessary checks, so it is used instead of the previous code.
        
        
        3.4.2 - (2009/03/23)
        --------------------
        
        - Added dependency 'zope.thread' to setup.py, without the tests were
          failing.
        
        - Backported a fix made by Albertas Agejevas to the 3.4 branch. He
          fixed a bug in DecoratedSecurityCheckerDescriptor which made
          security-wrapping location proxied exception instances throw
          exceptions on Python 2.5.  See
          https://bugs.launchpad.net/zope3/+bug/251848
        
        
        3.4.1 - 2008/07/27
        ------------------
        
        - Made C code compatible with Python 2.5 on 64bit architectures.
        
        
        3.4.0 (2007-10-02)
        ------------------
        
        - Updated meta-data.
        
        
        3.4.0b5 (2007-08-15)
        --------------------
        
        - Bug: Fixed a circular import in the C implementation.
        
        
        3.4.0b4 (2007-08-14)
        --------------------
        
        - Bug: ``zope.security.management.system_user`` had an ugly/brittle id.
        
        
        3.4.0b3 (2007-08-14)
        --------------------
        
        - ``zope.security`` now works on Python 2.5
        
        - Bug: ``zope.security.management.system_user`` wasn't a valid principal
          (didn't provide IPrincipal).
        
        - Bug: Fixed inclusion of doctest to use the doctest module from
          ``zope.testing``. Now tests can be run multiple times without
          breaking. (#98250)
        
        
        3.4.0b2 (2007-06-15)
        --------------------
        
        - Bug: Removed stack extraction in newInteraction. When using eggs this is an
          extremly expensive function. The publisher is now more than 10 times faster
          when using eggs and about twice as fast with a zope trunk checkout.
        
        
        3.4.0b1
        -------
        
        - Temporarily fixed the hidden (and accidental) dependency on zope.testing to
          become optional.
        
        Note: The releases between 3.2.0 and 3.4.0b1 where not tracked as an
        individual package and have been documented in the Zope 3 changelog.
        
        
        3.2.0 (2006-01-05)
        ------------------
        
        - Corresponds to the verison of the zope.security package shipped as part of
          the Zope 3.2.0 release.
        
        - Removed deprecated helper functions, 'proxy.trustedRemoveSecurityProxy' and
          'proxy.getProxiedObject'.
        
        - Made handling of 'management.{end,restore}Interaction' more careful w.r.t.
          edge cases.
        
        - Made behavior of 'canWrite' consistent with 'canAccess':  if 'canAccess'
          does not raise 'ForbiddenAttribute', then neither will 'canWrite'.  See:
          http://www.zope.org/Collectors/Zope3-dev/506
        
        - Code style / documentation / test fixes.
        
        
        3.1.0 (2005-10-03)
        ------------------
        
        - Added support for use of the new Python 2.4 datatypes, 'set' and
          'frozenset', within checked code.
        
        - C security proxy acquired a dependency on the 'proxy.h' header from the
          'zope.proxy' package.
        
        - XXX: the spelling of the '#include' is bizarre!  It seems to be related to
          'zpkg'-based builds, and should likely be revisited.  For the moment, I have
          linked in the 'zope.proxy' package into our own 'include' directory.  See
          the subversion checkin: http://svn.zope.org/Zope3/?rev=37882&view=rev
        
        - Updated checker to avoid re-proxying objects which have and explicit
          '__Security_checker__' assigned.
        
        - Corresponds to the verison of the zope.security package shipped as part of
          the Zope 3.1.0 release.
        
        - Clarified contract of 'IChecker' to indicate that its 'check*' methods may
          raise only 'Forbidden' or 'Unauthorized' exceptions.
        
        - Added interfaces, ('IPrincipal', 'IGroupAwarePrincipal', 'IGroup', and
          'IPermission') specifying contracts of components in the security framework.
        
        - Code style / documentation / test fixes.
        
        
        3.0.0 (2004-11-07)
        ------------------
        
        - Corresponds to the version of the zope.security package shipped as part of
          the Zope X3.0.0 release.
        
Keywords: zope security policy principal permission
Platform: UNKNOWN
Classifier: Development Status :: 5 - Production/Stable
Classifier: Environment :: Web Environment
Classifier: Intended Audience :: Developers
Classifier: License :: OSI Approved :: Zope Public License
Classifier: Programming Language :: Python
Classifier: Natural Language :: English
Classifier: Operating System :: OS Independent
Classifier: Topic :: Internet :: WWW/HTTP
Classifier: Framework :: Zope3