W

raz z wersją git 2.34.0 każdy nasz commit do kodu lub jego tag będzie mógł zostać podpisany kluczem SSH. Możliwość podpisywania dowolnych danych za pomocą SSH została dodana już w 2019 roku z wydaniem OpenSSH 8.0. Jednak, aby używać tej funkcjonalności bez żadnego problemu najlepiej używać OpenSSH w wersji 8.8. Nasz proces zaczynamy od instalacji i konfiguracji klienta git i SSH:

sudo apt install -y git

Kolejnym krokiem jest wygenerowanie klucza SSH, który będzie używany do podpisywania:

ssh-keygen -t ed25519 -C "agresor@nfsek.pl" -f ~/.ssh/code_commit_signing

Odpowiadamy na pytania i upewniamy się, że wpisaliśmy silne i unikalne hasło do klucza. Klucz ten będzie domyślnie przechowywany w naszym katalogu domowym pod katalogiem .ssh:

agresor@darkstar:~$ cat .ssh/code_commit_signing.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMzu8wjcnyAorVVtEjddoG2gaYjmRnHiZHvElYFcl/s/ 
agresor@nfsek.pl

[ czytaj całość… ]

P

ierwszy raz z truflową świnką ryjącą za poszukiwaniem kluczy mogliśmy spotkać się w Oh Shit, Git?!. Najnowsza, trzecia wersja została zupełnie przepisana w języku Go. Dodano do niej obsługę ponad 600 typów kluczy zwiększając tym samym zdolność tego narzędzia do polowania na wycieki danych uwierzytelniających. W dodatku detektory te obsługują aktywną weryfikację z odpowiednimi interfejsami API. Ujawnione dane uwierzytelniające, w tym pary tajnych kluczy, stanowią poważny problem cyberbezpieczeństwa. Klucze mogą być nadużywane do włamywania się do sieci korporacyjnych, często bardziej potajemnie i przez dłuższy czas niż wykorzystywanie luk w popularnym oprogramowaniu.
[ czytaj całość… ]

K

iedy wykonujemy program Python to w tle wykonuje się najpierw kompilacja kodu źródłowego (instrukcje znajdujące się w danym pliku .py) do formatu zwanego jako kod bajtowy. Kompilacja to proces tłumaczenia kodu na inny format, a w tym wypadku kod bajtowy jest niskopoziomową, niezależną od platformy reprezentacją kodu źródłowego. Język programowania Python przekłada każdą z instrukcji źródłowych na grupę instrukcji kodu bajtowego poprzez podzielenie ich na pojedyncze kroki. Proces przekładania kodu źródłowego na kod bajtowy odbywa się z myślą o szybkości wykonania – kod bajtowy może działać o wiele szybciej od oryginalnych instrukcji z kodu źródłowego zawartego w pliku tekstowym.
[ czytaj całość… ]

I

nernet to wodospad cieknących danych. W mojej pierwszej serii Necronomicon ( część I oraz II) mogliśmy się o tym przekonać na przykładzie skracarek adresów URL. Dzisiaj zajmiemy się serwisami oferującymi miejsce na repozytoria kodu. Ale od początku. Jakieś dziesięć lat temu powstał ruch DevOps – przechodząc przez różne etapy rozwoju dołączono do niego kolejny człon – DevSecOps. Upraszczając: jest to ruch, który osadza w cykl życia oprogramowania procesy bezpieczeństwa. Jego braki lub luki proceduralne są częstym i w dużej mierze niedocenianym wektorem zagrożeń dla wielu firm i organizacji.
[ czytaj całość… ]

K

iedy korzystamy z polecenia git zazwyczaj dotyczy ono przepływu pracy typowego dla kontroli wersji. Mamy lokalne repozytorium na swoim komputerze, na którym pracujemy i zdalne, gdzie trzymamy wszystko w synchronizowanym stanie i możemy pracować z innymi członkami zespołu lub z innych maszyn. Jednak narzędzia git można też użyć do wdrożenia aplikacji / konfiguracji na dowolne środowisko – testowe / produkcyjne. Wyobraźmy sobie następujący przykład:
[ czytaj całość… ]

T

aki tytuł swojej prezentacji na DEFCON 19 przyjął Adam Baldwin. Opierała się ona na błędzie w postaci braku blokady dostępu do plików zawierających metadane systemów DVCS (ang. Distributed Version Control Systems), czyli po prostu plików pochodzących z rozproszonych systemów kontroli wersji takich jak: .git, .bzr (bazaar), .hg (mercurial), czy .svn (subversion). Błąd ten wynika najczęściej z faktu, że programiści używają tego rodzaju rozwiązań do wdrażania aplikacji na serwery środowisk produkcyjnych, które także pełnią rolę publicznych serwerów WWW.
[ czytaj całość… ]