Miesiąc: sierpień 2022

Opublikowane w

Terminal HP T630

Jakiś czas temu pisałem o zakupionym HP T620. Sprawdził się jako sprzęt. Brak wentylatora, możliwości rozbudowy RAM i SSD, dużo wyjść. Działał dobrze i w sumie nie było powodu do wymiany, ale… Kumpel z pracy też kupił T620. Tyle, że w wersji z czterema rdzeniami. I jak mi dwa rdzenie wystarczały, tak widać po obciążeniu było, że do odtwarzania multimediów na styk są. I pewne operacje, nazwijmy to przygotowawcze do odtwarzania, mogłyby wykonywać się szybciej. No i kupiłem wersję z SSD o rozmiarze 8 GB, co dla Debiana z GUI pod rozrywkę i multimedia też na styk było[1]. Więc niby mógłby robić za podstawowy desktop, ale jednak nie do końca.

Terminal HP T630
Źródło: strona producenta

Pojawił się więc pomysł wymiany na wersję z czterema rdzeniami. Tym bardziej, że nie boję się kupna wersji używanej, a systemu nie potrzebuję – Debian działa dobrze. Trochę jest to próba racjonalizacji nowego gadżetu, nie ukrywam. Normalnie szukałbym nowej płytki z SoC ARM, ale ceny są tu tak nieprzyzwoicie wysokie, że odpuściłem. Jak już szukałem, to postanowiłem sprawdzić, czy są jakieś alternatywy.

Okazało się, że istnieją terminale HP T630, bardzo podobne do T620. Główna różnica to taktowanie CPU. 2 GHz, zamiast 1.5 GHz w wersji czterordzeniowej. I dwa razy większy maksymalny rozmiar pamięci RAM. Kupiłem więc T630 w wersji z dyskiem 32 GB i 8 GB RAM. Dla pamięci: w sierpniu 2022 zapłaciłem 220 zł. T620 miał 8 GB dysk, 4 GB RAM i kosztował w listopadzie 2020 120 zł.

Instalacja Debiana bezproblemowa. Działanie po uruchomieniu także. Poza jedną, istotną, wynikającą z hardware różnicą. Otóż T620 posiadał dwa osobne gniazda: line-in oraz line-out, a dodatkowo gniazdo słuchawkowe. W HP T630 jest nadal gniazdo słuchawkowe na froncie, ale gniazdo oznaczone line-in oraz line-out jest tylko jedno. Było z tym niewielkie zamieszanie, ale o tym w kolejnym wpisie.

Jest zauważalnie szybciej. Czy spróbuję, choćby testowo, korzystać z HP T630 jako podstawowego desktopa? Zobaczymy. Szansa na pewno jest.

[1] Tak, można wymienić SSD. Albo wręcz dołożyć pendrive’a albo czytnik kart microSD na USB do któregoś z licznych wolnych portów USB. W tym USB 3.0.

Opublikowane w

VSCodium na Debianie

Jak pisałem wcześniej, nadchodzi koniec edytora Atom. Z pewnych względów, na maszynie służbowej i tak zacząłem korzystać z Visual Studio Code . Dlatego postanowiłem przyspieszyć proces migracji także na prywatnej maszynie. VSC nie było złe, więc zgodnie z zapowiedzią dałem szansę VSCodium.

Czym jest VSCodium?

VSCodium to fork microsoftowego Visual Studio Code, zbudowany z otwartego kodu źródłowego, dostępny na wolnej licencji. Dodatkowo pozbawiony dodatków od Microsoft służących do zbierania telemetrii/śledzenia. Poza tym, wszystko powinno działać tak samo.

VSCodium logo
Źródło: https://vscodium.com/

Instalacja VSCodium

Na początek instalacja pod Debianem. Z tego co widzę, na Ubuntu będzie identycznie. Szczęśliwie dostępne jest repozytorium pakietów deb. Skorzystałem z opisu instalacji spod tego linka: https://www.linuxcapable.com/how-to-install-vscodium-on-debian-11-bullseye/. Wersja skrócona poniżej.

Dodajemy klucz GPG do zaufanych:

curl https://gitlab.com/paulcarroty/vscodium-deb-rpm-repo/raw/master/pub.gpg | gpg --dearmor > /etc/apt/trusted.gpg.d/vscodium.gpg

Dodajemy źródło pakietów:

echo "deb https://download.vscodium.com/debs vscodium main" > /etc/apt/sources.list.d/vscodium.list

Po tym zostaje już tylko aktualizacja danych o repozytoriach i instalacja pakietu codium:

apt update; apt install codium

Wtyczki z marketplace

Nieprzypadkowo napisałem, że wszystko powinno działać tak samo. Słowo powinno powinno dać do myślenia. Otóż po instalacji pozwoliłem sobie „ściągnąć” konfigurację, a w zasadzie używane wtyczki, z marketplace od kolegi z pracy, korzystającego z VSC. Mocno się zdziwiłem, bo większość potrzebnych wtyczek, tych od Microsoft, nie była w VSCodium dostępna do instalacji. Nie drążyłem wtedy tematu i po prostu zainstalowałem VSC.

Jednak po szybkim zbadaniu tematu okazuje się, że nie ma najmniejszego problemu z korzystaniem z marketplace Microsoft w VSCodium. Zgodnie z tym, co piszą w dokumentacji, wystarczy w pliku

~/.config/VSCodium/product.json

dodać stosowną zawartość, czyli:

{
  "extensionsGallery": {
    "serviceUrl": "https://marketplace.visualstudio.com/_apis/public/gallery",
    "cacheUrl": "https://vscode.blob.core.windows.net/gallery/index",
    "itemUrl": "https://marketplace.visualstudio.com/items",
    "controlUrl": "",
    "recommendationsUrl": ""
  }
}

I możemy cieszyć się dostępem do wtyczek zupełnie jak w Visual Studio Code.

Wtyczki

Nie ukrywam, że bardziej podobało mi się działanie wtyczek w Atomie. Na przykład isort wywołany tamże po prostu sortował wszystkie importy. W przypadku VSC nie ma tak dobrze. Z tego co udało mi się znaleźć, można „naprawić” pojedynczy import.

Istnieje obejście, które jest podpowiadane w opisie konfiguracji wtyczki, czyli dodanie do settings odpowiedniej sekcji. Jest to nieco nieintuicyjne, bo w czytamy to będąc w… ustawieniach, czyli settings. Chodzi jednak o inne settings. Jak znalazłem pod tym linkiem, trzeba zmienić zawartość pliku

~/.config/Code/User/settings.json

Na razie tyle. Z doświadczeń w pracy wynika, że spokojnie da się żyć z VSC zamiast Atoma. Na razie pracuje mi się w VSC gorzej, ale raczej chodzi o drobną zmianę przyzwyczajeń i dokładniejsze poznanie nowego programu. Z wyboru zamiennika jestem wstępnie zadowolony.

Opublikowane w

Publiczne Wi-Fi a bezpieczeństwo

Wczoraj ukazał się artykuł o tym, czy korzystanie z publicznego Wi-Fi jest bezpieczne. Uważam, że prezentowane tam podejście jest dość optymistyczne. Nie uważam obcych sieci za tak bezpiecznie, jak pisze autor. Wszystko zależy od tego, czego się obawiamy. I naszego poziomu paranoi.

Na pewno podłączanie do sieci Wi-Fi, jeśli zakładamy złe zamiary jej właściciela lub innych użytkowników jest bezpieczniejsze, niż podłączanie kablem ethernetowym. Ot, nikt nie poda wysokiego napięcia na kablu i nie spali nam urządzenia. No ale żarty na bok.

Publiczne Wi-Fi – zagrożenia

Podłączając się do cudzej lub publicznej sieci ujawniamy informacje o swoim urządzeniu i systemie. Np. syngatury urządzenia typu adres MAC czy hostname. W pewnych przypadkach dane te mogą zostać wykorzystane do… powiedzmy przypisania nam pewnych działań. Ale to bardziej naruszenie prywatności niż realny atak. Pójdźmy dalej.

Podłączając się do sieci eksponujemy nasze urządzenie na bezpośrednie połączenia. OK, jeśli ktoś ma firewall lub nie udostępnia żadnych usług innym komputerom w sieci lokalnej, to problemu nie ma. Ale już udostępnienie zasobu chronionego prostym hasłem z laptopa w sieci domowej, gdzie bezpośredni dostęp miały tylko nasze urządzenia może okazać się zgubne. W naszej sieci przed atakami z internetu mógł chronić router (NAT).

Nie taki HTTPS wspaniały

Wspomniany w artykule HSTS ma dwie wady. Po pierwsze, adopcja. Zwyczajnie nie wszystkie strony z niego korzystają. Żeby daleko nie szukać, tamten artykuł zamieszczony jest na stronie bez HSTS. I pewnie ktoś przytomnie zauważy, że przecież to tylko blog, a nie bank. To polecam samodzielne sprawdzenie, czy, ew. które polskie banki korzystają z HSTS na stronach. O HSTS z preload litościwie nie wspominam.

Po drugie, jest to mechanizm TOFU. Tzn. nie zapewnia bezpieczeństwa przy pierwszym połączeniu. Owszem, przeglądarka w kolejnych połączeniach do strony, przez zwykle długi okres ważności, będzie już korzystać z HTTPS. Ale jeśli jest to nowa strona lub otwierana w nowej przeglądarce to HSTS nic nie daje.

Dodatkowo autor wspomina o powszechnych przekierowaniach HTTP -> HTTPS. Tylko niestety taki mechanizm nie zapewnia bezpieczeństwa. OK, może je podnosić w szczególnym przypadku, jeśli jest stosowany łącznie z HSTS. Bez tego raczej zapewnia złudzenie bezpieczeństwa. Bowiem jeśli pierwszy request jest wykonywany po HTTP, to nadal DNS spoofing jest groźny. Atakujący może dowolnie rozwiązać nazwę domeny do której próbujemy się połączyć. Np. na swój serwer. I tam wykonać przekierowanie HTTP. Redirect (301) może być na cokolwiek. Także na domenę z poprawnym HTTPS. Tyle, że niekoniecznie tę, na którą chcieliśmy się połączyć. Tylko np. na domenę homograficzną, albo domenę o zbliżonej nazwie. Ot, choćby wchodząc na http://mojbank.pl możemy skończyć na https://mojbark.pl, o wyglądzie identycznym jak https://mojbank.pl. I z poprawnym certyfikatem HTTPS i „kłódeczką”.

No i ostatecznie nawet połączenie HTTPS z poprawnym hostem nie gwarantuje jeszcze, że jest w pełni bezpiecznie. W niektórych przypadkach, na które użytkownik nie ma wpływu, nadal możliwe mogą ataki na HTTPS. OK, w przeciwieństwie do DNS spoofingu są trudniejsze do wykonania.

Jak korzystać bezpieczniej z publicznych Wi-Fi?

Czy to znaczy, że zupełnie nie zgadzam się z autorem? Niekoniecznie. Zgadzam się, że jest o wiele bezpieczniej, niż kiedyś. Generalnie jeśli ktoś naprawdę musi skorzystać z Wi-Fi i miałbym dać tylko jedną radę to byłoby to: włącz DoH w przeglądarce i wpisuj adresy w pasku adresu przeglądarki „z palca”, korzystając z podpowiedzi. No wiem, to w zasadzie dwie rady. Ale przyjmijmy, że jedna, tylko złożona.

Czemu tak? DoH zapewni nam odporność na DNS spoofing, a dodatkowo da bonus w postaci podwyższenia prywatności. Potencjalny podsłuchujący nie dostanie adresów odwiedzanych stron „na tacy” w postaci nieszyfrowanych zapytań DNS. W części przypadków w ogóle nie będzie w stanie ustalić z jakim serwisem się łączymy.

Wpisywanie domen w pasku adresu, z wykorzystaniem podpowiedzi uchroni przed kliknięciem w podobną domenę i zwiększy szansę na wykorzystanie protokołu HTTPS już od pierwszego requestu.