[Python-Dev] Bug fixed in the bugs.python.org OAuth-based authentication: user logged as the wrong account
Hi, A bug has been identified and *fixed* in the OAuth-based authentication code used on the Python bug tracker bugs.python.org (BPO) to log in with GitHub, Launchpad or Google. Under some conditions, it was possible to be logged as another person account. We are only aware of a single user affected by the issue. We are not aware of any account takeover. All bugs at bugs.python.org are public: being logged as the wrong account cannot give access to private bugs. The main risk is if an attacker could be logged as an administrator (the "Coordinator" role) which allows to change the bug tracker configuration and to change accounts (add/remove roles, see/change the email address, etc.). We are not aware of any abuse. All OAuth accounts have been removed in the database to fully fix the issue. Users using OAuth-based authentication must associate again (once) their GitHub, Launchpad or Google account with their BPO account. A BPO account contains the following information: Name, Login Name, GitHub Name, Organisation, Timezone, Homepage, Contributor Form Received, Is Committer, E-mail address, Alternate E-mail addresses. All fields but Name and Timezone are hidden to other accounts, only coordinators can see all fields of other accounts. You can check in the "Your Details" page for the your account change log. Thanks Ammar Askar, Berker Peksağ and Ee Durbin who fixed the bug! Source code of bugs.python.org (Roundup fork): https://github.com/psf/bpo-tracker-cpython The OAuth-based authentication is an extension written for bugs.python.org. The bug report and its fix: * https://github.com/python/bugs.python.org/issues/64 * https://github.com/psf/bpo-tracker-cpython/commit/0a32e072aafca20c0bf51cf16fb6a7328cdd720a Report issues with bugs.python.org: https://github.com/python/bugs.python.org/issues To report sensitive issues, write to: [email protected] Victor -- Night gathers, and now my watch begins. It shall not end until my death. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/CIXIB6EMN7HOPMXFJI7EBK7V7OPK4E7H/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Bug fixed in the bugs.python.org OAuth-based authentication: user logged as the wrong account
Thanks for the fix! This could have caused some serious issues, so glad we were able to address it ahead of time. On Mon, Sep 13, 2021 at 5:06 AM Victor Stinner wrote: > Hi, > > A bug has been identified and *fixed* in the OAuth-based > authentication code used on the Python bug tracker bugs.python.org > (BPO) to log in with GitHub, Launchpad or Google. Under some > conditions, it was possible to be logged as another person account. We > are only aware of a single user affected by the issue. We are not > aware of any account takeover. > > All bugs at bugs.python.org are public: being logged as the wrong > account cannot give access to private bugs. The main risk is if an > attacker could be logged as an administrator (the "Coordinator" role) > which allows to change the bug tracker configuration and to change > accounts (add/remove roles, see/change the email address, etc.). We > are not aware of any abuse. > > All OAuth accounts have been removed in the database to fully fix the > issue. Users using OAuth-based authentication must associate again > (once) their GitHub, Launchpad or Google account with their BPO > account. > > A BPO account contains the following information: Name, Login Name, > GitHub Name, Organisation, Timezone, Homepage, Contributor Form > Received, Is Committer, E-mail address, Alternate E-mail addresses. > All fields but Name and Timezone are hidden to other accounts, only > coordinators can see all fields of other accounts. You can check in > the "Your Details" page for the your account change log. > > Thanks Ammar Askar, Berker Peksağ and Ee Durbin who fixed the bug! > > Source code of bugs.python.org (Roundup fork): > https://github.com/psf/bpo-tracker-cpython > > The OAuth-based authentication is an extension written for > bugs.python.org. The bug report and its fix: > > * https://github.com/python/bugs.python.org/issues/64 > * > https://github.com/psf/bpo-tracker-cpython/commit/0a32e072aafca20c0bf51cf16fb6a7328cdd720a > > Report issues with bugs.python.org: > https://github.com/python/bugs.python.org/issues > > To report sensitive issues, write to: [email protected] > > Victor > -- > Night gathers, and now my watch begins. It shall not end until my death. > ___ > Python-Dev mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/CIXIB6EMN7HOPMXFJI7EBK7V7OPK4E7H/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/OH7V7GJ6GTQJM3OBIXZ72IZXA4KSLVVH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 663: Improving and Standardizing Enum str(), repr(), and format() behaviors
On 9/11/2021 6:53 AM, Ethan Furman wrote: Abstract Now that we have a few years experience with Enum usage it is time to update the ``repr()``, ``str()``, and ``format()`` of the various enumerations by their intended purpose. You *are* allowed to put some (brief) details in the abstract. No need to avoid spoilers ;) As it stands, "it is time" on its own is a really bad reason to change anything. So you're preemptively making it sound like the PEP has no solid backing. I haven't read the rest yet. The abstract is supposed to make me want to read it, and this one does not, so I stopped. (Might come back later when I'm not trying to catch up on my weekend's email though.) Cheers, Steve ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/KN7QUBTJGWWP7TZ4PWJIZNVFPWU7S2ID/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: A better way to freeze modules
On Sat, Sep 11, 2021 at 7:08 PM Gregory Szorc wrote: > Thanks for all the replies, everyone! I'll reply to a few comments > individually. But I first wanted to address the common theme around > zipimport. > > First, one idea that nobody mentioned (and came to me after reading the > replies) was to possibly leverage zipimport for freezing the standard > library instead of extending the frozen importer. I strongly feel this > option is preferable to extending the frozen importer with additional > functionality. I suspect the Python core developers would prefer to close > importer feature gaps / bugs with zipimport over the frozen importer. And > since zipimport is actually usable without having to build your own > binaries, improvements to zipimport would more significantly benefit the > larger Python ecosystem. If zipimporter gained the ability to open a zip > archive residing in a memory address or a PyObject implementing the buffer > protocol, [parts of] the standard library could be persisted as a zip file > in libpython and the frozen importer would be limited to bootstrapping the > import subsystem, just like it is today. This avoids adding additional > complexity (like supporting __file__ and __cached__) to the frozen > importer. And it keeps the standard library using a commonly-used importer > in the standard library, just like it is today with PathFinder. > > Onto the bigger question that can be summarized as "why not use zipimport: > why do we need something different?" I sympathize with this reasoning. > zipimport exists, it is functional, and it is widely used and has > demonstrated value. > > Performance is a major reason to build something better than zipimport. > > I response to your replies, I implemented a handful of benchmarks for > oxidized_importer and also implemented a pure Rust implementation of a zip > file importer to collect some hard data. You can reproduce my results by > cloning https://github.com/indygreg/PyOxidizer.git and running `cargo > bench -p pyembed-bench`. At time of writing, the benchmarks materialize the > full standard library on the filesystem, in a zip archive (with no > compression), and in the "Python packed resources" format. It then fires up > a Python interpreter and imports ~450 modules comprising the standard > library. I encourage you to obtain your own numbers and look at the > benchmark code to better understand testing methodology. But here are some > results from Linux on my Ryzen 5950x. > > * zipimporter is slower than PathFinder to import the entirety of the > standard library when the disk cache is hot. 201.81ms for zipimporter vs > 174.06ms for PathFinder. > * My pure Rust zip importer is faster than zipimporter and PathFinder for > the same operation. 161.67ms when reading zip data from memory; 164.45ms > when using buffered filesystem I/O (8kb read operations). > * OxidizedFinder + Python packed resources are the fastest of all. > 121.07ms loading from memory. > * Parsing/indexing the container formats is fast in Rust. Python packed > resources parses in 107.69us and indexes in 200.52us (0.2ms). A zip archive > table of contents is parsed in 809.61us and indexes in 1.205ms. If that > same zip archive is read/seeked using filesystem I/O, the numbers go up to > 4.6768ms and 5.1591ms. > * Starting and finalizing a Python interpreter takes 11.930ms with > PathFinder and 4.8887ms with OxidizedFinder. > Now this is for importing 450 modules, correct? My suspicion is that import load for something that's start-up sensitive is not common. While there's an obvious performance difference between e.g. 202ms and 174ms, that may be at the extreme end. If you assume average import time per module and you assume about 100 modules imported then the difference is 45ms versus 39ms which is negligible. So while I appreciate the collection of these numbers and seeing there's room for improvement, I also don't think it's best for us to focus on the worst-case scenario. > > I won't post the full set of numbers for Windows, but they are generally > higher, especially if filesystem I/O is involved. PathFinder is still > faster than zipimporter, however. And zipimporter's relative slowness > compared to OxidizedFinder is more pronounced. > > There are many interesting takeaways from these numbers. But here are what > I think are the most important: > > * The Rust implementation of a zip importer trouncing performance of > zipimporter probably means zipimporter could be made a lot faster (I didn't > profile to measure why zipimporter is so slow. But I suspect its > performance is hindered by being implemented in Python.) > Being implemented in Python is very much on purpose for zipimporter as it used to be in C and no one wanted to work on it then. Having it in Python has made tweaking how it functions much easier. > * OxidizedFinder + Python packed resources are still significantly faster > than the next fastest solution (Rust implemented zip importer). > I don'
[Python-Dev] Re: PEP 663: Improving and Standardizing Enum str(), repr(), and format() behaviors
El vie, 10 sept 2021 a las 22:56, Ethan Furman () escribió: > > > Specification > = > > There a three broad categories of enum usage: > > - standard: Enum or Flag >a new enum class is created, and the members are used as > ``class.member_name`` > > - drop-in replacement: IntEnum, IntFlag, StrEnum >a new enum class is created which also subclasses ``int`` or ``str`` > and uses >``int.__str__`` or ``str.__str__``; the ``repr`` can be changed by > using the >``global_enum`` decorator > > - user-mixed enums and flags >the user creates their own integer-, float-, str-, whatever-enums > instead of >using enum.IntEnum, etc. > > Some sample enums:: > > # module: tools.py > > class Hue(Enum): # or IntEnum > LIGHT = -1 > NORMAL = 0 > DARK = +1 > > class Color(Flag): # or IntFlag > RED = 1 > GREEN = 2 > BLUE = 4 > > class Grey(int, Enum): # or (int, Flag) > BLACK = 0 > WHITE = 1 > > Using the above enumerations, the following table shows the old and new > behavior, while the last shows the final result: > > > > +-+--+-++---+---++---+ > | type | enum repr() | enum str() | enum format() > | flag repr() | flag str() > | flag format() | > > +-+--+-++---+---++---+ > | standard| 3.10 | || > | | > Color.RED|GREEN| Color.RED|GREEN | > | > > +--+-++---+---++---+ > | | new | || > | | > Color.RED|Color.GREEN | Color.RED|Color.GREEN | > > +-+--+-++---+---++---+ > > +-+--+-++---+---++---+ > | user mixed | 3.10 | || 1 > || > | 1 | > | > > +--+-++---+---++---+ > | | new | || Grey.WHITE > | | > | Grey.WHITE| > > +-+--+-++---+---++---+ > > +-+--+-++---+---++---+ > | int drop-in | 3.10 | | Hue.LIGHT | > | | > Color.RED|GREEN| | > | > > +--+-++---+---++---+ > | | new | | -1 | > | | 3 > | | > > +-+--+-++---+---++---+ > > +-+--+-++---+---++---+ > | global | 3.10 | | Hue.LIGHT | Hue.LIGHT > | | > Color.RED|GREEN| Color.RED|GREEN | > | > > +--+-++---+---++---+ > | | new | tools.LIGHT | LIGHT | LIGHT > | tools.RED|tools.GREEN | RED|GREEN > | RED|GREEN | > > +-+--+-++---+---++---+ > > +-+--+-++---+---++---+ > | user mixed | 3.10 ||| Grey.WHITE > | 1 | > | > > +--+-++---+---++---+ > | | new | tools.WHITE | WHITE | WHITE > | tools.WHITE | WHITE > | WHITE | > > +-+--+-++---+---++-
[Python-Dev] Re: PEP 467 feedback from the Steering Council
There is some discussion going on in bpo-45155 about what the default value of the `byteorder` argument should be for int.to_bytes() and int.from_bytes(): https://bugs.python.org/issue45155 I’ve created a short Discourse poll if you’d like to weigh in. https://discuss.python.org/t/what-should-be-the-default-value-for-int-to-bytes-byteorder/10616 Cheers, -Barry signature.asc Description: Message signed with OpenPGP ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/DCJO5KBALGSQ3SYXC3QSWFH3SJ67VOKA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 663: Improving and Standardizing Enum str(), repr(), and format() behaviors
On 9/13/21 9:03 AM, Steve Dower wrote: > You *are* allowed to put some (brief) details in the abstract. No need to avoid spoilers ;) > > As it stands, "it is time" on its own is a really bad reason to change anything. So you're > preemptively making it sound like the PEP has no solid backing. Abstract Update the ``repr()``, ``str()``, and ``format()`` of the various Enum types for consistency and to better match their intended purpose. Better? -- ~Ethan~ ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/G23CC3KDI3QZNGEXR7M52TALQLRF3CPQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 663: Improving and Standardizing Enum str(), repr(), and format() behaviors
On 9/13/21 9:55 AM, Jelle Zijlstra wrote: > This table doesn't render properly in https://www.python.org/dev/peps/pep-0663/#specification. > - There are some extra blank lines > - Many cells are blank > - There are two "user mixed" rows and it's not clear how those relate to the mention of "three broad categories" above. The blank cells are the "no change" cells; the blank lines were there to separate the types (removed). I have reworked those tables slightly -- hopefully they make more sense now. -- ~Ethan~ ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/WHLX3FSQYE62AEFFVGN6VGYQVWI5BD5J/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 663: Improving and Standardizing Enum str(), repr(), and format() behaviors
On 9/13/2021 8:12 PM, Ethan Furman wrote: On 9/13/21 9:03 AM, Steve Dower wrote: > You *are* allowed to put some (brief) details in the abstract. No need to avoid spoilers ;) > > As it stands, "it is time" on its own is a really bad reason to change anything. So you're > preemptively making it sound like the PEP has no solid backing. Abstract Update the ``repr()``, ``str()``, and ``format()`` of the various Enum types for consistency and to better match their intended purpose. Better? You don't have a one sentence summary of what the changes entail? "Originally these were based on the idea that ..., but now will work better for ... by making the results more consistent with ..." (where each "..." is filled with specific things). It doesn't have to save me reading the whole thing, but if I'm digging through documents going "why am I seeing instead of just '1'", it should confirm that this is the right document to read. (Alternatively, think about writing the tweet here that you want people to include when they share your PEP, assuming that 99% of people won't actually click through to the document. What can you tell them so that they at least know what is coming?) Cheers, Steve ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/VQI5IVW5B6NQB246YYOSAW5DP3G2ZWAQ/ Code of Conduct: http://python.org/psf/codeofconduct/
