Arti (Tor на Rust)

2024-06-21 есть кто то хорошо разбирающийся в Rust ?!
1) какого фига оно каждый раз даже с установленным sccache перекомпилирует ВЕСЬ проект ?
у меня /target +- 1ГБ для каждого варианта сборки (это помимо общего)
огромный список просто нижние строчки
61M ./i686-pc-windows-gnu/release/incremental/arti-3gpeybwopn9nb/s-gxbdd927dc-j0fwys-7g4e9zavzcynktoc6ryshntmr
61M ./i686-pc-windows-msvc/release/incremental/arti-x8uzb37lgp4w/s-gxbdxslke7-1x086o9-47gvw8p4p8c91d04ww8ox5zb5
61M ./x86_64-pc-windows-gnu/release/incremental/arti-1vxotnlhm46c8/s-gxbdnge1en-z2xa0g-8i51p1jim6g3oxpjxtbkw3q1d
63M ./x86_64-pc-windows-msvc/release/incremental/arti-6gzu4j0zca7m/s-gxbe601lpl-1jldemh-i9rvfne83p3u24rsdtiomy8p
401M ./i686-pc-windows-msvc/release/deps
413M ./x86_64-pc-windows-msvc/release/deps
414M ./i686-pc-windows-gnu/release/deps
419M ./x86_64-pc-windows-gnu/release/deps
467M ./release/deps
C:\GitHub\arti\target>du -sh
3.9G .
env RUSTFLAGS=-Awarnings C:\Users\le0n\.cargo\bin\cargo.exe build^
--target i686-pc-windows-gnu^
--release^ -p arti^ --no-default-features^ --features static-sqlite,rustls,bridge-client,compression,dns-proxy,harden,onion-service-client,pt-client,tokio,vanguards
env RUSTFLAGS=-Awarnings C:\Users\le0n\.cargo\bin\cargo.exe build^
--target x86_64-pc-windows-gnu^
--release^ -p arti^ --no-default-features^ --features static-sqlite,rustls,bridge-client,compression,dns-proxy,harden,onion-service-client,pt-client,tokio,vanguards
env RUSTFLAGS=-Awarnings C:\Users\le0n\.cargo\bin\cargo.exe build^
--target i686-pc-windows-msvc^
--release^ -p arti^ --features static
env RUSTFLAGS=-Awarnings C:\Users\le0n\.cargo\bin\cargo.exe build^
--target x86_64-pc-windows-msvc^
--release^ -p arti^ --features static
2) у меня древние ПК и нотебук
Intel Core i5 3550 @ 3.30GHz + MSI Z77MA-G45 (MS-7759)
Intel® Core™ i7-2630QM (6M Cache, 2.00 GHz) + Intel HM67
будет ли толк (нашел на разных сайтах) чтобы cargo build не ждать по 20+ минут при сборке всех .exe (examples) ?
[profile.release]
codegen-units = 1
lto = false
opt-level = "z"
panic = "abort"
strip = "debuginfo"
debug = 0
incremental = true
3) с какого то момента стало требовать liblzma-5.dll для части таргетов
причем там ДВА варианта "клиентов" (только арти для 4х таргетов. и 4е таргета с "примерами")
--no-default-features^ --features static-sqlite,rustls,bridge-client,compression,dns-proxy,harden,onion-service-client,pt-client,tokio,vanguards
-p arti -p connection-checker -p obfs4-checker -p arti-testing^
--features static
пытался добавить в общий cargo/config.toml
не помогло
[dependencies]
liblzma-sys = "0.3.4"
c:\cygwin\bin\ldd.exe x86_64-gnu\arti.exe | grep lzma
liblzma-5.dll => /cygdrive/c/TOR/_arti/x86_64-gnu/liblzma-5.dll (0x7ff8dfa60000
c:\cygwin\bin\ldd.exe arti-1.2.4-x86_64-gnu.exe | grep lzma
liblzma-5.dll => /cygdrive/c/TOR/_arti/liblzma-5.dll (0x7ff8dfa60000)
и если уж не убрать зависимость какую DLL брать для большей совместимости для чужих windows ?
M:\_Microsoft\_MSYS2\mingw64\bin\liblzma-5.dll
M:\_Microsoft\_MSYS2\ucrt64\bin\liblzma-5.dll так то да. но тут же появятся апологеты WinXP или еще чего
тут под себя то собрать и то не всегда тривиально
а уж под вообще всех... ну у меня два варианта. просто -p arti
и для желающих -p arti -p connection-checker -p obfs4-checker -p arti-testing^
вроде самые нужные/полезные. остальное IMHO мусор. но если кому то надо пусть напишут. добавлю (если только не всё
собирать вообще все == время (на моих ПК это как писал 20+ минут для каждого таргета из 4х
места дофига .exe занимают даже в .RAR/.7zip
на меня и так github LFS матерится что якобы 1ГБ трафика за месяц уже потрачено
брать какой нибудь UPX стремно. и сломает чего в RUST и антивирусы будут орать ну для этого есть всякие dog/doge / doggo / etc мне важней настоящий ресолвер если dnscrypt будет тупить (было что один dnscrypt сервер не отдавал IP для vk.com) кстати есть такие "прокси" кто не может/хочет настраивать squid/etc с кучей правил/исключений/етк
https://ntc.party/t/cow-pd-etc/7982/1
можно подсунуть TOR / ARTI / Psiphon / opera-proxy / shadowsocks / etc
правда гонять весь трафик через TOR socks5 такое себе. все еще достаточно много http:// встречается
в винде == обновления windows. всякие сертификаты SSL обновляются
в linux не знаю как у других а убунту многие apt тянет по http и хотя они подписаны заблокировать их как минимум нефига делать
тот же MITM с https будет орать уже на коннекте к серверу
(хотя те кто как я ставили yandex-browser или тем более (не я.) поставили сертификаты "министерства правды" .....)
даже за каким то фигом Telegram
http://149.154.167.41/api POST
http://[2001:67c:4e8:f002::a]/api POST
у меня в ТОР настроено HTTPTunnelPort 127.0.0.1:9080 IPv6Traffic PreferIPv6
оно принимает только CONNECT (https в том числе?)
АРТИ пока этого не умеет (?!)

Чтобы дллки не требовало я всегда дописывал LDFLAGS=-static вначале. Но кажется Rust это игнорит.

ну сейчас у меня
что/как туда добавить ?
[target.x86_64-pc-windows-msvc]
rustflags = ["-C", "target-feature=+crt-static"]
[target.i686-pc-windows-msvc]
rustflags = ["-C", "target-feature=+crt-static"]
[target.x86_64-pc-windows-gnu]
rustflags = ["-C", "target-feature=+crt-static"]
[target.i686-pc-windows-gnu]
rustflags = ["-C", "target-feature=+crt-static"]

Это не в конфиг. В терминал перед cargo. Но это не сработает. Из этих четырех?
i686-pc-windows-gnu
i686-pc-windows-msvc
x86_64-pc-windows-gnu
x86_64-pc-windows-msvc
Разные архитектуры и тулчейны.
Или речь о чем-то другом? Повторная компиляции при обновлении версии, при выборе разных проектов (-p) / features?

у меня
arti1 (cargo update -p arti) собирается только -p arti
arti2 (cargo update) собираются arti-testing / connection-checker / obfs4-checker / arti
и по очереди собирают и там и там 4е таргета
и не знаю почему даже если не делать cargo clean повторные cargo build засирают еще больше и заново вижу делается Compiling почти всего ДЛЯ КАЖДОГО таргета
вот если только 1 папка исходная. и только 1 таргет
то если ничего не менялось то оно мгновенно "заканчивает" повторные cargo build
я так понимаю (может и ошибаюсь)
там общая папка для всех /release/ проектов "гадит"
если собрать один раз с --release а второй без (в /debug/) то они вроде тоже не мешают друг другу
это вывод из 2х разных папок в процессе сборки (2 из 4х таргетов)
226M ./target/release/deps
275M ./target/x86_64-pc-windows-gnu/release/deps
414M ./target/i686-pc-windows-gnu/release/deps
253M ./target/release/deps
274M ./target/i686-pc-windows-gnu/release/deps
553M ./target/x86_64-pc-windows-gnu/release/deps
Removing C:\GitHub\arti-onion\target
Removed 14117 files, 6.0GiB total
Removing C:\GitHub\arti\target
Removed 12201 files, 4.1GiB total
sccache --show-adv-stats
Cache hits (c [gcc]) 123
Cache hits (rust) 559
Cache misses (c [gcc]) 183
Cache misses (rust) 1873
Non-cacheable reasons:
crate-type 328
incremental 304
- 88
missing input 18
Cache size 1002 MiB
2024-06-22
сижу мучаю PD -> COW -> squid/privoxy/vpn/tor
хоть и слишком коряво. но "работает" само
http://imageshack.com/a/img922/4476/Wdmeln.png
start pd.exe^
-proxies=http://127.0.0.1:7777,http://127.0.0.1:888^
-listens=127.0.0.1:6699,192.168.1.111:6699^
-direct=./_direct.txt^
-blocked=./_blocked.txt^
-statfile=./_PD_stat.json
:888 это wingate который ЕДИНСТВЕННЫЙ нормально понимает два gateway/ISP на windows
http://imageshack.com/a/img924/1546/ElyuQh.png
http://imageshack.com/a/img924/1937/faMTd3.png
rc.txt для COW
alwaysProxy = true
loadBalance = backup
listen = http://127.0.0.1:7777
statFile = ./stat
blockedFile = ./blocked.txt
directFile = ./direct.txt
proxy = http://127.0.0.1:8118 #privoxy с разными правилами и блокировка по доменам
proxy = http://127.0.0.1:3128 #squid тоже куча правил и антиреклама по доменам
proxy = socks5://127.0.0.1:9090 #vpn
proxy = http://127.0.0.1:18080 #opera-proxy
proxy = http://127.0.0.1:9580 #TCP не socks ибо не настолько доверяю
proxy = http://127.0.0.1:9080 #TOR тоже самое
до этого стояли
squid == direct + privoxy (socks5 vpn) + opera-proxy + httptunnel TCP/TOR
но слишком много разных правил. иногда вообще "лезет не туда" или не находит нужный "прокси"
privoxy == socks5 VPN + socks5t TCP/TOR так как squid не умеет socks
не настолько гибкий в плане настроек как squid. совершенно мутные логи
squid но пока все это настроишь ...
TCP_TUNNEL/200 HIER_DIRECT/yandex.ru\2a02:6b8:a::a yandex.ru:443 CONNECT 405596(ms) 137059(byte)
TCP_DENIED/403 HIER_NONE/-\- assets.msn.com:443 CONNECT 15(ms) 3740(byte)
TCP_TUNNEL/200 FIRSTUP_PARENT/Opera\127.0.0.1 www.bing.com:443 CONNECT 2258(ms) 5728(byte)
TCP_TUNNEL/200 FIRSTUP_PARENT/Privoxy\127.0.0.1 api.github.com:443 CONNECT 30785(ms) 9596(byte)
опять/снова через АРТИ не работает https://ipv6-test.com/
2024-06-22T15:52:30Z INFO tor_dirmgr: Directory is complete. attempt=2
2024-06-22T15:52:30Z INFO tor_guardmgr::guard: We have found that guard [23. .99:443 via obfs4 $cafdb3585f1675c07b8f9a2383bfcceb148a97d7] is usable.
2024-06-22T15:52:33Z INFO tor_guardmgr::guard: We have found that guard [82. .247:443 via obfs4 ed25519:kjkZY78eJCSm19uD1iSu3oAe7BDQOhT5NxDdO05EtWo $652e2bfa56a8ed9497fe3b3976704486eb4b3971] is usable.
2024-06-22T16:01:20Z WARN arti::socks: connection exited with error: error: remote hostname lookup failure
2024-06-22T16:01:20Z WARN arti::socks: connection exited with error: error: remote hostname lookup failure
2024-06-22T16:01:30Z WARN arti::socks: connection exited with error: error: operation timed out at exit
2024-06-22T16:02:26Z WARN arti::socks: connection exited with error: error: operation timed out at exit
2024-06-22T16:02:28Z WARN arti::socks: connection exited with error: error: operation timed out at exit
2024-06-22T16:02:28Z WARN arti::socks: connection exited with error: error: operation timed out at exit
2024-06-22T16:02:28Z WARN arti::socks: connection exited with error: error: operation timed out at exit
2024-06-22T16:02:36Z INFO tor_guardmgr::guard: We have found that guard [82. .122:443 via obfs4 ed25519:yucMcOf6X9R1Fv6UoHE+nCwguHH9Fl8IO3hy8q5e08U $f1a695c5f67d8751e2aca8f5d10a9f08fdc1467c] is usable.
2024-06-23 засада ;(
PD не умеет direct/proxy фильтры http / https / CONNECT
switchy omega как оказалось на Chromium (brave, yandex, etc) тоже не умеет URL_regex с http/https
пихать http через Ростелеком напрямую такое себе. и уж тем более через TOR/ARTI
а как весело и задорно все соединялось...
пришлось делать в браузере прописан COW (always_proxy)
и PD как резервный прокси (далеко не первый) для COW
ибо PD работает через IPv6 где пока не блочат многое. хотя и IPv6 есть далеко не у всех сайтов/серверов
кстати подсказали еще одну проверялку IP/country для TOR/ARTI/vpn/etc
так же откликается на https://1.1.1.1/ https://[2606:4700:4700::1111]/cdn-cgi/trace [2606:4700:4700::1001]
curl -x 127.0.0.1:6699 https://one.one.one.one/cdn-cgi/trace
ip=2a00:62c0: :2b23
colo=DME
http=http/2
loc=RU
tls=TLSv1.3
sni=plaintext
все еще пытаюсь найти компромис размер-vs-времясборки
только arti.exe Finished profile [optimized] target(s) in 9m 11s
Building [==> ] 90/448
несколько (4е) .exe Finished profile [optimized] target(s) in 20m 37s
Building [==> ] 455/531
[profile.release]
strip = true
codegen-units = 1
lto = true
opt-level = "z"
panic = "abort"
debug = false
incremental = true
кстати попробовал не указывать -p arti -p arti-testing -p connection-checker etc
Building [=======> ] 236/658
Finished `arti` profile [optimized] target(s) in 24m 39s
нифига не быстрей.
2024-06-24 кто пользуется snowflake 4e набора "серверов" (реально работают вроде только 3и. fastfly у меня ругается на SSL/https сертификат.)
https://forum.torproject.org/t/fix-problems-with-snowflake-since-2024-03-01-broke...-no-answer/11755

Тогда для каждого таргета придется держать одну папку.
На линуксе такой проблемы нет, в том плане, что нет разделения на msvc и gnu, а кросскомпилингом (--target) для разных архитектур я не занимаюсь из-за проблем со сборкой сишного openssl. Так что для каждой архитектуры одна ОС (виртуальная), даже так. Это очень костыльно, конечно, но я не спец.
Rust еще хранит кэш (сборок?) в папке .cargo.
Я -p не указываю и у меня собирается все возможное, 12 бинарников. Это раза в два дольше, чем с -p arti.

что то совсем сломали в последних commits ?
соединился. работал. а потом ОППА
http://imageshack.com/a/img923/7947/V7cA9n.png
хотя потом запустил другую сборку. с чистыми cache/state. вроде нормально заработало
надо смотреть долго и часто ... ну там нашел возможность через профили
но места будет сжирать... если только часто пересобирать без обновлений git pull/cargo update частых
[profile.arti1]
inherits = "release"
[profile.arti2]
inherits = "release"
--profile arti1 # это вместо --release
и тогда она создает \target\arti1\ \target\arti2\ etc я даже костыль в виде sccache поставил с 2ГБ лимитом
ну вроде немного помогает
до "замены tor.exe" там еще дальше чем я думал?
багофиче уже 3+ года
на windows тупо не собирается ни tor-circmgr/ntor_v3 ни даже arti-client/keymgr
ибо signal-hook-tokio только для "unix"
не знаю можно ли через async-std обойти. те обсуждения что нашел так ничем и не закончились
ну и уже писал
собираем
-p arti^ --no-default-features^ --features static-sqlite,rustls
получаем rustls
собираем -p arti -p connection-checker -p obfs4-checker -p arti-testing^ --no-default-features^ --features static-sqlite,rustls
и получаем native-tls
ибо как я понимаю где то зависимость зависимости от зависимости плюет на все опции
после прочтения форумов и перепробовав несколько вариантов как с --features FULL так и без него
с тестовыми флагами вроде собирается вот так
env LDFLAGS=-static RUSTFLAGS="-Ctarget-cpu=native -Awarnings" cargo build --release --no-default-features --features static-sqlite,rustls,bridge-client,compression,dns-proxy,harden,onion-service-client,pt-client,tokio,vanguards,arti-client/keymgr,tor-circmgr/ntor_v3
но без указания -p arti или даже --bin arti. так что собирается вообще всё включая shadow/etc
это ПП какой то
две сборки. только 1 таргет и там и там
Finished `release` profile [optimized] target(s) in 41m 37s
Finished `release` profile [optimized] target(s) in 41m 43s
95M ./target/release
96M ./target/release/incremental/arti_testing-387swimziq65x/s-gxfmxc2ad5-ypxfu9-8ydkwnnj5n4t7zvvh6c4cut9c
97M ./target/release/incremental/arti_bench-31rxuyrvlrk8m/s-gxfm9l5jee-1qc02aq-3gv5r6r3v6555835j89fbg4fp
97M ./target/release/incremental/arti_testing-33zvxjwfukbwo/s-gxg486jyqu-1xvxn3u-9pibivdqlfnbhgag5k41ost37
98M ./target/release/incremental/arti_bench-vtepi9tuc8t6/s-gxg3neffnk-3tqm6c-8xzu8f9kko7jo3fk9owajg4z4
2.4G ./target/release/deps
Removed 11767 files, 8.1GiB total

---

2024-06-26 нашел откуда liblzma-5.dll пролезли
-gnu собирал через rustup.exe default stable-gnu
-msvc через rustup.exe default stable-msvc
так вот при toolchain -gnu оно как раз добавляло зависимость от внешней библиотеки
\_MSYS2\mingw64\bin\liblzma-5.dll (ну или \_MSYS2\ucrt64\bin\liblzma-5.dll)
installed toolchains
stable-x86_64-pc-windows-gnu
stable-x86_64-pc-windows-msvc (default)
installed targets for active toolchain
i686-pc-windows-gnu
i686-pc-windows-msvc
x86_64-pc-windows-gnu
x86_64-pc-windows-msvc
увеличил размер sccache до 10ГБ ...
cargo cache sccache
Files Day Size Percentage
1299 2024-06-24 739.23 MB 17.94 %
3954 2024-06-25 2.26 GB 54.83 %
2476 2024-06-26 1.12 GB 27.23 %
но помогает вроде уже неплохо
после разделения каждого варианта сборки на --profile arti1_64_gnu --profile arti2_32_msvc etc
Cache hits (C/C++) 452
Cache hits (Rust) 2342
Cache misses 244
2024-06-27
"x86_64-unknown-linux-gnu"
# Disabled for now, see #1480 and https://github.com/rust-num/num-bigint/issues/311
#"x86_64-unknown-linux-gnux32"
"x86_64-unknown-linux-musl"

Каких только зверей нет в природе.

чтото сломалось толи в obfs4-lyrebird толи в АРТИ
2024-06-27T15:17:12Z INFO tor_ptmgr::ipc::sealed: Launching pluggable transport at lyrebird-64.exe for [PtTransportName("obfs4")]
2024-06-27T15:17:12Z WARN tor_ptmgr: Spawning PT for [PtTransportName("obfs4")] failed: Couldn't parse IPC line "STATUS TYPE=version IMPLEMENTATION="lyrebird" VERSION="devel"": no TRANSPORT in STATUS
2024-06-27T15:17:12Z WARN tor_ptmgr: PT for obfs4 failed to launch: Couldn't parse IPC line "STATUS TYPE=version IMPLEMENTATION="lyrebird" VERSION="devel"": no TRANSPORT in STATUS я пытался собрать даже такое. тем более он есть в официальных таргетах...
но нифига. куча ошибок про библиотеки/линковку/етк
по форумам вроде надо самому пересобирать таргет из исходников через mingw(?!)
не для меня и моего "программирования".
[target.i586-pc-windows-msvc]
#rustflags = ["-C", "target-feature=+crt-static"]
rustflags = ["-Ctarget-feature=+crt-static"]
installed targets for active toolchain
i586-pc-windows-msvc
p.s. "победил" M:\_Microsoft\_MSYS2\ucrt64\bin\jq.exe
в родном shell от MSYS оно не матерится на
jq -r '.relays[] | select(.consensus_weight >= 10000 ) | "\(.or_addresses[1]) \(.fingerprint) \(.consensus_weight) \(.country) \(.flags) \(.version)"'
cargo build --jobs 1 --target i586-pc-windows-msvc -p arti --features static
Compiling arti v1.2.4 (C:\GitHub\arti\crates\arti)
error: linking with `M:\_Microsoft\_llvm\18_1_7\bin\lld-link.exe` failed: exit code: 1
note: lld-link: error: could not open 'windows.0.48.5.lib': no such file or directory
error: could not compile `arti` (bin "arti") due to 1 previous error
M$ анти"вирус" опять нашел чтото (уже было срабатывание на другой билд)
http://imageshack.com/a/img923/3595/DTp04A.png
https://www.virustotal.com/gui/file/35136459eaf97f676d51b3c453e46b0dbc366723f8dbc...71e5dd?nocache=1
в RUST даже с win7 как я понимаю все грустно 2024-06-28 1.2.5
https://gitlab.torproject.org/tpo/core/arti/-/blob/main/CHANGELOG.md
все чудесатее и чудесатее
не собираются cargo build^
-p arti -p connection-checker -p obfs4-checker -p arti-testing^
--features static
Compiling arti-client v0.20.0 (C:\GitHub\arti-onion\crates\arti-client)
error[E0599]: no method named `generate` found for reference `&Arc<KeyMgr>` in the current scope
--> crates\arti-client\src\client.rs:1440:14
1434 | let key = self
1435 | | .keymgr
1436 | | .as_ref()
1437 | | .ok_or(ErrorDetail::KeystoreRequired {
1438 | | action: "generate client service discovery key",
1439 | | })?
1440 | | .generate::<HsClientDescEncKeypair>(
| | -^^^^^^^^ method not found in `&Arc<KeyMgr>`
error: could not compile `arti-client` (lib) due to 1 previous error
работают -p arti или вообще не указывать -p/--bin
https://github.com/LeonMskRu/arti_windows/releases/tag/1.2.5

Пекут как пирожки.
Нужны ли кому-нибудь линуксовые сборки? Потому что мне лень собирать.

lyrebird ЗАПУСКАЕТСЯ без ошибок у меня только если выбрать refs/tags/lyrebird-0.2.0
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-....0?ref_type=tags
на main нифига чтобы не делал (может и не все что "надо".) не работало
ну или fix_dependency_redirect
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/branches
даже obfs4proxy собрал чтобы проверить

Поучительная история про обычный TOR — как один дохлый мост в конфиге может всё испортить:
Если у нас прописаны только живые obfs4-мосты (одного достаточно), тор к ним сразу же подключается и быстренько грузится до 100%.
Но при наличии в конфиге одного или нескольких дохлых obfs4 ИНОГДА бывает так, что тор подключается к живым,
доходит до "Bootstrapped 25% (requesting_status): Asking for networkstatus consensus", а потом вдруг решает:
"давай-ка я живые мосты больше трогать не буду и начну долбиться в дохлые". И ВСЁ, дальше этих 25% загрузка не идёт.
Подтверждено логами. Я это видел несколько раз и только что дважды воспроизвёл:
7 (!) живых obfs4 + 3 дохлых = не грузится.
Пишет вот такую чушь, хотя мосты ещё как available: LeonMskRu, мы как раз недавно обсуждали юзеров мегафона с этой проблемой 25%.
Я думаю, этот симптом говорит о том, что юзеру надо просто найти и удалить из конфига всю дохлятину.
Мне сама эта отметка сразу показалась странной: если рабочих мостов совсем нет, тор при загрузке и до 25% не дойдёт.
Не знаю, как в подобной ситуации ведёт себя ARTI.

вобщем пока не нашел в чем косяк с "последним" lyrebird
как то так
git checkout --detach tags/lyrebird-0.2.0
git switch --detach tags/lyrebird-0.2.0 --recurse-submodules
работает.
единственное что нашел
после git pull origin main + go get -u нет этих строчек (те модули что есть одинаковые версии и там и там)
go: upgraded gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel v0.0.0-20240220175603-399c24557a18 => v0.0.0-20240507101150-3b6faa481637
go: upgraded golang.org/x/crypto v0.21.0 => v0.24.0
go: upgraded golang.org/x/net v0.22.0 => v0.26.0
go: upgraded golang.org/x/sys v0.18.0 => v0.21.0
go: upgraded golang.org/x/text v0.14.0 => v0.16.0
при переключении на 0.2.0 они есть еще хуже.
я специально написал батники. чтобы каждый раз как что то меняется (например тестировал webtunnel а переключился на obfs4)
это если дефолтные конфиги/пути в windows
del /q %USERPROFILE%\AppData\Local\torproject\Arti\cache\dir_blobs\*
del /q %USERPROFILE%\AppData\Local\torproject\Arti\cache\*
del /q %USERPROFILE%\AppData\Local\torproject\Arti\data\state\*
причем иногда даже с теми же мостами/конфигом может перестатать работать как минимум без очистки \state\ а то и весь \cache\ надо удалять.
в ТОРе это или в torrc или не знаю гдето дефолтные
DataDirectory c:\tor\var
теже самые state и cached-blablabla
причем не знаю как в ТОРе. в АРТИ это уже наверно год висит в багах (вроде как решенных? но это неточно.)
но они все пилят onion-relay onion-server RPC etc
хотя я и от ТОРа и тем более транспортов офигеваю не меньше последнее время как стал этим интересоваться
"встроили" webtunnel в lyrebird.
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/40017
Lyrebird cannot connect to the webtunnel server via IPv6
разрабы заметили/ответили про lyrebird
https://ntc.party/t/gitlab-lyrebird-buildrun-error/8010/7
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/40018
https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/63#note_3044771
хм. snowflake тоже может стать частью lyrebird
и я так понимаю TOR browser 14.0 и транспорты совсем откажутся от Win7
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-...015#note_3036660

По поводу go get я помню, что старые версии go скачивали последние гитовские версии библиотек (что не всегда хорошо), а новый go скачивает те, что указаны в конфиге. Различия могут быть в версиях.
Впихивают всё в lyrebird (бывший obfs4proxy). Раньше они также впихнули meek client. Но при этом сам meek клиент развивается (просто бинарники не поставляются), репозиторий активен. Видимо его наработки в lyrebird добавляют. Так что, если хочется быть сторонником классики (и плыть против течения), можно самому собирать standalone. Впрочем, может быть я не прав и разработка транспортов теперь ведётся в репозитории lyrebird. Но по крайней мере meek standalone вроде развивается.
Это ведь go, там импортнуть другой проект легко.
В obfs4proxy в своё время добавили obfs3 (который изначально был на питоне 2, вроде), fte (тоже питоновский), возможно переписали на go. Есть такая тенденция всё туда добавлять. Я сталкивался с подобным в сишном торе, только:
- не obfs4, а насканенные брижды или как их там называют, утилитой от ntc
- затыки начинали проявляться при браузерном запросе после неактивности (tor как служба). На что мне ответили, что использование таких мостов это хак, вот и проблемы.

Использование relay в качестве bridge - это хак, ладно.
Но obfs4 - изначально мосты, они только для этого предназначены и никакой другой функции не выполняют.
Так что всё-таки больше похоже на баг.

Мне почему-то кажется, что по идеологии разработчиков, пользователь должен использовать только 2-3 моста (живых). Столько ведь выдаёт сайт.

А эти затыки у меня случались и в комбинации 1/2 живых + 1 дохлый.
Про транспорты: в последнем expert bundle вообще нет webtunnel-client.
Теперь только lyrebird, значит.

ну запихивание там через оппу
вон как поломали lyrebird что он не запускается "на старых" TOR/ARTI при этом какого то фига это MAIN branch
и даже в одной из ссылок упоминается что тот же lyrebird и snowflake это про другое. и как оно вместе будет работать никто не знает
я боюсь представить конфиг например одновременно obfs4/snowflake/webtunnel с разными клиентами для каждого. а уж через один транспорт ;-P
про "неправильные" мосты (любые)
там какой то косяк с ХХ+ лет кодом похоже ибо я эти ошибки/баги про зависшие мосты и просто Guard-ы находил совсем древние
причем нет некакого механизма ни переключения через ХХ минут. ни тем более "простого" удаления неправильных state+cache
я вон в этой же ветке писал 100500 раз что АРТИ может 15+ минут долбится в неработающие 2а моста.
но "разрабам" важней RPС / onion-relay / etc ;-E
даже "корявые" PD/COW сохраняют в JSON удачные/неудачные попытки соединения и на следующий раз уже используют эти данные
ТОР же и тем более АРТИ без удаления руками "ненужного" так и не заработают
первый раз вижу такой подробный вывод в ТОР
даже в АРТИ не так информативно (ну может в debug/trace но там нечитаемый поток сознания.)
Jul 03 00:57:06.000 [notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 2218/6855, and can only build 10% of likely paths. (We have 100% of guards bw, 35% of midpoint bw, and 28% of exit bw = 10% of path bw.)
2024-07-03 нашел проверялку Country/IP/etc EXIT для ТОР (ну и не только.)
gron для удобства чтения JSON
curl -x socks5://127.0.0.1:9595 -4 http://ip-api.com/json/ | gron -m
json.country = "The Netherlands";
json.countryCode = "NL";
json.org = "TOR EXIT nodes";
json.query = "103.251.167.20";
оно же умеет и произвольные IP проверять по GeoIP
curl http://ip-api.com/json/192.42.116.208 | gron -m
json.as = "AS1101 SURF B.V.";
json.country = "The Netherlands";
json.countryCode = "NL";

2024-07-06 что то M$ antivirus и гугл стали определять
то ТОР давно
то мою сборку АРТИ не так давно
то вот недавно opera-proxy как трояны.
причем опера-прокси убило процесс и удалило файл во время работы после обновления базы видимо
кстати кто то пробовал АРТИ(windows) через nssm.exe сделать "сервисом" ?!
я все таки правильно понимаю что и тор/транспорты не будут собирать под все что не windows10/11 ?

LeonMskRu
Они перейдут на go 1.22, который несовместим с win7. Последний совместимый вроде как go 1.21. Это не значит, что go 1.21 запускается на win7. Но код, созданный go 1.21 (при кросскомпиле в линуксе или в win10+), должен работать на win7. Судя по opera-proxy.
Даже если некоторые ретрограды сборщики захотят остаться на go 1.21, наверняка со временем появятся новые фичи, которые затребуют новую версию go.

а с RUST как ? я вот нашел то есть оно уже сейчас не совместимо не то что с Win7 а даже Win8/8.1 ?
вроде как есть
targets {x86_64,i686}-win7-windows-msvc
но это надо самому из исходников компилить таргеты ?!
C:\GitHub>rustup target list | findstr /i "win"
i586-pc-windows-msvc
i686-pc-windows-gnu (installed)
i686-pc-windows-gnullvm
i686-pc-windows-msvc (installed)
x86_64-pc-windows-gnu (installed)
x86_64-pc-windows-gnullvm
x86_64-pc-windows-msvc (installed)

i686 уже несовместим с win7, судя по комментам здесь. С win8.0 совместимо было недавно, я проверял.
С i586 arti не соберётся, т.к. i586 предполагает отсутствие SSE2, а его хочет компонент ring. Это я тоже проверял, правда в линуксе.
Если i686-win7-windows-msvc не добавится командой rustup target add, то компилять. Не знаю насколько это сложно и долго, я ни разу не пробовал.

ну я нашел несколько инструкций вроде
https://seri.tools/blog/compiling-rust-for-legacy-windows/#rust
у меня умерло на этапе
python x.py build -i --stage 1 src/libstd
при
build i686-pc-windows-msvc
target i686-win7-windows-msvc
я уж даже не стал гуглить ибо не настолько фанат и не фига не разбираюсь в программировании чтобы все эти костыли поддерживать. к сожалению.
может кто и найдется разбирающийся кому надо

Люди даже для XP Rust заводили (сборки Firefox), да и Go (dnscrypt), но это хакерство и костылестроение.
К сожалению, win7 юзеры порой ограничены посильнее линуксоидов.
Но и перейдя они на линукс, тоже не все проги найдут. Тут кому что важнее.
Но я согласен, если кому-то нужна поддержка, пусть прикладывают усилия.
Правда, пока им проще забросить арти.

чтото я нифига не понимаю в GO
получаются два одинаковых .exe (папки у них разные:)
при том что локально у меня собирается нифига не MAIN branch
env GOOS=windows GOARCH=amd64 CGO_ENABLED=0 go build -ldflags="-s -w -X main.lyrebirdVersion=lyrebird-0.2.0" -p 1 -a -o lyrebird-64.exe -trimpath gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/cmd/lyrebird
C:\GitHub\lyrebird>git branch
* (HEAD detached at lyrebird-0.2.0)
fix_dependency_redirect
main
env GOOS=windows GOARCH=amd64 CGO_ENABLED=0 go build -p 1 -a -ldflags="-s -w -X main.lyrebirdVersion=lyrebird-0.2.0" -o lyrebird-64.exe -trimpath
p.s. да я сам скоро окажусь в подобной ситуации
ubuntu 22.04 lts на 5.15.0 работает на старом нотебуке.
новые ядра (даже 5.19 и 6.2) уже не видят ни встроенную сеть ни звук встроенный в чипсет
сеть еще обошел через dkms r8168 а вот звук никак похоже (все простые варианты что нашел не помогают. собирать kernel с патчами ну точно не мой уровень.) и хотя вроде обещают но даже видео нвидии могут в один момент остаться без драйверов да и я не в курсе как там работает поддежка древнего железа в dkms
и даже эта win10 где работаю и собираю АРТИ не совместима с официальным windows11 (часть проверок вроде можно отключить. но будут ли работать обновления и не превратится ли он с каким нибудь патчем в кирпич == под вопросом.)
Intel Core i5 3550 @ 3.30GHz (вроде нужны i5-8200 или выше)
MSI Z77MA-G45 (MS-7759) Socket LGA1155
просто тоже уже сроки подходят думаю RUST/GO тоже не будут десятки лет поддерживать и 10ку
2024-07-08 вобщем фиг знает что там go build собирает и откуда.
через go install понятней
в винде оно в c:\users\[имяпользователя]\go\bin по умолчанию собирается
вариант 1. не работает на АРТИ и как то криво с варнингами и кучей ошибок запускается на ТОР
C:\Users\le0n\go\bin>go install gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/cmd/lyrebird@main
go: downloading gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird v0.0.0-20240620180443-f56896ffb54a
go: downloading github.com/refraction-networking/utls v1.6.3
go: downloading github.com/quic-go/quic-go v0.40.1
вариант 2. работает как и раньше без особых проблем на АРТИ и на ТОР
C:\Users\le0n\go\bin>go install gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/cmd/lyrebird@lyrebird-0.2.0
go: downloading gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird v0.0.0-20240327102443-aab489105e97

Есть такое дело. Релизный lyrebird 0.2.0 работает.
В сборках Tor Expert Bundle (stable и alpha) такой проблемы нет. Там или lyrebird 0.2.0 или как-то пофиксили. Не знал, что есть такая деградация в ядрах. А я в Арче подглядел опции: Но торовцы их не используют. С ними бинарник чуть больше и в readelf -d видны доп. флаги.
ChatGPT мне про них рассказал:
Эти опции сборки Go добавляют специфические флаги, которые влияют на процесс компиляции и конечный результат (бинарный файл). Давайте разберем каждую из этих опций и их влияние:
1. -buildmode=pie:

1. Опция pie (Position Independent Executable) делает так, чтобы скомпилированный бинарный файл мог быть размещен в любом месте в памяти. Это повышает безопасность за счет использования механизма ASLR (Address Space Layout Randomization).
   
2. Увеличение размера бинарного файла связано с дополнительными данными и кодом, необходимыми для поддержки этой функциональности.

2. -trimpath:

1. Опция -trimpath удаляет информацию о пути к исходным файлам из бинарного файла. Это полезно для создания повторяемых сборок, поскольку пути к исходникам не будут варьироваться в зависимости от среды компиляции.
   
2. Эта опция обычно не влияет на размер бинарного файла, но улучшает конфиденциальность и повторяемость.

3. -ldflags=-linkmode=external:

1. Опция -linkmode=external заставляет компоновщик использовать внешние инструменты для компоновки (например, компоновщик ОС) вместо встроенного компоновщика Go. Это может быть полезно для специфических целей, например, при создании некоторых типов исполняемых файлов.
   
2. Использование внешнего компоновщика может увеличить размер бинарного файла за счет дополнительных данных, необходимых для внешней компоновки.

4. -mod=readonly:

1. Опция -mod=readonly заставляет компилятор использовать режим только для чтения для модуля, не позволяя ему вносить изменения в файлы go.mod и go.sum. Это полезно для обеспечения консистентности зависимостей.
   
2. Эта опция не влияет на размер бинарного файла.

5. -modcacherw:

1. Опция -modcacherw делает кэш модулей записи и чтения. По умолчанию кэш модулей является только для чтения, что может предотвращать случайные изменения. Эта опция может быть полезна при настройке среды разработки.
   
2. Эта опция также не влияет на размер бинарного файла.

Насколько они хороши?
Эти опции полезны для повышения безопасности (-buildmode=pie), обеспечения консистентности сборок (-trimpath, -mod=readonly), и настройки специфичного поведения компоновки (-ldflags=-linkmode=external). Тем не менее, каждая из них может немного увеличить размер бинарного файла, особенно -buildmode=pie и -ldflags=-linkmode=external.
Если безопасность и повторяемость сборок для вас важнее, чем минимальный размер бинарного файла, то эти опции являются хорошим выбором. В противном случае, если размер бинарного файла критичен, можно рассмотреть возможность отключения некоторых из них, например, -buildmode=pie и -ldflags=-linkmode=external.
Кстати, trimpath не помешал бы Arti. Он при (нефатальном) крэше пишет путь сборки.
Upd: У меня пока что проблем с этим нет, но и мосты ещё живые (потому что я за VPN).
Если надо удалить, я пишу в терминале из домашней папки: Вернулся с obfs4 на webtunnel и столкнулся с проблемами. Чистка кэша помогла.

trimpath в RUST/cargo есть. но только в +nightly
https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#profile-trim-paths-option
про webtunnel
у меня из 33и найденых на https://github.com/scriptzteam/Tor-Bridges-Collector/blob/main/bridges-webtunnel
рабочие только 17 штук
я просто не копался. их забанили или они сами время от времени "дохнут" ...
удаление cache\state
ну у меня удаляются и дефолтные пути windows и мои из конфига (показалось так проще и удобней.)
к тому же я последнее время добавляю батники эти в сборки.
но это под виндой где пофиг на права директорий и файлов. в линуксе надо будет проверять что всё по феншую
[storage]
# создается в /state
state_dir = "./"
cache_dir = "./cache"
про кернелы 5.19 6.2 ну они вроде как переходные ?
end of life 2022 2023
может не заморачивались. или железо слишком древнее
чипсет Intel HM67.
даже видео Nvidia GeForce GT 555M в kernel 6.8 послали на ... под 5.19 и 6.2 еще есть драйвер+dkms дальше нотебук на свалку
2024-07-11 свежий snowflake тоже перестал работать на АРТИ
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/...8a186c0059fef496
2024-07-11T18:40:10Z INFO tor_ptmgr::ipc::sealed: Launching pluggable transport at snowflake-client-64.exe for [PtTransportName("snowflake")]
2024-07-11T18:40:10Z WARN tor_ptmgr: Spawning PT for [PtTransportName("snowflake")] failed: Couldn't parse IPC line "STATUS TYPE=version IMPLEMENTATION="snowflake" VERSION="2.9.2 (9e977fe6*)"": no TRANSPORT in STATUS
2024-07-11T18:40:10Z WARN tor_ptmgr: PT for snowflake failed to launch: Couldn't parse IPC line "STATUS TYPE=version IMPLEMENTATION="snowflake" VERSION="2.9.2 (9e977fe6*)"": no TRANSPORT in STATUS
"чинится" как и с lyrebird
git checkout --detach tags/v2.9.2
git switch --detach tags/v2.9.2 --recurse-submodules
C:\GitHub\snowflake>git branch
* (HEAD detached at v2.9.2)
p.s. https://gitlab.torproject.org/tpo/core/arti/-/issues/1488
(здесь могла быть картинка :ЖДУН:)
2024-07-12 похоже выкину webtunnel из сборки. ибо там даже откатывать нечего чтобы вернуть "работу" в АРТИ
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/...d513a21ec74fe8c6
p.s. lyrebird 0.2.0 вроде как работает вместо webtunnel
2024-07-12T16:32:11Z INFO tor_ptmgr::ipc::sealed: Launching pluggable transport at lyrebird-64.exe for [PtTransportName("webtunnel")]
но что то слишком много ошибок == не может скачать консенсус
https://www.flickr.com/photos/200778714@N04/53852369853/sizes/o/

попытался собрать 1.2.6
независимо от конфига (без мостов, мосты, мосты+транспорты)
как и от флагов при сборке
крашится как arti.exe так и connection-checker/arti-testing
thread 'tokio-runtime-worker' panicked at C:\GitHub\arti\crates\tor-proto\src\circuit\streammap.rs:379:17: Missing open stream
2024-08-02T20:24:11Z ERROR arti::logging: Panic at C:\GitHub\arti\crates\tor-proto\src\circuit\streammap.rs:379:17: Missing open stream
даже просто
env RUSTFLAGS=-Awarnings cargo build --jobs 1 --features full,static --release
не компилится
error[E0433]: failed to resolve: could not find `iterator` in `signal_hook`
--> C:\Users\le0n\.cargo\registry\src\index.crates.io-6f17d22bba15001f\signal-hook-async-std-0.2.2\src\lib.rs:62:18
error: could not compile `signal-hook-async-std` (lib) due to 4 previous errors

Умеет ли arti в вышестоящий (upstream/parent) proxy или только через proxychains натравливать его?
Раньше было модно заблокированный tor пускать через shadowsocks. Сейчас столкнулся с тем, что shadowsocks блокируют, если там внутри бегает tls (определяют по размеру пакетов), при этом http сайты через него грузятся.
Сишный tor через такой кастрированный shadowsocks скрипя, но соединяется (а после установки соединения уже не тормозит).
В arti же постоянно ошибки EOF. Подробнее.
psiphon over ss тоже работает, но не очень быстро. Хотя, RST пакеты в Wireshark исчезают.
Почему у нас блокируют youtube, tor, shadowsocks, а народ на кухне компилирует и обсуждает куда лучше перейти? Те же французы бы давно вышли.

А разве черех V2RayNG нельзя пустить Socks 127.0.0.1 9050? Я видел в настройках плиложения добавления собственных http. socks и всё это маскировкой в X-Ray или другой протокол на выбор.