Con sudo --version viene spiegata la configurazione effettiva di sudo, inclusi gli IP della macchina per qualche ragione

anxiety, socialization

'impostor syndrome vs reality:
what i know, what i think others know, what others actually know'

Dovrò cambiare launcher, yay

Mamba — Conda riscritto in C++
https://github.com/mamba-org/mamba

Micromamba — versione single-executable, statically-linked, cross-platform
https://anaconda.org/conda-forge/micromamba

C'è nei repo archlinuxcn

Summary

anaconda = ambiente gigante di ricerca per python

miniconda = ambiente minimo per venv python

conda = package manager extra-python, gestisce anche librerie native ed altri software

mamba = conda in C++, cross-platform

micromamba = mamba statically linked, cross-platform

Bending Spoons ha comprato Vimeo per 1,38 miliardi di dollari!

https://investors.vimeo.com/news-releases/news-release-details/vimeo-enters-definitive-agreement-be-acquired-bending-spoons-138

Oggi a lavoro un'odissea con Android, VPN, profilo lavoro, HTTPS, certificati self-signed ed analisi di rete.

Abbiamo questi clienti il cui software è raggiungibile solo attraverso una VPN via HTTPS ad un certo ip. Hanno dei domini aziendali associati all'ip con un certificato firmato da una loro authority interna, peccato che da VPN i loro DNS non siano raggiungibili quindi non lo è neanche la loro authority.

Per aggirare il problema ho inserito a mano i loro domini in C:\Windows\System32\drivers\etc\hosts .

In pratica hanno questo problema: con la nostra app mobile (iOS e Android) ad ogni login ricevono un errore strano, poi però premendo Riprova tutto funziona correttamente. L'app è scritta in Flutter ed abbiamo anche una versione web ad uso interno, peccato che questo bug lì non sia replicabile.

Usiamo la stessa app anche internamente, quindi per evitare di sloggarmi ne ho installato una copia nel profilo di lavoro.

Come allineare gli astri ed analizzare le richieste di rete?

Avevo già installato la VPN su windows e sapendo che su altri OS dà problemi (LAN e internet non raggiungibili) ho preferito evitare di installarla sul mio telefono.

Esiste questo tool fighissimo mitmproxy cross-platform che consente di fare da man-in-the-middle HTTPS tramite proxy, Wireguard, socks5 ecc, facendo però installare sul dispositivo dei suoi certificati anch'essi self-signed. Ha anche un'interfaccia web mitmweb molto comoda.

Installo quindi il tool sul mio pc windows e installo un client wireguard sul mio telefono (profilo standard) — quindi:
• server clienti — vpn — windows — etc\hosts
— mitmproxy — wireguard server — lan — android
— profilo standard: wireguard client
— profilo lavoro: app

Apriti cielo...

Innanzitutto viene fuori che android isola le reti dei profili, quindi bisogna installare ed attivare la vpn nello stesso profilo delle app da connettere. Reinstallo e riconfiguro wireguard...

Mitmproxy segnalava che il client (l'app android) rifiutava la connessione TLS nonostante io abbia aggiunto il certificato nel sistema.

Viene fuori quindi che da android 7 ogni app deve chiedere esplicitamente nel manifest se usare i certificati utente, quindi chiedo al mio collega di compilarmi una build con quella modifica.

Disinstallo e reinstallo l'app nel profilo di lavoro e...

INSTALL_FAILED_UPDATE_INCOMPATIBLE: Package signatures do not match the previously installed version

Ma come? L'avevo tolta nel profilo di lavoro.
Viene fuori che android NON ISOLA le app installate di utenti diversi:
se un utente (nel mio caso il profilo standard) ha già installato un'app con lo stesso package, non puoi installare lo stesso package con firma diversa su altri utenti (il profilo di lavoro). (In contrasto con l'isolamento di rete di prima)

Rifiutandomi di disinstallare l'app originale dal profilo standard, il mio collega prova direttamente con il suo emulatore android mentre io provo con waydroid installato su WSL — in entrambi i casi nulla da fare.

Fast forward, Flutter non rispetta mai in ogni caso i certificati utente. Su questo esiste una issue chiusa per inattività. L'unica soluzione sana per considerarli sarebbe iterarli a mano con un plugin e creare un SecurityContext aggiungendone 1 (esatto solo 1).

Fortunatamente l'app funziona anche con connessioni HTTP, quindi su WSL ho installato caddy configurandolo come reverse-proxy al dominio dei clienti, e fortunatamente esiste l'opzione tls_insecure_skip_verify che ignora i certificati self-signed.

Controllo che il firewall di windows sia aperto verso WSL e... FUNZIONA. L'app originale android riesce a connettersi via HTTP al reverse-proxy.

Rimane un problema... come analizzare il flusso di rete però?

Avrei potuto utilizzare nuovamente mitmproxy oppure wireshark, ma abbiamo optato per l'emulatore android sul mac del collega. Sarebbe stato più semplice se l'emulatore non avesse un bridge che nasconde gli indirizzi 192.168x

Dopo altro wrestling con adb forward / reverse (tra l'altro, solito tool che non si capisce mai dove sia installato), mi sono ricordato dell'esistenza di socat, uno swiss army knife che consente di connettere insieme qualsiasi tipo di socket in modo bidirezionale: TCP UDP IPV4 IPV6 FILE PIPE SOCK unix ...

Creando un secondo relay localhost sul mac del collega, l'emulatore è riuscito a connettersi tramite 10.0.2.2

socat \
tcp4-listen:5678,fork,reuseaddr \
tcp4:192.168.1.x:80

Riuscendo finalmente ad analizzare le richieste di rete, scopriamo che nel primo tentativo di login una delle chiamate API contiene nel body di risposta un json, corretto al 99.9% ...se non per una graffa di chiusura mancante

{
  "status": "ok",
  "results": { ...
  }

Ma questa graffa, nella stessa chiamata del secondo tentativo, È PRESENTE.

To be continued.

La risoluzione è stata decisamente meno entusiasmante.

Mi sono accorto che nel body oltre alla graffa finale mancante sono anche presenti spazio+newline iniziali extra, ma il Content-Length è identico

 
{
  "status": "ok",
  "results": { ...
  }

Il codice PHP dell'API ha una cache di sessione che se disattivata fa comparire il problema ad ogni chiamata, questo spiega il successo delle successive chiamate.

Qualcosa durante il calcolo della risposta genera quegli spazi, inoltre il Content-Length è sicuramente forzato lato PHP prendendo la lunghezza della risposta reale — niente programmi di rete che inseriscono header vuoti, il rasoio di Occam va sempre considerato.

Facendo un po' di bisect con ob_start() + ob_get_clean() trovo il colpevole: uno spazio residuo dopo un tag di chiusura ?> di una personalizzazione del 2016...

Poi confermato con questo grep
grep -Pzrl '^\s+<\?php|\?>([ \t]+[\r\n]*|[\r\n]*[ \t]+)$' .

Più di 12h buttate per uno spazio

Il re del circo ha parlato

Ho aperto per caso un server Discord ed ho trovato due cose pazzesche: