text:
PEP: 8015 Title: Organization of the Python community Author: Victor
Stinner Status: Rejected Type: Informational Topic: Governance
Content-Type: text/x-rst Created: 04-Oct-2018

Abstract

This PEP formalizes the current organization of the Python community and
proposes 3 main changes:

-   Formalize the existing concept of "Python teams";
-   Give more autonomy to Python teams;
-   Replace the BDFL (Guido van Rossum) with a new "Python Steering
    Committee" of 5 members which has limited roles: basically decide
    how decisions are taken, but don't take decisions.

PEPs are approved by a PEP delegate or by a vote (reserved to core
developers, need >= 2/3 majority).

PEP Rejection

PEP 8015 was rejected by a core developer vote described in PEP 8001 on
Monday, December 17, 2018.

PEP 8016 and the governance model it describes were chosen instead.

Rationale

This PEP describes the organization of the whole Python development
community, from Python users to the Python Steering Committee.
Describing all groups and all roles in the same document helps to make
the organization more consistent.

The number of governance changes is minimized to get a smooth transition
from the old BDFL organization to the new Steering Committee
organization.

One key design of the organization is to avoid decision bottlenecks.
Discussions and decisions are distributed into Python teams where
experts in each topic can be found. The expectation is smoother
discussions on PEPs: fewer people with better knowledge of the topic.

Previously, most decisions have been taken by the Benevolent Dictator
For Life (BDFL), Guido van Rossum. The growing popularity of Python
increased the pressure on a single person. The proposed organization
distributes decisions and responsibilities to reduce the pressure and
avoid wearing any individual down.

To keep most of the decision power within the hands of the community,
the Python Steering Committee has very limited roles. The idea is to
reduce the risk that a group of people or companies "takes over" the
Python project through just a couple individuals. The project must
remain autonomous and open to everybody.

The most sensitives PEPs are decided by democracy: a vote reserved to
core developers, see the PEP process section below for the voting
method.

Common Guidelines

-   The Python community is open to everyone.
-   Members must respect the Python Community Code of Conduct which
    ensures that discussions remain constructive and that everybody
    feels welcomed.
-   Python is and will remain an autonomous project.
-   People with decisions power should reflect the diversity of its
    users and contributors.

Community Organization

Right now, there are different group of people involved in the Python
project. The more involved you are, the more decisions power you get. It
is important that the people acceding to the deepest group are the most
trusted ones.

This PEP formalizes the following groups:

-   Python Users
-   Python Contributors
-   Python Teams Members
-   Python Core Developers
-   Python Steering Committee Members
-   PSF Code of Conduct Workgroup

Python Users

This is the largest group: anyone who uses Python.

Python Contributors

Once a Python user sends an email to a Python mailing list, comments on
the Python bug tracker, proposes or reviews a Python change, they become
a Python contributor.

Python Teams

Python became too big to work as a unique team anymore, people naturally
have grouped themselves as teams to work more closely on specific
topics, sometimes called "Special Interest Group" (SIG).

When enough developers are interested by a specific topic, they can
create a new team. Usually, the main action is to ask the Python
postmaster to create a new "SIG" mailing list, but the team can choose
to use a different communication channel.

Team members are Python contributors and Python core developers. The
team is self-organized and is responsible to select who can join the
team and how.

Team members can get the bug triage permission on the team bug tracker
component. The more involved in a team you are, the more decisions power
and responsibilities you get.

A team might become allowed to decide on their own PEPs, but only the
Python Steering Committee can allow that (and it has the power to revoke
it as well). Such a case is exceptional, currently a single team has
such permission: the Packaging Team.

See Annex: Examples of Python Teams.

Python Core Developers

One restricted definition of a core developer is the ability to merge a
change (anywhere in the code) and have the bug triage permission (on all
bug tracker components).

Core developers are developers who are proven to have the required
skills to decide if a change can be approved or must be rejected, but
also (and this is more important) what changes should not be made.
Python has a long history, big constraints on backward compatibility,
high quality standards (ex: changes require new tests). For these
reasons, becoming a core can take several months or longer.

Becoming a core developer means more responsibilities. For example, if a
developer merges a change, they become responsible for regressions and
for the maintenance of that modified code.

Core developers are expected to be exemplary when it comes to the Code
of Conduct. They are encouraged to mentor contributors.

Promote a contributor as core developer

Once an existing core developer considers that a contributor is ready to
join the core group, to become a core developer, that core developer
asks the contributor if they would like to become a core developer. If
the contributor is interested in such new responsibilities, a vote is
organized.

The vote is reserved to core developers, is public, and is open for 1
week. Usually the core developer who proposes the promotion has to
describe the work and skills of the candidate in the description of the
vote. A contributor is only promoted if two thirds (>= 2/3) of votes
approve ("+1") the promotion. Only "+1" and "-1" votes are accounted;
other votes (ex: null, "-0", "+0.5") are ignored.

If the candidate is promoted, usually they get a mentor for 1 month to
help them to handle new responsibilities.

If the candidate is not promoted, a new vote can be organized later,
when the candidate gets the missing skills, for example 6 months later.

Python Steering Committee

The Python Steering Committee is made of the most trusted core
developers since it has the most decision power. The roles of this group
are strictly limited to ensure that Python keeps its autonomy and
remains open.

The Python Steering Committee is composed of 5 members. They are elected
for 3 years and 1/3 is replaced every year (first year: 1, second year:
2, third year: 2). This way, a member will stay for one full Python
release and the committee composition will be updated frequently. A
committee member can be a candidate for the seat they are leaving. There
are no term limits.

Committee members must be Python core developers. It is important that
the members of the committee reflect the diversity of Python' users and
contributors. A small step to ensure that is to enforce that only 2
members (strictly less than 50% of the 5 members) can work for the same
employer (same company or subsidiaries of the same company).

The size of 5 members has been chosen for the members diversity and to
ensure that the committee can continue to work even if a member becomes
unavailable for an unknown duration.

Python Steering Committee Roles

Python Steering Committee roles:

-   Decide how a PEP is approved (or rejected or deferred).
-   Grant or revoke permissions to a Python team. For example, allow a
    team to give the bug triage permission (on the team component) to a
    contributor.

To decide how a PEP is approved (or rejected or deferred), there are two
options:

-   The committee elects a PEP delegate (previously known as
    "BDFL-delegate"): a core developer who will take the final decision
    for the specific PEP. The committee select the PEP delegate who can
    be proposed by the Python team where the PEP is discussed.
-   The committee can organize a vote on the PEP, see PEP process for
    the vote organization. The committee decides when the vote is
    organized. A vote is preferred for changes affecting all Python
    users, like language changes.

The committee keeps the "vision" and consistency of Python. It also
makes sure that important features reach completion. Their ability to
pick PEP delegates is meant to help them to achieve that goal.

Election of Python Steering Committee Members

The vote is organized by the Steering Committee. It is announced 3 weeks
in advance: candidates have to apply during this period. The vote is
reserved to core developers and is open for 1 week. To avoid
self-censorship, the vote uses secret ballots: avoid the risk of
hostility from someone who may get more power (if they get elected).

The vote uses the Schulze/Beatpath/CSSD variant of the Condorcet method
using an online service like Condorcet Internet Voting Service (CIVS).
This voting method reduces the risk of tie. It also produces a ranking
of all candidates, needed for the creation of the committee.

In case of tie, a new vote is organized immediately between candidates
involved in the tie using the same voting method and also during 1 week.
If the second vote leads to a tie again, the current Steering Committee
is responsible to select the elected member(s).

If a committee member steps down, a new vote is organized to replace
them.

If the situation of a committee member changes in a way that no longer
satisfies the committee constraint (ex: they move to the same company as
two other committee members), they have to resign. If the employer of a
member is acquired by the employer of two other members, the member with
the mandate ending earlier has to resign once the acquisition completes.

Election Creating the Python Steering Committee Members

To bootstrap the process, 5 members are elected at the committee
creation. The vote follows the same rules than regular committee votes,
except that the election needs 5 members, and the vote is organized by
the PSF Board.

In a council election, if 3 of the top 5 vote-getters work for the same
employer, then whichever of them ranked lowest is disqualified and the
6th-ranking candidate moves up into 5th place; this is repeated until a
valid council is formed.

In case of tie, a second vote is organized immediately between
candidates involved in the tie and following candidates to fill the
remaining seats. The vote follows the same rules as the regular
committee vote. If the second vote still result in a tie, the PSF Board
is responsible to elect members and decide their position in the vote
result.

The order in the vote result must be unique for elected members: #1 and
#2 are elected for 3 years, #2 and #3 for 2 years, and #5 for 1 year.

Example of vote result with a tie:

-   A
-   B
-   C
-   D
-   E, F
-   G
-   ...

The first 4 candidates (A, B, C and D) are elected immediately. If E
works for the same employer than two other elected member, F is also
elected. Otherwise, a second vote is organized for the 5th seat between
E and F.

Special Case: Steering Committee Members And PEPs

A committee member can be a PEP delegate.

A committee member can propose a PEP, but cannot be the PEP delegate of
their own PEP.

When the committee decides that a PEP must be voted, committee members
can vote as they are also core developers, but they don't have more
power than other core developer.

PSF Code of Conduct Workgroup

Charter

The workgroup's purpose is to foster a diverse and inclusive Python
community by enforcing the PSF code of conduct, along with providing
guidance and recommendations to the Python community on codes of
conduct, that supports the PSF mission of “ongoing development of
Python-related technology and educational resources”.

We work toward this common goal in three ways:

-   Review, revise, and advise on policies relating to the PSF code of
    conducts and other communities that the PSF supports. This includes
    any #python chat community & python.org email list under PSF
    jurisdiction.
-   Create a standard set of codes of conduct and supporting documents
    for multiple channels of interaction such as, but not limited to,
    conferences, mailing lists, slack/IRC, code repositories, and more.
-   Develop training materials and other processes to support Python
    community organizers in implementing and enforcing the code of
    conduct.

The organization of this workgroup is defined by the ConductWG Charter.

Special Case: Ban a core developer

As any other member of the Python community, the PSF Code of Conduct
Workgroup can ban a core developer for a limited amount of time. In this
case, the core developer immediately loses their core developer status.
Core developers are expected to be exemplary when it comes to the Code
of Conduct.

In general, a ban is only the last resort action when all other options
have been exhausted.

At the end of the ban, the developer is allowed to contribute again as a
regular contributor.

If the developer changes their behavior, another core developer can
organize a new vote to propose the developer for promotion to core
developer. The vote follows the same process than for any other Python
contributor.

PEP process

There are 2 main roles on PEPs:

-   PEP Authors
-   PEP Delegate

PEP Authors do their best to write high quality PEP.

The PEP delegate is responsible to help the authors to enhance their PEP
and is the one taking the final decision (accept, reject or defer the
PEP). They can also help to guide the discussion.

If no decision is taken, the authors can propose again the PEP later
(ex: one year later), if possible with new data to motivate the change.
A PEP Delegate can also choose to mark a PEP as "Deferred" to not reject
the PEP and encourage to reopen the discussion later.

PEPs specific to a Python team are discussed on the team mailing list.
PEPs impacting all Python developers (like language changes) must be
discussed on the python-dev mailing list.

Vote on a PEP

When the Python Steering Committee decides that a PEP needs a wider
approval, a vote is organized.

The vote is reserved to core developers, is public, is announced 1 week
in advance, and is open for 1 week. The PEP can still be updated during
the 1 week notice, but must not be modified during the vote. Such vote
happens on the mailing list where the PEP has been discussed. The
committee decides when the vote is organized. The PEP must have been
discussed for a reasonable amount of time before it is put to vote.

A PEP is only approved if two thirds (>= 2/3) of votes approve ("+1")
the PEP. Only "+1" and "-1" votes are accounted; other votes (ex: null,
"-0", "+0.5") are ignored.

A PEP can only be approved or rejected by a vote, not be deferred.

Lack of Decision

If a discussion fails to reach a consensus, if the Python Steering
Committee fail to choose a PEP delegate, or if a PEP delegate fails to
take a decision, the obvious risk is that Python fails to evolve.

That's fine. Sometimes, doing nothing is the wisest choice.

Change this PEP

The first version of this PEP has been written after Guido van Rossum
decided to resign from his role of BDFL in July 2018. Before this PEP,
the roles of Python community members have never been formalized. It is
difficult to design a perfect organization at the first attempt. This
PEP can be updated in the future to adjust the organization, specify how
to handle corner cases and fix mistakes.

Any change to this PEP must be validated by a vote. The vote is
announced 3 weeks in advance, is reserved to core developers, happens in
public on the python-committers mailing list, and is open for 1 week.
The proposed PEP change can still be updated during the 3 weeks notice,
but must not be modified during the vote.

The change is only approved if four fifths (>= 4/5) of votes approve
("+1") the change. Only "+1" and "-1" votes are accounted; other votes
(ex: null, "-0", "+0.5") are ignored.

Annex: Summary on votes

  Vote                  Notice    Open     Ballot    Method
  --------------------- --------- -------- --------- -----------------------------------
  Promote contributor   none      1 week   public    >= 2/3 majority
  PEP                   1 week    1 week   public    >= 2/3 majority
  Change this PEP       3 weeks   1 week   public    >= 4/5 majority
  Steering Committee    3 weeks   1 week   private   Condorcet (Schulze/Beatpath/CSSD)

All these votes are reserved to core developers.

Annex: Examples of Python Teams

Below are examples of some Python teams (the list will not be kept up to
date in this PEP).

Packaging Team

The packaging team runs its own PEP category and can approve (or reject)
their own PEPs.

-   Website: packaging.python.org
-   Mailing list: distutils-sig
-   Bug tracker component: Distutils
-   Example of members: Paul Moore, Alyssa Coghlan, Donald Stuff
-   Stdlib module: distutils
-   Current PEP delegate: Paul Moore

IDLE Team

IDLE is a special case in the Python standard library: it's a whole
application, not just a module. For this reason, it has been decided
that the code will be the same in all Python stable branches (whereas
the stdlib diverges in newer stable branches).

-   Bug tracker component: IDLE
-   Example of members: Terry Reedy, Cheryl Sabella, Serhiy Storchaka
-   Stdlib module: idlelib

Mentorship Team

Becoming a core developer is long and slow process. Mentorship is an
efficient way to train contributors as future core developers and build
a trust relationship.

-   Websites:
    -   https://www.python.org/dev/core-mentorship/
    -   https://devguide.python.org/
-   Repository: https://github.com/python/devguide
-   Mailing list: core-mentorship (private archives)
-   Example of members: Guido van Rossum, Carol Willing, Victor Stinner

Note: The group is not responsible to promote core developers.

Documentation Team

-   Mailing list: doc-sig
-   Bug tracker component: Documentation
-   GitHub tag: type-doc
-   Example of members: Julien Palard, INADA Naoki, Raymond Hettinger.

The team also manages documentation translations.

See also the Mentorship team which maintains the "Devguide".

Security Team

-   Website: https://www.python.org/news/security/
-   Mailing lists:
    -<EMAIL_ADDRESS>(to report vulnerabilities)
    -   security-sig (public list)
-   Stdlib modules: hashlib, secrets and ssl
-   Example of members: Christian Heimes, Benjamin Peterson

The<EMAIL_ADDRESS>mailing list is invite-only: only members of the
"Python Security Response Team" (PSRT) can read emails and reply;
whereas security-sig is public.

Note: This team rarely proposed PEPs.

Performance Team

-   Website: https://speed.python.org/
-   Mailing list: speed
-   Repositories:
    -   https://github.com/python/performance
    -   https://github.com/tobami/codespeed
-   Bug tracker type: Performance
-   GitHub label: type-performance
-   Stdlib module: cProfile, profile, pstats and timeit
-   Example of members: Victor Stinner, INADA Naoki, Serhiy Storchaka

Usually PEPs involving performance impact everybody and so are discussed
on the python-dev mailing list, rather than the speed mailing list.

Asynchronous Programming Team

-   Website: https://docs.python.org/dev/library/asyncio.html
-   Mailing list: async-sig
-   Bug tracker component: asyncio
-   GitHub label: expert-asyncio
-   Stdlib modules: asyncio and contextvars
-   Example of members: Andrew Sveltov, Yury Selivanov

PEP only modifying asyncio and contextvars can be discussed on the
async-sig mailing list, whereas changes impacting the Python language
must be discussed on python-dev.

Type Hints Team

-   Website: http://mypy-lang.org/
-   Repository: https://github.com/python/typing
-   GitHub label for mypy project: topic-pep-484
-   Stdlib modules: typing
-   Example of members: Guido van Rossum, Ivan Levkivskyi, Jukka
    Lehtosalo, Łukasz Langa, Mark Shannon.

Note: There is a backport for Python 3.6 and older, see typing on PyPI.

Version History

History of this PEP:

-   Version 7: Adjust the Steering Committee
    -   The Steering Committee is now made of 5 people instead of 3.
    -   There are no term limits (instead of a limit of 2 mandates: 6
        years in total).
    -   A committee member can now be a PEP delegate.
-   Version 6: Adjust votes
    -   Specify the Condorcet method: use Schulze/Beatpath/CSSD variant
        to elect Python Steering Committee members. Specify how to deal
        with tie and the constraint on the employers.
    -   Vote on promoting a contributor and on PEPs now requires >= 2/3
        rather than 50%+1.
    -   Vote on changing this PEP now requires >= 4/5 rather than 50%+1.
    -   Explain how to deal with a company acquisition.
-   Version 5: Election of Python Steering Committee Members uses secret
    ballots
-   Version 4:
    -   Adjust votes: open for 1 week instead of 1 month, and announced
        in advance.
    -   Rename the "Python Core Board" to the "Python Steering
        Committee";
    -   Clarify that this committee doesn't approve PEPs and that
        committee members cannot cumulate more than 2 mandates;
    -   Add the "Type Hints" team to the annex.
-   Version 3: Add "Special Case: Ban a core developer" and "How to
    update this PEP" sections.
-   Version 2: Rename the "Python board" to the "Python Core Board", to
    avoid confusion with the PSF Board.
-   Version 1: First version posted to python-committers and
    discuss.python.org.

Copyright

This document has been placed in the public domain.


text:
PEP: 466 Title: Network Security Enhancements for Python 2.7.x Version:
$Revision$ Last-Modified: $Date$ Author: Alyssa Coghlan
<EMAIL_ADDRESS>Status: Final Type: Standards Track Content-Type:
text/x-rst Created: 23-Mar-2014 Python-Version: 2.7.9 Post-History:
23-Mar-2014, 24-Mar-2014, 25-Mar-2014, 26-Mar-2014, 16-Apr-2014
Resolution:
https://mail.python.org/pipermail/python-dev/2014-April/134163.html

Abstract

Most CPython tracker issues are classified as errors in behaviour or
proposed enhancements. Most patches to fix behavioural errors are
applied to all active maintenance branches. Enhancement patches are
restricted to the default branch that becomes the next Python version.

This cadence works reasonably well during Python's normal 18-24 month
feature release cycle, which is still applicable to the Python 3 series.
However, the age of the standard library in Python 2 has now reached a
point where it is sufficiently far behind the state of the art in
network security protocols for it to be causing real problems in use
cases where upgrading to Python 3 in the near term may not be feasible.

In recognition of the additional practical considerations that have
arisen during the 4+ year maintenance cycle for Python 2.7, this PEP
allows a critical set of network security related features to be
backported from Python 3.4 to upcoming Python 2.7.x maintenance
releases.

While this PEP does not make any changes to the core development team's
handling of security-fix-only branches that are no longer in active
maintenance, it does recommend that commercial redistributors providing
extended support periods for the Python standard library either backport
these features to their supported versions, or else explicitly disclaim
support for the use of older versions in roles that involve connecting
directly to the public internet.

New security related features in Python 2.7 maintenance releases

Under this proposal, the following features will be backported from
Python 3.4 to upcoming Python 2.7.x maintenance releases:

-   in the os module:
    -   persistent file descriptor for os.urandom().
-   in the hmac module:
    -   constant time comparison function (hmac.compare_digest()).
-   in the hashlib module:
    -   password hashing function (hashlib.pbkdf2_hmac()).
    -   details of hash algorithm availability
        (hashlib.algorithms_guaranteed and
        hashlib.algorithms_available).
-   in the ssl module:
    -   this module is almost entirely synchronised with its Python 3
        counterpart, bringing TLSv1.x settings, SSLContext manipulation,
        Server Name Indication, access to platform certificate stores,
        standard library support for peer hostname validation and more
        to the Python 2 series.
    -   the only ssl module features not backported under this policy
        are the ssl.RAND_* functions that provide access to OpenSSL's
        random number generation capabilities - use os.urandom()
        instead.

As a general change in maintenance policy, permission is also granted to
upgrade to newer feature releases of OpenSSL when preparing the binary
installers for new maintenance releases of Python 2.7.

This PEP does NOT propose a general exception for backporting new
features to Python 2.7 - every new feature proposed for backporting will
still need to be justified independently. In particular, it will need to
be explained why relying on an independently updated backport on the
Python Package Index instead is not an acceptable solution.

Implementation status

This PEP originally proposed adding all listed features to the Python
2.7.7 maintenance release. That approach proved to be too ambitious
given the limited time frame between the original creation and
acceptance of the PEP and the release of Python 2.7.7rc1. Instead, the
progress of each individual accepted feature backport is being tracked
as an independent enhancement targeting Python 2.7.

Implemented for Python 2.7.7:

-   Issue #21306: backport hmac.compare_digest
-   Issue #21462: upgrade OpenSSL in the Python 2.7 Windows installers

Implemented for Python 2.7.8:

-   Issue #21304: backport hashlib.pbkdf2

Implemented for Python 2.7.9 (in development):

-   Issue #21308: backport specified ssl module features
-   Issue #21307: backport remaining specified hashlib module features
-   Issue #21305: backport os.urandom shared file descriptor change

Backwards compatibility considerations

As in the Python 3 series, the backported ssl.create_default_context()
API is granted a backwards compatibility exemption that permits the
protocol, options, cipher and other settings of the created SSL context
to be updated in maintenance releases to use higher default security
settings. This allows them to appropriately balance compatibility and
security at the time of the maintenance release, rather than at the time
of the original feature release.

This PEP does not grant any other exemptions to the usual backwards
compatibility policy for maintenance releases. Instead, by explicitly
encouraging the use of feature based checks, it is designed to make it
easier to write more secure cross-version compatible Python software,
while still limiting the risk of breaking currently working software
when upgrading to a new Python 2.7 maintenance release.

In all cases where this proposal allows new features to be backported to
the Python 2.7 release series, it is possible to write cross-version
compatible code that operates by "feature detection" (for example,
checking for particular attributes in a module), without needing to
explicitly check the Python version.

It is then up to library and framework code to provide an appropriate
warning and fallback behaviour if a desired feature is found to be
missing. While some especially security sensitive software MAY fail
outright if a desired security feature is unavailable, most software
SHOULD instead emit a warning and continue operating using a slightly
degraded security configuration.

The backported APIs allow library and application code to perform the
following actions after detecting the presence of a relevant network
security related feature:

-   explicitly opt in to more secure settings (to allow the use of
    enhanced security features in older maintenance releases of Python
    with less secure default behaviour)
-   explicitly opt in to less secure settings (to allow the use of newer
    Python feature releases in lower security environments)
-   determine the default setting for the feature (this MAY require
    explicit Python version checks to determine the Python feature
    release, but DOES NOT require checking for a specific maintenance
    release)

Security related changes to other modules (such as higher level
networking libraries and data format processing libraries) will continue
to be made available as backports and new modules on the Python Package
Index, as independent distribution remains the preferred approach to
handling software that must continue to evolve to handle changing
development requirements independently of the Python 2 standard library.
Refer to the Motivation and Rationale section for a review of the
characteristics that make the secure networking infrastructure worthy of
special consideration.

OpenSSL compatibility

Under this proposal, OpenSSL may be upgraded to more recent feature
releases in Python 2.7 maintenance releases. On Linux and most other
POSIX systems, the specific version of OpenSSL used already varies, as
CPython dynamically links to the system provided OpenSSL library by
default.

For the Windows binary installers, the _ssl and _hashlib modules are
statically linked with OpenSSL and the associated symbols are not
exported. Marc-Andre Lemburg indicates that updating to newer OpenSSL
releases in the egenix-pyopenssl binaries has not resulted in any
reported compatibility issues[1]

The Mac OS X binary installers historically followed the same policy as
other POSIX installations and dynamically linked to the Apple provided
OpenSSL libraries. However, Apple has now ceased updating these
cross-platform libraries, instead requiring that even cross-platform
developers adopt Mac OS X specific interfaces to access up to date
security infrastructure on their platform. Accordingly, and
independently of this PEP, the Mac OS X binary installers were already
going to be switched to statically linker newer versions of OpenSSL[2]

Other Considerations

Maintainability

A number of developers, including Alex Gaynor and Donald Stufft, have
expressed interest in carrying out the feature backports covered by this
policy, and assisting with any additional maintenance burdens that arise
in the Python 2 series as a result.

Steve Dower and Brian Curtin have offered to help with the creation of
the Windows installers, allowing Martin von Löwis the opportunity to
step back from the task of maintaining the 2.7 Windows installer.

This PEP is primarily about establishing the consensus needed to allow
them to carry out this work. For other core developers, this policy
change shouldn't impose any additional effort beyond potentially
reviewing the resulting patches for those developers specifically
interested in the affected modules.

Security releases

This PEP does not propose any changes to the handling of security
releases - those will continue to be source only releases that include
only critical security fixes.

However, the recommendations for library and application developers are
deliberately designed to accommodate commercial redistributors that
choose to apply these changes to additional Python release series that
are either in security fix only mode, or have been declared "end of
life" by the core development team.

Whether or not redistributors choose to exercise that option will be up
to the individual redistributor.

Integration testing

Third party integration testing services should offer users the ability
to test against multiple Python 2.7 maintenance releases (at least 2.7.6
and 2.7.7+), to ensure that libraries, frameworks and applications can
still test their handling of the legacy security infrastructure
correctly (either failing or degrading gracefully, depending on the
security sensitivity of the software), even after the features covered
in this proposal have been backported to the Python 2.7 series.

Handling lower security environments with low risk tolerance

For better or for worse (mostly worse), there are some environments
where the risk of latent security defects is more tolerated than even a
slightly increased risk of regressions in maintenance releases. This
proposal largely excludes these environments from consideration where
the modules covered by the exemption are concerned - this approach is
entirely inappropriate for software connected to the public internet,
and defence in depth security principles suggest that it is not
appropriate for most private networks either.

Downstream redistributors may still choose to cater to such
environments, but they will need to handle the process of downgrading
the security related modules and doing the associated regression testing
themselves. The main CPython continuous integration infrastructure will
not cover this scenario.

Motivation and Rationale

The creation of this PEP was prompted primarily by the aging SSL support
in the Python 2 series. As of March 2014, the Python 2.7 SSL module is
approaching four years of age, and the SSL support in the still popular
Python 2.6 release had its feature set locked six years ago.

These are simply too old to provide a foundation that can be recommended
in good conscience for secure networking software that operates over the
public internet, especially in an era where it is becoming quite clearly
evident that advanced persistent security threats are even more
widespread and more indiscriminate in their targeting than had
previously been understood. While they represented reasonable security
infrastructure in their time, the state of the art has moved on, and we
need to investigate mechanisms for effectively providing more up to date
network security infrastructure for users that, for whatever reason, are
not currently in a position to migrate to Python 3.

While the use of the system OpenSSL installation addresses many of these
concerns on Linux platforms, it doesn't address all of them (in
particular, it is still difficult for sotware to explicitly require some
higher level security settings). The standard library support can be
bypassed by using a third party library like PyOpenSSL or Pycurl, but
this still results in a security problem, as these can be difficult
dependencies to deploy, and many users will remain unaware that they
might want them. Rather than explaining to potentially naive users how
to obtain and use these libraries, it seems better to just fix the
included batteries.

In the case of the binary installers for Windows and Mac OS X that are
published on python.org, the version of OpenSSL used is entirely within
the control of the Python core development team, but is currently
limited to OpenSSL maintenance releases for the version initially
shipped with the corresponding Python feature release.

With increased popularity comes increased responsibility, and this
proposal aims to acknowledge the fact that Python's popularity and
adoption is at a sufficiently high level that some of our design and
policy decisions have significant implications beyond the Python
development community.

As one example, the Python 2 ssl module does not support the Server Name
Indication standard. While it is possible to obtain SNI support by using
the third party requests client library, actually doing so currently
requires using not only requests and its embedded dependencies, but also
half a dozen or more additional libraries. The lack of support in the
Python 2 series thus serves as an impediment to making effective use of
SNI on servers, as Python 2 clients will frequently fail to handle it
correctly.

Another more critical example is the lack of SSL hostname matching in
the Python 2 standard library - it is currently necessary to rely on a
third party library, such as requests or backports.ssl_match_hostname to
obtain that functionality in Python 2.

The Python 2 series also remains more vulnerable to remote timing
attacks on security sensitive comparisons than the Python 3 series, as
it lacks a standard library equivalent to the timing attack resistant
hmac.compare_digest() function. While appropriate secure comparison
functions can be implemented in third party extensions, many users don't
even consider the issue and use ordinary equality comparisons instead -
while a standard library solution doesn't automatically fix that
problem, it does make the barrier to resolution much lower once the
problem is pointed out.

Python 2.7 represents the only long term maintenance release the core
development team has provided, and it is natural that there will be
things that worked over a historically shorter maintenance lifespan that
don't work over this longer support period. In the specific case of the
problem described in this PEP, the simplest available solution is to
acknowledge that long term maintenance of network security related
modules requires the ability to add new features, even while retaining
backwards compatibility for existing interfaces.

For those familiar with it, it is worth comparing the approach described
in this PEP with Red Hat's handling of its long term open source support
commitments: it isn't the RHEL 6.0 release itself that receives 10 years
worth of support, but the overall RHEL 6 series. The individual RHEL 6.x
point releases within the series then receive a wide variety of new
features, including security enhancements, all while meeting strict
backwards compatibility guarantees for existing software. The proposal
covered in this PEP brings our approach to long term maintenance more
into line with this precedent - we retain our strict backwards
compatibility requirements, but make an exception to the restriction
against adding new features.

To date, downstream redistributors have respected our upstream policy of
"no new features in Python maintenance releases". This PEP explicitly
accepts that a more nuanced policy is appropriate in the case of network
security related features, and the specific change it describes is
deliberately designed such that it is potentially suitable for Red Hat
Enterprise Linux and its downstream derivatives.

Why these particular changes?

The key requirement for a feature to be considered for inclusion in this
proposal was that it must have security implications beyond the specific
application that is written in Python and the system that application is
running on. Thus the focus on network security protocols, password
storage and related cryptographic infrastructure - Python is a popular
choice for the development of web services and clients, and thus the
capabilities of widely used Python versions have implications for the
security design of other services that may themselves be using newer
versions of Python or other development languages, but need to
interoperate with clients or servers written using older versions of
Python.

The intent behind this requirement was to minimise any impact that the
introduction of this policy may have on the stability and compatibility
of maintenance releases, while still addressing some key security
concerns relating to the particular aspects of Python 2.7. It would be
thoroughly counterproductive if end users became as cautious about
updating to new Python 2.7 maintenance releases as they are about
updating to new feature releases within the same release series.

The ssl module changes are included in this proposal to bring the Python
2 series up to date with the past 4 years of evolution in network
security standards, and make it easier for those standards to be broadly
adopted in both servers and clients. Similarly the hash algorithm
availability indicators in hashlib are included to make it easier for
applications to detect and employ appropriate hash definitions across
both Python 2 and 3.

The hmac.compare_digest() and hashlib.pbkdf2_hmac() are included to help
lower the barriers to secure password storage and checking in Python 2
server applications.

The os.urandom() change has been included in this proposal to further
encourage users to leave the task of providing high quality random
numbers for cryptographic use cases to operating system vendors. The use
of insufficiently random numbers has the potential to compromise any
cryptographic system, and operating system developers have more tools
available to address that problem adequately than the typical Python
application runtime.

Rejected alternative: just advise developers to migrate to Python 3

This alternative represents the status quo. Unfortunately, it has proven
to be unworkable in practice, as the backwards compatibility
implications mean that this is a non-trivial migration process for large
applications and integration projects. While the tools for migration
have evolved to a point where it is possible to migrate even large
applications opportunistically and incrementally (rather than all at
once) by updating code to run in the large common subset of Python 2 and
Python 3, using the most recent technology often isn't a priority in
commercial environments.

Previously, this was considered an acceptable harm, as while it was an
unfortunate problem for the affected developers to have to face, it was
seen as an issue between them and their management chain to make the
case for infrastructure modernisation, and this case would become
naturally more compelling as the Python 3 series evolved.

However, now that we're fully aware of the impact the limitations of the
Python 2 standard library may be having on the evolution of internet
security standards, I no longer believe that it is reasonable to expect
platform and application developers to resolve all of the latent defects
in an application's Unicode correctness solely in order to gain access
to the network security enhancements already available in Python 3.

While Ubuntu (and to some extent Debian as well) are committed to
porting all default system services and scripts to Python 3, and to
removing Python 2 from its default distribution images (but not from its
archives), this is a mammoth task and won't be completed for the Ubuntu
14.04 LTS release (at least for the desktop image - it may be achieved
for the mobile and server images).

Fedora has even more work to do to migrate, and it will take a
non-trivial amount of time to migrate the relevant infrastructure
components. While Red Hat are also actively working to make it easier
for users to use more recent versions of Python on our stable platforms,
it's going to take time for those efforts to start having an impact on
end users' choice of version, and any such changes also don't benefit
the core platform infrastructure that runs in the integrated system
Python by necessity.

The OpenStack migration to Python 3 is also still in its infancy, and
even though that's a project with an extensive and relatively robust
automated test suite, it's still large enough that it is going to take
quite some time to migrate fully to a Python 2/3 compatible code base.

And that's just three of the highest profile open source projects that
make heavy use of Python. Given the likely existence of large amounts of
legacy code that lacks the kind of automated regression test suite
needed to help support a migration from Python 2 to Python 3, there are
likely to be many cases where reimplementation (perhaps even in Python
3) proves easier than migration. The key point of this PEP is that those
situations affect more people than just the developers and users of the
affected application: the existence of clients and servers with outdated
network security infrastructure becomes something that developers of
secure networked services need to take into account as part of their
security design, and that's a problem that inhibits the adoption of
better security standards.

As Terry Reedy noted, if we try to persist with the status quo, the
likely outcome is that commercial redistributors will attempt to do
something like this on behalf of their customers anyway, but in a
potentially inconsistent and ad hoc manner. By drawing the scope
definition process into the upstream project we are in a better position
to influence the approach taken to address the situation and to help
ensure some consistency across redistributors.

The problem is real, so something needs to change, and this PEP
describes my preferred approach to addressing the situation.

Rejected alternative: create and release Python 2.8

With sufficient corporate support, it likely would be possible to create
and release Python 2.8 (it's highly unlikely such a project would garner
enough interest to be achievable with only volunteers). However, this
wouldn't actually solve the problem, as the aim is to provide a
relatively low impact way to incorporate enhanced security features into
integrated products and deployments that make use of Python 2.

Upgrading to a new Python feature release would mean both more work for
the core development team, as well as a more disruptive update that most
potential end users would likely just skip entirely.

Attempting to create a Python 2.8 release would also bring in
suggestions to backport many additional features from Python 3 (such as
tracemalloc and the improved coroutine support), making the migration
from Python 2.7 to this hypothetical 2.8 release even riskier and more
disruptive.

This is not a recommended approach, as it would involve substantial
additional work for a result that is actually less effective in
achieving the original aim (which is to eliminate the current widespread
use of the aging network security infrastructure in the Python 2
series).

Furthermore, while I can't make any commitments to actually addressing
this issue on Red Hat platforms, I can categorically rule out the idea
of a Python 2.8 being of any use to me in even attempting to get it
addressed.

Rejected alternative: distribute the security enhancements via PyPI

While this initially appears to be an attractive and easier to manage
approach, it actually suffers from several significant problems.

Firstly, this is complex, low level, cross-platform code that integrates
with the underlying operating system across a variety of POSIX platforms
(including Mac OS X) and Windows. The CPython BuildBot fleet is already
set up to handle continuous integration in that context, but most of the
freely available continuous integration services just offer Linux, and
perhaps paid access to Windows. Those services work reasonably well for
software that largely runs on the abstraction layers offered by Python
and other dynamic languages, as well as the more comprehensive
abstraction offered by the JVM, but won't suffice for the kind of code
involved here.

The OpenSSL dependency for the network security support also qualifies
as the kind of "complex binary dependency" that isn't yet handled well
by the pip based software distribution ecosystem. Relying on a third
party binary dependency also creates potential compatibility problems
for pip when running on other interpreters like PyPy.

Another practical problem with the idea is the fact that pip itself
relies on the ssl support in the standard library (with some additional
support from a bundled copy of requests, which in turn bundles
backport.ssl_match_hostname), and hence would require any replacement
module to also be bundled within pip. This wouldn't pose any
insurmountable difficulties (it's just another dependency to vendor),
but it would mean yet another copy of OpenSSL to keep up to date.

This approach also has the same flaw as all other "improve security by
renaming things" approaches: they completely miss the users who most
need help, and raise significant barriers against being able to
encourage users to do the right thing when their infrastructure supports
it (since "use this other module" is a much higher impact change than
"turn on this higher security setting"). Deprecating the aging SSL
infrastructure in the standard library in favour of an external module
would be even more user hostile than accepting the slightly increased
risk of regressions associated with upgrading it in place.

Last, but certainly not least, this approach suffers from the same
problem as the idea of doing a Python 2.8 release: likely not solving
the actual problem. Commercial redistributors of Python are set up to
redistribute Python, and a pre-existing set of additional packages.
Getting new packages added to the pre-existing set can be done, but
means approaching each and every redistributor and asking them to update
their repackaging process accordingly. By contrast, the approach
described in this PEP would require redistributors to deliberately opt
out of the security enhancements by deliberately downgrading the
provided network security infrastructure, which most of them are
unlikely to do.

Rejected variant: provide a "legacy SSL infrastructure" branch

Earlier versions of this PEP included the concept of a 2.7-legacy-ssl
branch that preserved the exact feature set of the Python 2.7.6 network
security infrastructure.

In my opinion, anyone that actually wants this is almost certainly
making a mistake, and if they insist they really do want it in their
specific situation, they're welcome to either make it themselves or
arrange for a downstream redistributor to make it for them.

If they are made publicly available, any such rebuilds should be
referred to as "Python 2.7 with Legacy SSL" to clearly distinguish them
from the official Python 2.7 releases that include more up to date
network security infrastructure.

After the first Python 2.7 maintenance release that implements this PEP,
it would also be appropriate to refer to Python 2.7.6 and earlier
releases as "Python 2.7 with Legacy SSL".

Rejected variant: synchronise particular modules entirely with Python 3

Earlier versions of this PEP suggested synchronising the hmac, hashlib
and ssl modules entirely with their Python 3 counterparts.

This approach proved too vague to build a compelling case for the
exception, and has thus been replaced by the current more explicit
proposal.

Rejected variant: open ended backport policy

Earlier versions of this PEP suggested a general policy change related
to future Python 3 enhancements that impact the general security of the
internet.

That approach created unnecessary uncertainty, so it has been simplified
to propose backport a specific concrete set of changes. Future feature
backport proposals can refer back to this PEP as precedent, but it will
still be necessary to make a specific case for each feature addition to
the Python 2.7 long-term support release.

Disclosure of Interest

The author of this PEP currently works for Red Hat on test automation
tools. If this proposal is accepted, I will be strongly encouraging Red
Hat to take advantage of the resulting opportunity to help improve the
overall security of the Python ecosystem. However, I do not speak for
Red Hat in this matter, and cannot make any commitments on Red Hat's
behalf.

Acknowledgements

Thanks to Christian Heimes and other for their efforts in greatly
improving Python's SSL support in the Python 3 series, and a variety of
members of the Python community for helping me to better understand the
implications of the default settings we provide in our SSL modules, and
the impact that tolerating the use of SSL infrastructure that was
defined in 2010 (Python 2.7) or even 2008 (Python 2.6) potentially has
for the security of the web as a whole.

Thanks to Donald Stufft and Alex Gaynor for identifying a more limited
set of essential security features that allowed the proposal to be made
more fine-grained than backporting entire modules from Python 3.4
([3],[4]).

Christian and Donald also provided valuable feedback on a preliminary
draft of this proposal.

Thanks also to participants in the python-dev mailing list threads
([5],[6],[7],[8]), as well as the various folks I discussed this issue
with at PyCon 2014 in Montreal.

References

Copyright

This document has been placed in the public domain.

  Local Variables: mode: indented-text indent-tabs-mode: nil
  sentence-end-double-space: t fill-column: 70 coding: utf-8 End:

[1] Marc-Andre Lemburg's OpenSSL feedback for Windows
(https://mail.python.org/pipermail/python-dev/2014-March/133438.html)

[2] Ned Deily's OpenSSL feedback for Mac OS X
(https://mail.python.org/pipermail/python-dev/2014-March/133347.html)

[3] Donald Stufft's recommended set of backported features
(https://mail.python.org/pipermail/python-dev/2014-March/133500.html)

[4] Alex Gaynor's recommended set of backported features
(https://mail.python.org/pipermail/python-dev/2014-March/133503.html)

[5] PEP 466 discussion (round 1)
(https://mail.python.org/pipermail/python-dev/2014-March/133334.html)

[6] PEP 466 discussion (round 2)
(https://mail.python.org/pipermail/python-dev/2014-March/133389.html)

[7] PEP 466 discussion (round 3)
(https://mail.python.org/pipermail/python-dev/2014-March/133442.html)

[8] PEP 466 discussion (round 4)
(https://mail.python.org/pipermail/python-dev/2014-March/133472.html)

license: Public Domain


text:
PEP: 758 Title: Allow except and except* expressions without parentheses
Author: Pablo Galindo<EMAIL_ADDRESS>Brett Cannon
<EMAIL_ADDRESS>PEP-Delegate: TBD Status: Draft Type: Standards Track
Created: 30-Sep-2024 Python-Version: 3.14 Post-History: 02-Oct-2024

Abstract

This PEP[1] proposes to allow unparenthesized except and except* blocks
in Python's exception handling syntax. Currently, when catching multiple
exceptions, parentheses are required around the exception types. This
was a Python 2 remnant. This PEP suggests allowing the omission of these
parentheses, simplifying the syntax, making it more consistent with
other parts of the syntax that make parentheses optional, and improving
readability in certain cases.

Motivation

The current syntax for catching multiple exceptions requires parentheses
in the except expression (equivalently for the except* expression). For
example:

    try:
        ...
    except (ExceptionA, ExceptionB, ExceptionC):
        ...

While this syntax is clear and unambiguous, it can be seen as
unnecessarily verbose in some cases, especially when catching a large
number of exceptions. By allowing the omission of parentheses, we can
simplify the syntax:

    try:
        ...
    except ExceptionA, ExceptionB, ExceptionC:
        ...

This change would bring the syntax more in line with other
comma-separated lists in Python, such as function arguments, generator
expressions inside of a function call, and tuple literals, where
parentheses are optional.

The same change would apply to except* expressions. For example:

    try:
        ...
    except* ExceptionA, ExceptionB, ExceptionC:
        ...

Both forms will also allow the use of the as clause to capture the
exception instance as before:

    try:
        ...
    except ExceptionA, ExceptionB, ExceptionC as e:
        ...

Rationale

The decision to allow unparenthesized except blocks is based on the
following considerations:

1.  Simplicity: Removing the requirement for parentheses simplifies the
    syntax, making it more consistent with other parts of the language.
2.  Readability: In cases where many exceptions are being caught, the
    removal of parentheses can improve readability by reducing visual
    clutter.
3.  Consistency: This change makes the except clause more consistent
    with other parts of Python where unambiguous, comma-separated lists
    don't require parentheses.

Specification

The syntax for the except clause will be modified to allow an
unparenthesized list of exception types. The grammar will be updated as
follows:

    except_block:
        | 'except' expressions ['as' NAME] ':' block
        | 'except' ':' block

    except_star_block
        | 'except' '*' expressions ['as' NAME] ':' block

This allows both the current parenthesized syntax and the new
unparenthesized syntax:

    try:
        ...
    except (ExceptionA, ExceptionB):  # Still valid
        ...
    except ExceptionC, ExceptionD:    # New syntax
        ...

The semantics of exception handling remain unchanged. The interpreter
will catch any of the listed exceptions, regardless of whether they are
parenthesized or not.

Backwards Compatibility

This change is fully backwards compatible. All existing code using
parenthesized except and except* blocks will continue to work without
modification. The new syntax is purely additive and does not break any
existing code.

It's worth noting that in Python 2 the unparenthesized syntax was
allowed with two elements, but had different semantics, in which the
first element of the list was used as the exception type and the second
element as the capture variable. This change does not reintroduce the
Python 2 semantics, and the unparenthesized syntax will behave
identically to the parenthesized version.

Security Implications

There are no known security implications for this change. The semantics
of exception handling remain the same, and this is purely a syntactic
change.

How to Teach This

For new Python users, the unparenthesized syntax can be taught as the
standard way to catch multiple exceptions:

    try:
        risky_operation()
    except ValueError, TypeError, OSError:
        handle_errors()

For experienced users, it can be introduced as a new, optional syntax
that can be used interchangeably with the parenthesized version.
Documentation should note that both forms are equivalent:

    # These are equivalent:
    except (ValueError, TypeError):
        ...

    except ValueError, TypeError:
        ...

It should be emphasized that this is purely a syntactic change and does
not affect the behaviour of exception handling.

Reference Implementation

A proof-of-concept implementation is available at
https://github.com/pablogsal/cpython/commits/notuples/. This
implementation modifies the Python parser to accept the new syntax and
ensures that it behaves identically to the parenthesized version.

Rejected Ideas

1.  Allowing mixed parenthesized and unparenthesized syntax:

        try:
            ...
        except (ValueError, TypeError), OSError:
           ...

    This was rejected due to the potential for confusion and to maintain
    a clear distinction between the two styles.

Footnotes

Copyright

This document is placed in the public domain or under the
CC0-1.0-Universal license, whichever is more permissive.

[1] Originally named "Parenthetically Speaking, We Don't Need 'Em"

authors:
Brett Cannon
Pablo Galindo


text:
PEP: 272 Title: API for Block Encryption Algorithms v1.0 Version:
$Revision$ Last-Modified: $Date$ Author: A.M. Kuchling<EMAIL_ADDRESS>Status: Final Type: Informational Content-Type: text/x-rst Created:
18-Sep-2001 Post-History: 17-Apr-2002, 29-May-2002

Abstract

This document specifies a standard API for secret-key block encryption
algorithms such as DES or Rijndael, making it easier to switch between
different algorithms and implementations.

Introduction

Encryption algorithms transform their input data (called plaintext) in
some way that is dependent on a variable key, producing ciphertext. The
transformation can easily be reversed if and only if one knows the key.
The key is a sequence of bits chosen from some very large space of
possible keys. There are two classes of encryption algorithms: block
ciphers and stream ciphers.

Block ciphers encrypt multibyte inputs of a fixed size (frequently 8 or
16 bytes long), and can be operated in various feedback modes. The
feedback modes supported in this specification are:

  Number   Constant   Description
  -------- ---------- -----------------------
  1        MODE_ECB   Electronic Code Book
  2        MODE_CBC   Cipher Block Chaining
  3        MODE_CFB   Cipher Feedback
  5        MODE_OFB   Output Feedback
  6        MODE_CTR   Counter

These modes are to be implemented as described in NIST publication SP
800-38A[1]. Descriptions of the first three feedback modes can also be
found in Bruce Schneier's book Applied Cryptography[2].

(The numeric value 4 is reserved for MODE_PGP, a variant of CFB
described in 2440: "OpenPGP Message Format". This mode isn't considered
important enough to make it worth requiring it for all block encryption
ciphers, though supporting it is a nice extra feature.)

In a strict formal sense, stream ciphers encrypt data bit-by-bit;
practically, stream ciphers work on a character-by-character basis. This
PEP only aims at specifying an interface for block ciphers, though
stream ciphers can support the interface described here by fixing
'block_size' to 1. Feedback modes also don't make sense for stream
ciphers, so the only reasonable feedback mode would be ECB mode.

Specification

Encryption modules can add additional functions, methods, and attributes
beyond those described in this PEP, but all of the features described in
this PEP must be present for a module to claim compliance with it.

Secret-key encryption modules should define one function:

    new(key, mode, [IV], **kwargs)

Returns a ciphering object, using the secret key contained in the string
'key', and using the feedback mode 'mode', which must be one of the
constants from the table above.

If 'mode' is MODE_CBC or MODE_CFB, 'IV' must be provided and must be a
string of the same length as the block size. Not providing a value of
'IV' will result in a ValueError exception being raised.

Depending on the algorithm, a module may support additional keyword
arguments to this function. Some keyword arguments are specified by this
PEP, and modules are free to add additional keyword arguments. If a
value isn't provided for a given keyword, a secure default value should
be used. For example, if an algorithm has a selectable number of rounds
between 1 and 16, and 1-round encryption is insecure and 8-round
encryption is believed secure, the default value for 'rounds' should be
8 or more. (Module implementors can choose a very slow but secure value,
too, such as 16 in this example. This decision is left up to the
implementor.)

The following table lists keyword arguments defined by this PEP:

  Keyword        Meaning
  -------------- -----------------------------------------------------------------------------------
  counter        Callable object that returns counter blocks (see below; CTR mode only)
  rounds         Number of rounds of encryption to use
  segment_size   Size of data and ciphertext segments, measured in bits (see below; CFB mode only)

The Counter feedback mode requires a sequence of input blocks, called
counters, that are used to produce the output. When 'mode' is MODE_CTR,
the 'counter' keyword argument must be provided, and its value must be a
callable object, such as a function or method. Successive calls to this
callable object must return a sequence of strings that are of the length
'block_size' and that never repeats. (Appendix B of the NIST publication
gives a way to generate such a sequence, but that's beyond the scope of
this PEP.)

The CFB mode operates on segments of the plaintext and ciphertext that
are 'segment_size' bits long. Therefore, when using this mode, the input
and output strings must be a multiple of 'segment_size' bits in length.
'segment_size' must be an integer between 1 and block_size*8, inclusive.
(The factor of 8 comes from 'block_size' being measured in bytes and not
in bits). The default value for this parameter should be block_size*8.
Implementors are allowed to constrain 'segment_size' to be a multiple of
8 for simplicity, but they're encouraged to support arbitrary values for
generality.

Secret-key encryption modules should define two variables:

-   block_size

    An integer value; the size of the blocks encrypted by this module,
    measured in bytes. For all feedback modes, the length of strings
    passed to the encrypt() and decrypt() must be a multiple of the
    block size.

-   key_size

    An integer value; the size of the keys required by this module,
    measured in bytes. If key_size is None, then the algorithm accepts
    variable-length keys. This may mean the module accepts keys of any
    random length, or that there are a few different possible lengths,
    e.g. 16, 24, or 32 bytes. You cannot pass a key of length 0 (that
    is, the null string '') as a variable-length key.

Cipher objects should have two attributes:

-   block_size

    An integer value equal to the size of the blocks encrypted by this
    object. For algorithms with a variable block size, this value is
    equal to the block size selected for this object.

-   IV

    Contains the initial value which will be used to start a cipher
    feedback mode; it will always be a string exactly one block in
    length. After encrypting or decrypting a string, this value is
    updated to reflect the modified feedback text. It is read-only, and
    cannot be assigned a new value.

Cipher objects require the following methods:

-   decrypt(string)

    Decrypts 'string', using the key-dependent data in the object and
    with the appropriate feedback mode. The string's length must be an
    exact multiple of the algorithm's block size or, in CFB mode, of the
    segment size. Returns a string containing the plaintext.

-   encrypt(string)

    Encrypts a non-empty string, using the key-dependent data in the
    object, and with the appropriate feedback mode. The string's length
    must be an exact multiple of the algorithm's block size or, in CFB
    mode, of the segment size. Returns a string containing the
    ciphertext.

Here's an example, using a module named 'DES':

    >>> import DES
    >>> obj = DES.new('abcdefgh', DES.MODE_ECB)
    >>> plaintext = "Guido van Rossum is a space alien."
    >>> len(plaintext)
    34
    >>> obj.encrypt(plaintext)
    Traceback (innermost last):
      File "<stdin>", line 1, in ?
    ValueError: Strings for DES must be a multiple of 8 in length
    >>> ciphertext = obj.encrypt(plain+'XXXXXX')   # Add padding
    >>> ciphertext
    '\021,\343Nq\214DY\337T\342pA\372\255\311s\210\363,\300j\330\250\312\347\342I\3215w\03561\303dgb/\006'
    >>> obj.decrypt(ciphertext)
    'Guido van Rossum is a space alien.XXXXXX'

References

Changes

2002-04: Removed references to stream ciphers; retitled PEP; prefixed
feedback mode constants with MODE_; removed PGP feedback mode; added CTR
and OFB feedback modes; clarified where numbers are measured in bytes
and where in bits.

2002-09: Clarified the discussion of key length by using
"variable-length keys" instead of "arbitrary-length".

Acknowledgements

Thanks to the readers of the python-crypto list for their comments on
this PEP.

Copyright

This document has been placed in the public domain.

[1] NIST publication SP 800-38A, "Recommendation for Block Cipher Modes
of Operation" (http://csrc.nist.gov/encryption/modes/)

[2] Applied Cryptography


text:
PEP: 3139 Title: Cleaning out sys and the "interpreter" module Version:
$Revision$ Last-Modified: $Date$ Author: Benjamin Peterson
<EMAIL_ADDRESS>Status: Rejected Type: Standards Track
Content-Type: text/x-rst Created: 04-Apr-2008 Python-Version: 3.0

Rejection Notice

Guido's -0.5 put an end to this PEP. See
https://mail.python.org/pipermail/python-3000/2008-April/012977.html.

Abstract

This PEP proposes a new low-level module for CPython-specific
interpreter functions in order to clean out the sys module and separate
general Python functionality from implementation details.

Rationale

The sys module currently contains functions and data that can be put
into two major groups:

1.  Data and functions that are available in all Python implementations
    and deal with the general running of a Python virtual machine.
    -   argv
    -   byteorder
    -   path, path_hooks, meta_path, path_importer_cache, and modules
    -   copyright, hexversion, version, and version_info
    -   displayhook, __displayhook__
    -   excepthook, __excepthook__, exc_info, and exc_clear
    -   exec_prefix and prefix
    -   executable
    -   exit
    -   flags, py3kwarning, dont_write_bytecode, and warn_options
    -   getfilesystemencoding
    -   get/setprofile
    -   get/settrace, call_tracing
    -   getwindowsversion
    -   maxint and maxunicode
    -   platform
    -   ps1 and ps2
    -   stdin, stderr, stdout, __stdin__, __stderr__, __stdout__
    -   tracebacklimit
2.  Data and functions that affect the CPython interpreter.
    -   get/setrecursionlimit
    -   get/setcheckinterval
    -   _getframe and _current_frame
    -   getrefcount
    -   get/setdlopenflags
    -   settscdumps
    -   api_version
    -   winver
    -   dllhandle
    -   float_info
    -   _compact_freelists
    -   _clear_type_cache
    -   subversion
    -   builtin_module_names
    -   callstats
    -   intern

The second collections of items has been steadily increasing over the
years causing clutter in sys. Guido has even said he doesn't recognize
some of things in it[1]!

Moving these items off to another module would send a clear message to
other Python implementations about what functions need and need not be
implemented.

It has also been proposed that the contents of types module be
distributed across the standard library[2]; the interpreter module would
provide an excellent resting place for internal types like frames and
code objects.

Specification

A new builtin module named "interpreter" (see Naming) will be added.

The second list of items above will be split into the stdlib as follows:

The interpreter module

    -   get/setrecursionlimit
    -   get/setcheckinterval
    -   _getframe and _current_frame
    -   get/setdlopenflags
    -   settscdumps
    -   api_version
    -   winver
    -   dllhandle
    -   float_info
    -   _clear_type_cache
    -   subversion
    -   builtin_module_names
    -   callstats
    -   intern

The gc module:

    -   getrefcount
    -   _compact_freelists

Transition Plan

Once implemented in 3.x, the interpreter module will be back-ported to
2.6. Py3k warnings will be added to the sys functions it replaces.

Open Issues

What should move?

dont_write_bytecode

Some believe that the writing of bytecode is an implementation detail
and should be moved[3]. The counterargument is that all current,
complete Python implementations do write some sort of bytecode, so it is
valuable to be able to disable it. Also, if it is moved, some wish to
put it in the imp module.

Move to some to imp?

It was noted that dont_write_bytecode or maybe builtin_module_names
might fit nicely in the imp module.

Naming

The author proposes the name "interpreter" for the new module. "pyvm"
has also been suggested[4]. The name "cpython" was well liked [5].

References

Copyright

  This document has been placed in the public domain.

  Local Variables: mode: indented-text indent-tabs-mode: nil
  sentence-end-double-space: t fill-column: 70 coding: utf-8 End:

[1] http://bugs.python.org/issue1522

[2] https://mail.python.org/pipermail/stdlib-sig/2008-April/000172.html

[3] https://mail.python.org/pipermail/stdlib-sig/2008-April/000217.html

[4] https://mail.python.org/pipermail/python-3000/2007-November/011351.html

[5] https://mail.python.org/pipermail/stdlib-sig/2008-April/000223.html