2024-03-19, ogłoszono dwie dziury bezpieczeństwa na liście mailingowej, poświęconej problemom bezpieczeństwa Pythona: "quoted zip-bomb" i "TemporaryDirectory symlink dereference during cleanup". Obie miały dotykać wszystkich aktualnych wydań CPythona.
Tego samego dnia, wydano nowe wersje Pythona 3.10, 3.9 i 3.8. Co ciekawe, nie było wydań dla 3.11 i 3.12.
2024-04-02, w końcu otagowano Pythona 3.11.9. Początkowo, podpis dla archiwum się nie sprawdzał. Dziś już jest OK, ale wydania dalej nie ogłoszono. Co jednak najbardziej mnie zaskoczyło, to brak poprawek dla dwóch ogłoszonych wcześniej problemów! Czyżby nieudane wydanie?
Przyjrzałem się sprawie bliżej… i okazało się, że oba problemy były już poprawione w poprzednim wydaniu 3.11.8 (i 3.12.2), więc ogłoszenie było błędne. Wzdych.
The Python Package Index (PyPI) repository experienced a malware upload attack, forcing maintainers to suspend new project creation and user registration to mitigate the threat. This incident involved malicious Python packages, likely uploaded using typo-squatting techniques, designed to steal sensitive information and credentials. The malware also included a persistence mechanism to remain active on compromised systems.
Paczka Pythona #regex (nie mylić z wbudowanym modułem re) zbudowana jest w oparciu o szczegóły implementacji CPythona i nie obsługuje poprawnie #PyPy (i autor zapowiada, że może w końcu zablokować kompilację na PyPy). Jednakże wygląda na to, że wymagająca jej paczka #ReAssert działa bez problemów ze zwyczajnym re.
Dzisiaj #Gentoo przechodzi z łatania w sposób niedoskonały paczki regex, i ignorowania szczególnych przypadków, w których nie zadziała, na rzecz łatania re-assert. Chciałbym wysłać tę trywialną łatkę autorowi, ale — jak już wcześniej narzekałem — dostałem niegdyś bana, autor nie potrafi powiedzieć dlaczego, ale nie przeszkadza mu to uważać bana za sprawiedliwego. Może po prostu proaktywnie banuje devów dystrybucji Linuksa.
For detailed data on past contributions (and another place to help fund PyPy if GitHub sponsoring isn't your thing), visit https://opencollective.com/pypy.
Even though the team prefers Mercurial, they believe being on GitHub will foster contributions.
If you know your way around GitHub Actions, Buildbots, GH Wikis, or are interested in contributing, now is a great time to get involved. Starring the repo helps with visibility.
#PyPy v7.3.14: release of #python 2.7, 3.9, and 3.10
"The PyPy team is proud to release version 7.3.14 of PyPy.
Hightlights of this release are compatibility with HPy-0.9, cffi 1.16, additional C-API interfaces, and more python3.10 fixes.
[...]
We would like to thank our donors for the continued support of the PyPy project.
[...]
We would also like to thank our contributors and encourage new people to join the project. "
PyPy 7.3.14 has just been released! 🎉
The main feature is HPy 0.9 support, as well as various bug fixes and small improvements. ✨ Thanks to Matti for doing the release! 🙏
Typowa sytuacja we współczesnym #OpenSource, na przykładzie ekosystemu języka #Python.
Wiele projektów używa biblioteki #FreezeGun, by nadpisywać wskazania zegara na potrzeby testów. FreezeGun powoli przestaje być rozwijany. W końcu zaczyna mieć problemy z nowymi wersjami Pythona. Dystrybucje, takie jak #Gentoo, są odporne na te problemy, bo mogą łatwo dodać lokalne łatki.
Tak więc projekty zaczynają korzystać z #TimeMachine. Niestety, time-machine opiera się na hakowaniu detali implementacji CPythona (w imię wydajności, bo przecież nadpisywanie czasu w testach to wydajnościowe wąskie gardło), więc na #PyPy nie działa w ogóle. Niektóre projekty wspierają FreezeGun i time-machine równocześnie, inne nie.
Czasem time-machine łapie segfaulty na CPythonie. Z czasem coraz więcej segfaultów zostaje zgłoszonych. Nie ma więc zaskoczenia, że nowe zgłoszenia błędów nie spotykają się z odpowiedzią. W międzyczasie, FreezeGun na nowo zaczyna być rozwijany. No i zgadnijcie, co teraz się dzieje…
Chciałbym także podziękować autorom PyPy za ich wsparcie, zarówno w kwestii poprawiania błędów w PyPy, jak również udzielaniu pomocy innym projektom, by poprawić ich zgodność z PyPy. Praca z wami jest przyjemnością!
Na koniec, poznałem ważny argument za pracą nad wsparciem PyPy w projektach: nawet jeśli dana paczka nie działa szybciej na PyPy, to może być zależnością w większym projekcie, w którym PyPy ogółem przynosi lepszą wydajność.
This weekend I landed a CPython PR that I'm very happy about (with the help of @ambv and Dennis Sweeney):
I switched the storage of all the names of Unicode code points in the unicodedata modules to using a different data structure, a "directed acyclic word graph". This makes the compiled module 440 KiB smaller. I did the same thing in PyPy a year ago, quite happy that it now made it to CPython too.
At the last Python Language Summit in April, after three back-to-back sessions on the C API, we agreed that our discussions about the future of the C API are lacking a shared understanding of its current state, its strengths and weaknesses.
We decided to work towards a document summarising a community consensus on that, and have now put together the draft of PEP 733.
@iritkatriel Nice! As a #pypy irc channel lurker, this looks like the most comprehensive collection of concerns about the C API I have seen. Hope that it will help make the lives of alternative Python implementations easier in the future.
PyPy v7.3.13: release of #Python 2.7, 3.9, and 3.10
"""
The PyPy team is proud to release version 7.3.13 of PyPy. This is primarily a security/bug-fix release. CPython released security patches, and this release also improves the ability to use type specifications via PyType_FromSpec and friends. There are also some small speed-ups.
"""
PyPy is a great project, run by great people. I wish it had more recognition and more resources devoted to it.
At first, I was a bit skeptical of the new Modular's #Mojo language.
Having no binaries available (only a playground), and a long history of #Python contenders such as #PyPy or Pyston that never achieved full compatibility... was a huge turnoff.
The amount of Python compilers that never reach 100% compatibility is almost hilarious.
Having seen the tremendous amount of effort behind #Julialang, and how little is its community compared to Python's... adds on top of that.
Everyone, welcome to the Fediverse for Antonio Cuni @antocuni , HPy founder, PyPy and PyScript core dev and a friend of mine. 👋 #hpy#pypy#pyscript#python
#Python language lawyers, we're seeing some interesting issue with #PyPy / ijson.
ijson is calling the async function's wait() method and iterating over the results until it gets StopIteration exception, and it uses it to get the return value. This works in Python both in CPython and PyPy but within C API, CPython tp_iternext() raises StopIteration while in PyPy it does not — is that a bug or is there some other way to get the return value?
If you're testing PyPy on #GitHubActions in several projects, you can use all-repos to update many at the same time. See @jugmac00's blog for setup tips: