awesome-tunneling - коллекция селфхостед туннелей на любой случай. Сгруппировано по областям применения и возможностям.

https://github.com/anderspitman/awesome-tunneling

#tunnel #security #network

Возможность доступа к коммитам по хэшу во всех связанных форками репозиториях вызвано тем, что GitHub в целях оптимизации и исключения дубликатов хранит вместе все объекты из основного репозитория и форков, лишь логически разделяя принадлежность коммитов. Подобное хранение позволяет просмотреть в основном репозитории любой коммит из любого форка, явно указав его хэш в URL. Например, пользователь может создать форк репозитория "/torvalds/linux" и добавить в него любой код, после чего этот код станет доступен по прямой хэш-ссылке в репозитории "/torvalds/linux". В случае удаления репозитория, если имеется хотя бы один публичных форк, данные из удалённого репозитория остаются доступны по хэшу коммита.

Предлагается три сценария, представляющих угрозу безопасности:

- Первый сценарий затрагивает ситуации, когда разработчики создают форки публичных репозиториев, добавляют в них изменения, экспериментируют, а затем удаляют. Помимо утечки кода, который не предназначен для публикации, опасность представляет ситуация, когда в экспериментах в код файлов с примерами добавляются рабочие ключи доступа к API. В этом случае атакующий может получить доступ к изменению по хэшу коммита, адресуемому после удаления форка через основной репозиторий. Например, предложенным способом исследователи смогли определить 30 рабочих ключей доступа к API, изучив три связанных с машинным обучением репозитория с большим числом форков.

- Второй сценарий касается возможности получения доступа к данным после удаления первичного репозитория, если для этого репозитория были созданы форки. В качестве примера приводится случай, когда в публичном репозитории одной компании были случайно опубликованы закрытые ключи одного из сотрудников, позволяющие получить полный доступ ко всем репозиториям данной компании на GitHub. Компания удалила репозиторий через который была утечка, но ключи по-прежнему остались доступны для извлечения через обращения по хэшу коммита в репозиториях с форками.

- Третий сценарий связан с моделью разработки проектов, которые развивают базовую открытую версию в публичном репозитории и расширенную проприетарную версию в приватном. Если компания изначально развивала проект в приватном репозитории, а затем после открытия кода проекта перевела его в разряд публичных, но продолжила разработку закрытой внутренней или расширенной версии в приватном форке, имеется возможность доступа к добавленным в приватный форк изменениям по хэшам коммитов через публичный репозиторий. При этом доступ возможен только к изменениям, добавленным в приватный форк до перевода основного репозитория в разряд публичных (хранилища приватных и публичных репозиториев разделяются, но, когда два репозитория были приватными, коммиты хранились совместно, поэтому остались в репозитории после его перевода в разряд публичных).
. . .
Подобрать хэш коммита, формируемый на базе алгоритма SHA-1 и включающий 32 символа, не реально, но оказалось, что это и не требуется. GitHub поддерживает сокращённую форму обращения к коммитам, позволяющую адресовать изменения по нескольким первым символам хэша, если отсутствуют пересечения с другими коммитами. Минимальное число символов для сокращённой адресации хэша - 4, что соответствует перебору всего 65 тысяч комбинаций (16^4). При этом перебор может и не потребоваться, так как API GitHub позволяет подключать обработчики для перехвата событий, которые используются сторонними проектами, ведущими архив с полным логом всех операций, в котором информация о хэшах коммитов остаётся и после удаления репозиториев.

Доступ к данным из удалённых и приватных репозиториев на GitHub, имеющих форки
https://www.opennet.me/opennews/art.shtml?num=61605
+
Оригинал
Anyone can Access Deleted and Private Repository Data on GitHub
https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github

Ещё одна проблема с которой сегодня столкнулся и для которой понадобился экстренный фикс - это если /var/lib/kubelet и /var/lib/containerd находятся на разных разделах, то в Kubernetes не работает нормально garbage collection.

Ситуация маслом на полотне:
/var/lib/containerd переполнен, а кубелет смотрит себе под ноги в /var/lib/kubelet и говорит что всё нормально: "ещё целых 95% свободного места".
При этом поды запуститься не могут из-за того что не могут спулить новый image. Пришлось повозитсья с bind mounts чтобы вынести их на общий раздел.

https://sklar.rocks/how-container-storage-interface-works/
#k8s #kubernetes #csi

https://github.com/mateussouzaweb/kvm-qemu-virtualization-guide
#github #kvm #qemu

https://blog.benjojo.co.uk/post/ssh-randomart-how-does-it-work-art
#ssh #art

Казалось бы, избитая тема, как работают DNS-резолверы, но добавь туда Dual-Stack, закопайся в глубь кода Linux – и вот готово многостраничное чтиво о том, что, как все думали, работает очень просто.
Но эта история не про усложнить, а объяснить, как есть на низком уровне.

https://biriukov.dev/docs/resolver-dual-stack-application/0-sre-should-know-about-gnu-linux-resolvers-and-dual-stack-applications/

https://arthurchiao.art/blog/cilium-life-of-a-packet-pod-to-service/
#cilium #ebpf

Testing Helm Charts Part I
https://grem1.in/post/helm-testing-pt1/

Testing Helm Charts Part II
https://grem1.in/post/helm-testing-pt2/

В этот раз статья также будет разбита на две подчасти и обе подчасти будут представлять собой, в основном, сугубо теоретиескую составляющую. А речь пойдет о пространствах имен в Linux. Ранее данная тема уже затрагивалась, когда мы говорили о безопасности в Docker, но здесь подробностей чуть больше выйдет. Через пару дней опубликую вторую подчасть.

Вообще перевод из блога Quarkslab's давно уже в сети, поскольку оригинальная статья была опбуликована ещё в 2021 году, но мне хотелось бы иметь на канале свою интерпретацию данного long read.

https://github.com/charmbracelet/vhs
#github #cli

https://www.youtube.com/watch?v=RRZIweUW4YA
#k8s #kubernetes #auth

https://planetscale.com/blog/btrees-and-database-indexes
#db #btree