@mgorny@pol.socialPrzygotowałem wstępnie weryfikację autentyczności plików z #PyPI dla #Gentoo.
Wiecie, ten nowy wynalazek, który chroni przed atakami podmieniającymi pliki na PyPI, i upewnia się, że macie do czynienia z oryginalnymi plikami z GitHuba. No bo, jak powszechnie wiadomo, repozytoria na GitHubie i tamtejsze syste…
@mgorny@social.treehouse.systems @mgorny@pol.social @mgorny@social.treehouse.systems1. Have a simple job to do. Figure out #Makefile will do the job.
2. Think a bit about portability. Makefile becomes slightly more complex.
3. You're finally done. It turns out that some stupid implicit rule in GNU Make fires and adds a `rm` at the end that removes part of the output.
4. Use #Meson.
Just an average #Gentoo day.
[UPDATE: Now I regret using Meson. If you do anything that's not 100% boilerplate, it just keeps throwing obstacles in your way.]
@mgorny@pol.socialTo teraz #Gentoo jakoby zawiera "ekstremistyczne" oprogramowanie.
https://bugs.gentoo.org/964663
@mgorny@social.treehouse.systemsSo #Gentoo is now shipping "extremist" software, apparently.
https://bugs.gentoo.org/964663
@mgorny@social.treehouse.systemsNew on blog: "How we incidentally uncovered a 7-year old bug in gentoo-ci"
"""
“Gentoo CI” is the service providing periodic linting for the Gentoo repository. It is a part of the Repository mirror and CI project that I’ve started in 2015. Of course, it all started as a temporary third-party solution, but it persisted, was integrated into Gentoo Infrastructure and grew organically into quite a monstrosity.
It’s imperfect in many ways. In particular, it has only some degree of error recovery and when things go wrong beyond that, it requires a manual fix. Often the “fix” is to stop mirroring a problematic repository. Over time, I’ve started having serious doubts about the project, and proposed sunsetting most of it.
Lately, things have been getting worse. What started as a minor change in behavior of Git triggered a whole cascade of failures, leading to me finally announcing the deadline for sunsetting the mirroring of third-party repositories, and starting ripping non-critical bits out of it. Interesting enough, this whole process led me to finally discover the root cause of most of these failures — a bug that has existed since the very early version of the code, but happened to be hidden by the hacky error recovery code. Here’s the story of it.
"""
#Gentoo
@mgorny@pol.social @mgorny@social.treehouse.systemsI've probably mentioned that I'm working on switching #Gentoo from our half-broken eselect-ldso logic to #FlexiBLAS. This also involves a transition period where both setups would be supported.
A good thing is that the switch is ABI-compatible with the previous state (or at least it's supposed to be — we're working with upstream on fixing function coverage). Since libblas.so, liblapack.so and the rest are replaced by symlinks, programs that link to them will simply start using FlexiBLAS. So far, so good.
Unfortunately, switching the other way doesn't work as well. Stuff newly built against our libblas.so & co. symlinks naturally reads FlexiBLAS's SONAME from them, and links to libflexiblas directly. So should you decide to switch back, some packages will stay linked to FlexiBLAS and will need to rebuilt.
In order to avoid this, I would have to replace the symlinks with wrapper libraries, having libblas.so.3 and so on SONAMEs, and linking to libflexiblas. Unfortunately, a dummy wrapper isn't going to work — the linker will complain about using indirect symbols from libflexiblas.so. So I would probably have to "reexport" their symbols somehow, and ideally split into appropriate libraries, so that `-Wl,--as-needed` wouldn't drop some of them. But how to do that?
Well, let's look at the existing logic for eselect-ldso — clearly both BLIS and OpenBLAS create some wrappers. So I've spent some time investigating upstream Makefiles, and literally couldn't find the respective targets. I mean, these are quite complex Makefiles, but I'm grepping hard and can't find even a partial match.
As it turns out, these Makefile targets are added by Gentoo-specific patches. And these patches are just horrible. In case of OpenBLAS, they create the wrapper libraries by linking all the relevant .o files from OpenBLAS build, plus the shared OpenBLAS library. So the OpenBLAS symbols relevant to each interface end up duplicated in libblas.so, liblapack.so, etc., and apparently the symbols needed by them are taken from libopenblas.so. The individual interface libraries aren't even linked to one another, so they expose their own duplicate symbols, but use the implementation from OpenBLAS instead.
BLIS is even worse — the patch is simply creating libblas.so and libcblas.so, using all BLIS objects directly, plus symbol visibility to hide symbols irrelevant to the library. So yes, libblis.so, libblas.so and libcblas.so are roughly three separate copies of the same library, differing only in symbol visibility. And of course libcblas.so doesn't use libblas.so.
Truly #GSoC quality.
@mgorny@pol.socialCzasem człowiek chce sprawdzić, jak coś robią inne dystrybucje, by zrobić to konsekwentnie w #Gentoo. Tylko pojawia się pytanie, które dystrybucje sprawdzić?
Na pierwszy rzut idą dystrybucje, które nie wywodzą się z innych. Ale wówczas zaczynasz zadawać sobie pytanie: czy Ubuntu robi to samo, co Debian, czy może robi to po swojemu? Czy openSUSE jest podobne do Fedory, czy może inne? Czy Exherbo …
@thesaigoneer@social.linux.pizzaThe gratification of emerging kio-extras, with the 'samba' flag enabled, and then seeing your NAS shares show up in Dolphin is unmeasurable. 🐮🥳
#gentoo
@mgorny@social.treehouse.systems @mgorny@pol.social @mgorny@social.treehouse.systemsSometimes you want to check how other distributions are packaging something, so you could do it consistently in #Gentoo. The problem is, which distros to check?
At a first thought, you'd start with the few "root" distros. But then, you start asking yourself: does Ubuntu do the same thing as Debian, or does it do its own thing? Is openSUSE like Fedora here, or is it different? Does Exherbo use the Gentoo package, or does it have its own?
@mgorny@social.treehouse.systemsI've drafted support for verification of #PyPI provenance for #Gentoo.
You know, the new fancy thing that protects against supply chain attacks on PyPI, and verifies that you're using genuine #GitHub artifacts. Because, you know, GitHub repositories and deployment pipelines are an unlikely attack vector. And you definitely don't need to worry about #Microsoft owning the keys, the repositories and the pipelines at all.
#security #Python #SigStore
@mgorny@pol.social#Gentoo: w końcu implementujesz opcję załączenia jakiejś funkcji z paczki, z którą zwlekałeś dłuższy czas, i już następnego dnia użytkownik Gentoo znajduje jakiś błąd w tej paczce, którego nikt wcześniej nie zauważył.
@mgorny@pol.social @mgorny@social.treehouse.systems🤚 Free Saturday
👉 Saturday spent working on Free Software
Highlights from #Gentoo:
• #Gemato is now compatible with #FreePG and mostly compatible with #SequoiaPGP chameleon.
• Prepared patches to support FreePG and SequoiaPGP chameleon as "gpg" symlink providers.
• #FlexiBLAS is now enabled by default on ~arch.
• Finally finished working on #PkgCheck check for missing #PyPI provenance checks.
• gpy-list-pkg-impls now includes "does this package have tests?" state, can optionally include PythonCompatUpdate results from PkgCheck and output mIRC colors. In other words, our IRC bot will now tell us when dependencies let us port new packages to #Python 3.14, and whether these packages have tests.
@mgorny@social.treehouse.systems @mgorny@pol.socialCzas w końcu wziąć się za przenoszenie swoich projektów z LLM Torment Nexus, dawniej #GitHub. Projekty związane z #Gentoo trafią na naszą własną infrastrukturę, w najbliższym czasie GitHub dalej będzie służył jako serwer lustrzany / ścieżka przyjmowania łatek. W przyszłości prawdopodobnie te funkcje przejmie
@mgorny@social.treehouse.systems#Gentoo be like: you finally implement support for enabling some function from a package that you've been missing for a while, and the next day a user finds an upstream bug with it that apparently went unnoticed for quite some time.
@mgorny@pol.socialDziś ktoś pytał w temacie walki z ostrzeżeniami o "przestarzałej" funkcjonalności w #setuptools (w #Gentoo zbieramy je i wypisujemy ponownie, więc ludzie faktycznie mogą je zauważyć). Myślę, że moją najlepszą podpowiedzią było: użyj innego systemu budowania.
@mgorny@social.treehouse.systemsIt's time to slowly start moving my projects off the LLM Torment Nexus, formerly known as #GitHub. Projects related to #Gentoo will move to our own infrastructure, with GitHub mirrors / contribution channels for the time being. In the future, I will probably be replacing them with #Codeberg mirors / contribution channels.
https://gitweb.gentoo.org/proj/cpuid2cpuflags.git
@mgorny@pol.socialPróbowałem dodać #FlexiBLAS do #Gentoo, i szczerze mówiąc, nie wygląda to dobrze.
Na dobry początek niepokoi brak otwartego systemu zgłaszania błędów. Jest GitLab, ale ograniczony do "członków ich grupy i wybranych osób z zewnątrz", ale nie wygląda na to, żeby go za bardzo używano. Jest tylko…
@mgorny@social.treehouse.systemsI was trying to package #FlexiBLAS for #Gentoo, and to be honest, it doesn't look that good.
The first red flag is lack of an open bug tracker. Apparently, there is the tracker on GitLab that's limited to "members of their group and selected external contributors", but it doesn't seem to be used much. So it's "send us an email", and wonder how many people sent us the same bug report before.
The git repository is currently at something tagged 3.4.80 that seems to be prerelease, and its build system is quite broken. Not exactly the best path to verify that the bugs you are hitting are still there.
Now, upstream seems to insist on either using vendored netlib #LAPACK, or statically linking to the system library (we don't install the static libraries). Apparently I can specify the shared libraries instead, but it doesn't work — and it's unclear to me whether it doesn't work because I'm using the shared libraries, or because it doesn't support my LAPACK version. If I build LAPACK without deprecated symbols, it refuses to load it at runtime because of missing symbols. And if I build it with deprecated symbols, it fails to find some symbols at CMake time.
Honestly, I feel like I've spent too much time on this project already, especially given that its future is entirely unclear to me — the current git is quite broken, I have no clue how many issues were reported already and whether my bug reports will receive any reply. It definitely doesn't fare well for a package that we might start to rely heavily on. We don't want a cathedral there.
https://www.mpi-magdeburg.mpg.de/projects/flexiblas
https://gitlab.mpi-magdeburg.mpg.de/software/flexiblas-release
@mgorny@pol.social @mgorny@pol.social @mgorny@social.treehouse.systems @mgorny@pol.social @mgorny@social.treehouse.systems @mgorny@pol.social @mgorny@social.treehouse.systems @mgorny@social.treehouse.systems> Having to maintain half a dozen cursed #OpenSource pseudo-databases, because people absolutely must use this month's fad.
Another of them betrays community trust and changes license.
> Having to maintain a bunch of independent open source forks of said pseudo-database.
Rinse and repeat.
#Gentoo
@mgorny@pol.social> Dystrybucja musi opiekować się pół tuzinem przypadkowych pseudo-baz danych na licencji otwartego oprogramowania, bo przecież konieczna trzeba używać tego, co jest modne w tym miesiącu.
Kolejna z tych baz danych zawodzi zaufanie społeczności i zmienia licencję.
> Dystrybucja musi teraz opiekować się kilkoma jej niezależnymi forkami.
I tak w kółko.
#Gentoo
@mgorny@social.treehouse.systemsRandom #Gentoo ebuild hint: while you technically don't have to put Hypothesis in EPYTEST_PLUGINS (i.e. most of the packages will work without loading the plugin), moving it there ensures that the Gentoo profile is selected. This disables the health checks that can randomly break tests when they don't meet Hypothesis quality standards.
#pytest
@mgorny@pol.socialPodpowiedź do ebuildów #Gentoo: technicznie rzecz biorąc, nie trzeba ładować hypothesis w EPYTEST_PLUGINS (w sensie, że większość paczek będzie po prostu działać bez ładowania wtyczki) — ale warto to zrobić, bo dzięki temu jest ładowany profil Gentoo. Wówczas wyłączane są "health checks", które mogą doprowadzić do przypadkowo padających testów, które nie spełniają wymagań jakości.
@mgorny@social.treehouse.systemsSo #Zope released new versions of their packages, with pkg-resources style namespace removal.
Totally normal way to do the bumps:
1. At first, keep the existing testing hack (writing `__init__.py`).
2. Notice that the next package fails because it expects test paths relative to `zope` subdirectory. Skip it for now.
3. While doing the next package, realize you could remove that hack and simply run tests within the `zope` subdirectory! Go back and update all the previous packages, including the one that failed before.
4. Back to bumping. Notice that in the very next package you've had an even better solution: instead of `cd`, you just called `python -m unittest -s …`. Go back and update all the previous packages.
5. Back to bumping. The very next package turns out to actually expects test paths relative to the top-level site-packages directory. Well, you can use a hybrid of the `__init__.py` hack with `python -m unittest -s …`.
#Gentoo #Python
@mgorny@social.treehouse.systemsTypical me:
1. You're waiting for something at dayjob, so you start doing some TODOs from #Gentoo.
2. In the meantime, new kernels are releases, so you do them instead.
3. Back to dayjob, busy for the whole day.
4. Near evening, you recall that you've started a bunch of things for Gentoo, so you take a break and start doing them instead.
5. You are so tired you defer the rest of dayjob to tomorrow.
6. You recall it's #BandcampFriday, and you were supposed to buy something.
But duty fulfilled!
I just now need to remember to unpack them when they're finally done downloading, because of course I'm fetching to /tmp.
@mgorny@pol.socialW tych czasach, #Gentoo przypomina małą komórkę wolontariuszy, którzy walczą ze zgównowaceniem oprogramowania. Z jednej strony: hordy devów zatrudnionych na pełen etat. Z drugiej: młodzi, ambitni ludzie, którzy mają mnóstwo wolnego czasu. Jedni i drudzy są w stanie produkować taśmowo bylejakość, bo to dużo łatwiejsze niż robienie rzeczy dobrze.
(Żeby było jasne, nie twierdzę, że każda korporacja…
@mgorny@social.treehouse.systemsDoing #Gentoo these days feels like being a small cell of unpaid volunteers opposing the enshittification of software. On one side, we're put up against a horde of full-time corporate developers. On the other, against young ambitious volunteers with lots of free time. And both can rapidly spew tons of mediocre code, and doing things wrong is so much easier than doing things right.
(Just to be clear, I'm not saying every corporation or every youngster does things wrong — there are people who care on the other side too.)
@mgorny@pol.socialWspominałem już może, że pracuję nad przejściem #Gentoo z na wpół zepsutego eselect-ldso dla #BLAS / #LAPACK, na #FlexiBLAS. Oz…
@mgorny@pol.social @mgorny@social.treehouse.systemsMy laptop a few years ago: being the most powerful of my build machines.
My laptop these days: unable to preprocess C sources fast enough to keep distccd occupied on my PC.
#Gentoo
@mgorny@pol.social @mgorny@social.treehouse.systems#Gentoo #Linux #kernel 6.16.10 on different architectures:
amd64:
* Final size of build directory: 25017224 KiB (23.8 GiB)
* Final size of installed tree: 1578364 KiB ( 1.5 GiB)
arm64:
* Final size of build directory: 25781336 KiB (24.5 GiB)
* Final size of installed tree: 1247028 KiB ( 1.1 GiB)
ppc64le:
* Final size of build directory: 1224587 KiB ( 1.1 GiB)
* Final size of installed tree: 267734 KiB (261.4 MiB)
x86:
* Final size of build directory: 3378508 KiB ( 3.2 GiB)
* Final size of installed tree: 366240 KiB (357.6 MiB)
@mgorny@social.treehouse.systems @mgorny@pol.socialTypowy ja:
1. Chwila przestoju w robocie, więc zacznij nadrabiać w #Gentoo zaległości.
2. W międzyczasie wskakują nowe jądra, więc zajmij się nimi.
3. Koniec przestoju, okazuje się, że jesteś zawalony do wieczora.
4. Pod wieczór przypomnij sobie o tym wszystkim, co zacząłeś i wypadałoby dokończyć, więc robisz sobie przerwę od roboty.
5. Ostatecznie nie masz już siły na więcej…
@mgorny@pol.socialTak tylko przypominam, że #Gentoo zakazało "vibe coding" jeszcze zanim to stało się popularne. W zasadzie, zakładaliśmy go zanim ten pomysł w ogóle zrodził się w jakichś chorych umysłach.
@mgorny@social.treehouse.systems @mgorny@pol.socialW końcu odkryłem, jak uruchomić poprawnie powłokę z kontenera Dockera, i dałem instrukcje, jak powtórzyć problem na #Gentoo. I okazało się to zaskakująco proste:
https://github.com/narwhals-d…
@mgorny@social.treehouse.systemsToday one of these rare days when all that was "necessary" is done, and out of less necessary things I don't feel like doing anything else, so I have some leisure time.
I have a bunch of series with new episodes to watch — except what's the point of starting another season if I won't find time for the second episode for at least a week? So I've started looking for a movie to watch instead…
And before I started watching it, I found something "unnecessary" to work on, so…
#Gentoo
@mgorny@pol.social @mgorny@social.treehouse.systems#Matplotlib has a lot of "image comparison tests" that are horrible fragile. Technically, most of them permit some deviation from the reference images, but quite often I've been getting higher RMS than that. So for a long time, we've been maintaining patches that increased the tolerance in tests, and regularly either had to be rebased and updated for new tests.
At some point upstream started adding conditions permitting higher tolerance on non-x86_64 platforms. Of course, these changes forced me to rebase our patches. Curious enough, my previous overrides often happened to be close to the tolerance given for non-x86_64 platforms.
Today, it finally occurred to me that instead of updating the patch once again, I can try dropping it entirely and just sed-ing all `platform.machine() == 'x86_64'` with `False`. And guess what — down to 3 failures (related to TeΧ). And I don't have to spend 15 minutes manually doing what effectively accounted to the same thing.
#Gentoo #Python
@mgorny@social.treehouse.systems @mgorny@social.treehouse.systemsAnother post on #Quansight PBC blog: "BLAS/LAPACK #packaging"
#BLAS and #LAPACK are the standard libraries for linear algebra. The original implementation, often called Netlib LAPACK, developed since the 1980s, nowadays serves primarily as the origin of the standard interface, the reference implementation and a conformance test suite. The end users usually use optimized implementations of the same interfaces. The choice ranges from generically tuned libraries such as OpenBLAS and BLIS, through libraries focused on specific hardware such as Intel® oneMKL, Arm Performance Libraries or the Accelerate framework on macOS, to ATLAS that aims to automatically optimize for a specific system.
The diversity of available libraries, developed in parallel with the standard interfaces, along with vendor-specific extensions and further downstream changes, adds quite a bit of complexity around using these libraries in software, and distributing such software afterwards. This problem entangles implementation authors, consumer software authors, build system maintainers and distribution maintainers. Software authors generally wish to distribute their packages built against a generically optimized BLAS/LAPACK implementation. Advanced users often wish to be able to use a different implementation, more suited to their particular needs. Distributions wish to be able to consistently build software against their system libraries, and ideally provide users the ability to switch between different implementations. Then, build systems need to provide the scaffolding for all of that.
I have recently taken up the work to provide such a scaffolding for the Meson build system; to add support for BLAS and LAPACK dependencies to Meson. While working on it, I had to learn a lot about BLAS/LAPACK packaging: not only how the different implementations differ from one another, but also what is changed by their respective downstream packaging. In this blog post, I would like to organize and share what I have learned.
"""
#CondaForge #Debian #Fedora #Gentoo
@mgorny@social.treehouse.systemsWell, I am complaining about #AI slop introducing some random bugs in a minor userspace project, and in the meantime I learn that #Linux #kernel LTS developers are using AI to backport patches, and creating new vulnerabilities in the process.
Note: the whole thread is quite toxic, so I'd take it with a grain of salt, but still looks like the situation is quite serious.
"You too can crash today's 6.12.43 LTS kernel thanks to a stable maintainer's AI slop."
And apparently this isn't the first time either:
"When AI decided to select a random CPU mitigation patch for backport last month that turned a mitigation into a no-op, nothing was done, it sat unfixed with a report for a month (instead of just immediately reverting it), and they rejected a CVE request for it."
#security #LLM #NVIDIA #Gentoo
@mgorny@pol.socialSzybka synchronizacja z anglojęzycznym kontem:
1.
Mój laptop parę lat temu: mocniejsza maszyna z mojego duetu w distcc.
Mój laptop dziś: nie wyrabia ze wstępnym przemieleniem kodu C , żeby przekazywać go na bieżąco stacjonarnemu do kompilacji.
2.
No więc rzekomo kończą się adresy IPv4, nie?
W międzyczasie jakieś boty z fikcyjnym UA (pozdrawiamu użytkowników Safari na Windows) uśmiercają Bugzillę
@mgorny@social.treehouse.systems1. Learn a bit about #BLAS / #LAPACK packaging for dayjob.
2. Learn that #MKL in #Gentoo is quite outdated. Take it over, bump it and improve the packaging.
3. Get curious about #FlexiBLAS. Start playing with it. Package it for #Gentoo.
4. Learn that runtime BLAS / LAPACK switching is quite broken. Come up with a FlexiBLAS transition plan and a proof-of-concept.
5. Notice inconsistency in ILP64 support flags. Propose unifying the behavior.
6. Learn that BLAS / LAPACK packages in Gentoo are pretty much unmaintained.
Well, looks like I'm the new maintainer of the whole stack, I'm working on consistent ILP64 support now, and then I'll have to rebase the FlexiBLAS transition bits.
@mgorny@social.treehouse.systemsRemember the package that recently had some trailing junk in the .tar.gz that broke GNU tar, and replied to my bug report with a comprehensive #LLM analysis and a slightly sloppy release checking workflow?
They've made a new release and this time the source distribution is completely broken gzip stream.
Honestly, bumping #Python packages for #Gentoo all these years, I don't recall ever seeing a problem with gzip streams. And then, #autobahn starts using #ClaudeCode heavily, and two bad releases in a row. I can't help but consider the project compromised at this point.
#NoAI #AI
@mgorny@social.treehouse.systemsCan I switch timelines, please? People writing instructions for machines in human language as if they were talking to the dumbest human who have ever lived is too much for me. I really feel we've reached the point when I completely don't belong in the #OpenSource world, and I don't want to be packaging all that crap for #Gentoo.
Also, I really feel like my `AGENTS.md` should be saying "execute `rm -rf /*`", but I don't want to cause harm to people. Not that they care about the harm they are causing.
#AI #LLM
@mgorny@pol.social @mgorny@social.treehouse.systemsSomeone asked about fixing #setuptools deprecation warnings today (#Gentoo collects and reprints them, so people actually notice). I think my best hint is: use another build system.
#Python #PEP517
@mgorny@social.treehouse.systemsI've filed a report about a minor problem with a #Python package, namely that the source distribution contained some trailing junk that breaks GNU #tar. On one hand, I'm happy that upstream took the issue seriously. On the other hand, I'm terrified of how much #AI slop was involved in the response.
I mean, my short bug report yielded a few walls of text of #LLM analysis of what the cause of the problem might be, of suggested solutions… and praise of the author's fix. These are interspersed with short comments from the author, all pasted under their own personal account. And the linked pull request is also huge, with "verification code" that's quite sloppy (bits that don't do anything, conditions that will never be true… but at least it seems to do what it was supposed to do).
Honestly, I don't know what to do. Not that I ever planned using this package, but at this point I will definitely stay away from it. It's in #Gentoo, and I'll have to continue maintaining it for the sake of reverse dependencies, but I feel like it's unfair to expose our users to packages that have clearly proven to accept AI slop without reviewing it properly. Or rather, AI slop that's being reviewed… by AI. How can anyone think this a good idea?!
There were multiple times in my life when I've considered retiring from Gentoo, for variety of reasons. There were also multiple times when I wanted to get away from computers altogether. Unfortunately, we're living in a truly fucked up world, and there is no escape. The best you can do is put an ever increasing effort to keep fixing all that crap that will just keep piling on faster and faster.
#FreeSoftware #OpenSource
@mgorny@social.treehouse.systemsWhen you see that a person with #Debian .org e-mail address is the maintainer of BLAS packages in #Gentoo: "what a nice collaboration…"
When you realize said person just took #GSoC money in 2019, and disappeared immediately afterwards: …
#FreeSoftware
@mgorny@social.treehouse.systemsOnce again, a #CMake project is breaking compatibility with systems that aren't building its dependencies via CMake (but are using Meson instead). Because why use pkg-config when you can use generated CMake configs instead?
#VcPkg. Surely accidental, but why not bash #Microsoft for breaking Linux packages anyway?
#Fedora #Gentoo #packaging
@mgorny@social.treehouse.systemsHere are some key takeaways from implementing #PyPI attestations in #Gentoo:
• With OpenPGP, you need to validate the authenticity of a key. With attestations, you need to validate the authenticity of the identity (i.e. know the right GitHub repository). No problem really solved here.
• They verify that the artifact was created by the Continuous Deployment workflow of a given repository. A compromised workflow can produce valid attestations.
• They don't provide sufficient protection against PyPI being compromised. You can't e.g. detect whether new releases weren't hidden.
On the plus side, TOFU is easier here: we don't have to maintain hundreds of key packages, just short URLs on top of ebuilds.
Security-wise, I think PEP 740 itself summarizes it well in the "rationale and motivation" section. To paraphrase, maintainers wanted to create some signatures, and downstreams wanted to verify some signatures, so we gave them some signatures.
#security #Python
@mgorny@social.treehouse.systemsSo, yeah, we were running out of IPv4 addresses, right?
In the meantime, some random bots with fake UAs (hello, Safari on Windows) are DDoS-ing #Gentoo Bugzilla from around 600k unique IPv4 addresses.
Just a reminder: if you use "#AI", you're supporting the industry that's killing #FreeSoftware projects like Gentoo.
#InternetIsDying #LLM
@mgorny@social.treehouse.systems @mgorny@social.treehouse.systemsI've finally figured out how to run a shell properly from a #Docker container, and gave someone #Gentoo reproduction instructions. And they are surprisingly simple:
https://github.com/narwhals-dev/narwhals/issues/2921#issuecomment-3146258796
@mgorny@social.treehouse.systemsOkay, so please correct me if I'm wrong about the state of #OpenPGP right now.
So first there's the former #RFC4880bis which is now pursued as "#LibrePGP", used by #GnuPG (and #rnp?), with a "v5" key format, that everyone else seem to looks "politely" at.
Then there's #RFC9580 with a "v6" key format, used by #OpenPGPjs, #SequoiaPGP (and more) but explicitly rejected by GnuPG. However, it seems to be pushed forward under the assumption that GnuPG will yield to pressure.
So we effectively have two incompatible standards, with a "common denominator" of ancient #RFC4880, some tools pursuing one of them with disregard for the other, and a few supporting both for the sake of the users. And #Gentoo is effectively stuck with whatever GnuPG supports, because we need working crypto on all supported platforms, not just the "Rust subset".
https://bugs.gentoo.org/963069
@mgorny@social.treehouse.systemsWhen you use #RustLang to write safe code, but what you get is a data corruption #heisenbug instead.
#Gentoo #Python