fosstodon.org is one of the many independent Mastodon servers you can use to participate in the fediverse.
Fosstodon is an invite only Mastodon instance that is open to those who are interested in technology; particularly free & open source software. If you wish to join, contact us for an invite.

Administered by:

Server stats:

8.8K
active users

#mitmproxy

0 posts0 participants0 posts today

🤣 Oh, look! Another techie spends "a couple of hours" cracking open Claude Code like it's their personal piñata! Spoiler alert: they found it's slower and pricier than a toddler on a sugar high. 🚀 But hey, at least they got to flex their terminal skills with some #mitmproxy magic! 🧙‍♂️✨
kirshatrov.com/posts/claude-co #techiefun #piñata #hacking #terminalskills #ClaudeCode #HackerNews #ngated

kirshatrov.comReverse engineering Claude Code • Kir Shatrov

No więc skończyłem walkę z segfaultem w #mitmproxy-linux. Okazuje się, że segfault miał miejsce w #Gentoo #Sandbox. Nadebugowałem się, ale znalazłem przyczynę. Otóż, okazuje się, że z jakiegoś powodu, aya_ebpf nadpisuje systemową implementację memcpy() własną, napisaną w Ruście, która zwraca niepoprawną wartość.

#RustLang jest naprawdę wspaniałym tworem.

github.com/aya-rs/aya/issues/1

GitHubaya_ebpf overrides C library `memcpy()` function with an implementation with incorrect return value · Issue #1254 · aya-rs/ayaBy mgorny

So finished debugging #mitmproxy-linux segfault. It turned out it was a segfault in #Gentoo #Sandbox. After dire debugging, it turns out that, for some reason, aya_ebpf crate overrides the system memcpy() function with a #RustLang implementation that has incorrect return value.

Rust is truly impressive.

github.com/aya-rs/aya/issues/1

GitHubaya_ebpf overrides C library `memcpy()` function with an implementation with incorrect return value · Issue #1254 · aya-rs/ayaBy mgorny

Aktualizacja w temacie #mitmproxy, czyli jak nie zamierzałem spędzać soboty.

Poprzednio: pol.social/@mgorny/11436480116

Tak więc:

1. Z pomocą osoby nickiem vadorovsky, dowiedziałem się, że jak dam --no-default-features, to bpf-linker użyje systemowego LLVM, i w ten sposób pozbyłem się problemów nr. 2 i 4.
2. #LLVM 20 nadal się sypie, ale jakimś cudem wtorkowy snapshot LLVM 21 działa.
3. Musiałem wrzucić btfdump na potrzeby testów, ale teraz wszystkie przechodzą.
4. Zmarnowałem godziny na budowanie mitmproxy-linux, ale w końcu znalazłem sposób. Otóż, okazuje się, że muszę wywalić logikę budowania binarek w formacie bpf z tej paczki, zbudować je ręcznie z poprawną wartością RUSTFLAGS, a potem połączyć to w całość. github.com/mitmproxy/mitmproxy
5. Problem z rustc-build-sysroot jest jeszcze gorszy w mitmproxy-linux.
6. Testy mitmproxy-linux segfaulcą (jak to #RustLang).
7. Ale jak już wszystko poinstaluję, to testy mitmproxy przechodzą.

Więc zostaje mi wymyślić, co zrobić z tymi segfaulcącymi testami, i myślę, że nowa wersja mitmproxy może wylądować w #Gentoo. Przypięta do pojedynczej wersji kompilatora Rusta, ale zawsze coś.

Pol.socialmgorny-nyan (on) :autism:🙀🚂🐧 (@mgorny@pol.social)Zmarnowałem kolejną godzinę na użeranie się z próbą dodania bpf-linker / nowej wersji #mitmproxy do #Gentoo. Podsumowując: 1. Wymaga funkcji, dostępnych wyłącznie w eksperymentalnych wersjach kompilatora #RustLang. Można to obejść, ustawiając RUSTC_BOOTSTRAP=1. https://github.com/aya-rs/bpf-linker/issues/250 2. Wymaga innych wersji kilku bibliotek poprzez zależność aya-rustc-llvm-proxy, jakimś cudem. Można to albo rozwiązać dodając do ebuilda owe wersje, albo usuwając z wypakowanego archiwum plik `Cargo.lock`. 3. Wymaga `compiler_builts` poprzez zależność rustc-build-sysroot. Co ciekawe, konkretna wersja jest przypięta wewnątrz biblioteki standardowej Rusta, więc musiałbym dodać odpowiednią wersję zależności dla każdej obsługiwanej wersji kompilatora! 4. Ma własną logikę wyszukiwania biblioteki #LLVM, która porusza się po PATH i podmienia `bin` na `lib`. Tak, na katalog z 32-bitowymi bibliotekami. Da się to obejść, ustawiając LD_LIBRARY_PATH. https://github.com/aya-rs/bpf-linker/issues/270 5. Nawet jak obejdę wszystkie inne problemy, to koniec konców się sypie na użyciu LLVM. Zgaduję, że nikomu nie przyszło do głowy użyć do testów LLVM z kontrolą poprawności użycia API. https://github.com/aya-rs/bpf-linker/issues/271 No cóż, taka jakość programów pisanych w Ruście. Co gorsza, te wszystkie problemy dotyczą nie budowania, a uruchamiania bpf-linkera — więc tak czy siak, instalowalibyśmy program, który w ogóle nie działa bez dodatkowych obejść.

#mitmproxy update AKA not how I imagined spending my Saturday.

Previous post: social.treehouse.systems/@mgor

So:

1. With help of vadorovsky, I've learned that I need to pass --no-default-features, and then it uses system LLVM which resolves problems 2. and 4.
2. #LLVM 20 still fails on that assertion, but Tuesday's LLVM 21 snapshot works fine.
3. I also needed to package btfdump for bpf-linker's tests but I was finally able to get them to pass.
4. After spending hours trying to figure out mitmproxy-linux build failures, I've finally found a way to build it: I need to remove upstream's logic for building bpf binaries, build them manually with correct RUSTFLAGS, and then build the whole thing. github.com/mitmproxy/mitmproxy
5. rustc-build-sysroot crate problem is even worse in mitmproxy-linux.
6. mitmproxy-linux's tests segfault (yeah, #RustLang).
7. But still, with the packages built, I can get tests to pass on mitmproxy itself.

So yeah, if I can only figure out what to do about these segfaulting tests, I think we can get new mitmproxy version into #Gentoo. Pinned to one Rust version, but that's better than nothing, I guess.

Treehouse Mastodonmgorny-nyan (he) :autism:🙀🚂🐧 (@mgorny@treehouse.systems)Spent another hour on trying to get bpf-linker / new #mitmproxy into #Gentoo. To summarize: 1. It needs features from nightly #RustLang compiler at runtime. This can be worked around via setting RUSTC_BOOTSTRAP=1. https://github.com/aya-rs/bpf-linker/issues/250 2. It needs different pinned versions of some libraries via aya-rustc-llvm-proxy somehow. This can be solved via manually adding more crates to the ebuild (sigh) or just removing the extra `Cargo.lock` from the crate. 3. It needs `compiler_builtins` crate via rustc-build-sysroot crate. Funny enough, the version is pinned by Rust standard library itself, so I need to add a specific crate for every supported Rust compiler version! 4. It uses a homemade logic to find #LLVM library, which iterates over PATH and replaces `bin` with `lib`. Yes, with 32-bit libdir. It can be worked around via setting LD_LIBRARY_PATH. https://github.com/aya-rs/bpf-linker/issues/270 5. Even after working around all these issues, it crashes by triggering an assertion in LLVM. I guess nobody bothered testing with assertions enabled, as usual. https://github.com/aya-rs/bpf-linker/issues/271 So yeah, that's your Rust quality. On top of that, let's not forget that this is all runtime issues — like we would be installed a bpf-linker executable that's nonfunctional unless you apply workarounds.

Zmarnowałem kolejną godzinę na użeranie się z próbą dodania bpf-linker / nowej wersji #mitmproxy do #Gentoo. Podsumowując:

1. Wymaga funkcji, dostępnych wyłącznie w eksperymentalnych wersjach kompilatora #RustLang. Można to obejść, ustawiając RUSTC_BOOTSTRAP=1. github.com/aya-rs/bpf-linker/i
2. Wymaga innych wersji kilku bibliotek poprzez zależność aya-rustc-llvm-proxy, jakimś cudem. Można to albo rozwiązać dodając do ebuilda owe wersje, albo usuwając z wypakowanego archiwum plik `Cargo.lock`.
3. Wymaga `compiler_builts` poprzez zależność rustc-build-sysroot. Co ciekawe, konkretna wersja jest przypięta wewnątrz biblioteki standardowej Rusta, więc musiałbym dodać odpowiednią wersję zależności dla każdej obsługiwanej wersji kompilatora!
4. Ma własną logikę wyszukiwania biblioteki #LLVM, która porusza się po PATH i podmienia `bin` na `lib`. Tak, na katalog z 32-bitowymi bibliotekami. Da się to obejść, ustawiając LD_LIBRARY_PATH. github.com/aya-rs/bpf-linker/i
5. Nawet jak obejdę wszystkie inne problemy, to koniec konców się sypie na użyciu LLVM. Zgaduję, że nikomu nie przyszło do głowy użyć do testów LLVM z kontrolą poprawności użycia API. github.com/aya-rs/bpf-linker/i

No cóż, taka jakość programów pisanych w Ruście. Co gorsza, te wszystkie problemy dotyczą nie budowania, a uruchamiania bpf-linkera — więc tak czy siak, instalowalibyśmy program, który w ogóle nie działa bez dodatkowych obejść.

GitHub`compile_test` fails with non-nightly compiler · Issue #250 · aya-rs/bpf-linkerBy mgorny

Spent another hour on trying to get bpf-linker / new #mitmproxy into #Gentoo. To summarize:

1. It needs features from nightly #RustLang compiler at runtime. This can be worked around via setting RUSTC_BOOTSTRAP=1. github.com/aya-rs/bpf-linker/i
2. It needs different pinned versions of some libraries via aya-rustc-llvm-proxy somehow. This can be solved via manually adding more crates to the ebuild (sigh) or just removing the extra `Cargo.lock` from the crate.
3. It needs `compiler_builtins` crate via rustc-build-sysroot crate. Funny enough, the version is pinned by Rust standard library itself, so I need to add a specific crate for every supported Rust compiler version!
4. It uses a homemade logic to find #LLVM library, which iterates over PATH and replaces `bin` with `lib`. Yes, with 32-bit libdir. It can be worked around via setting LD_LIBRARY_PATH. github.com/aya-rs/bpf-linker/i
5. Even after working around all these issues, it crashes by triggering an assertion in LLVM. I guess nobody bothered testing with assertions enabled, as usual. github.com/aya-rs/bpf-linker/i

So yeah, that's your Rust quality. On top of that, let's not forget that this is all runtime issues — like we would be installed a bpf-linker executable that's nonfunctional unless you apply workarounds.

GitHub`compile_test` fails with non-nightly compiler · Issue #250 · aya-rs/bpf-linkerBy mgorny