GoHome - это просто мастхев штука для хостинга #golang пакетов на своем домене.

Максимально актуальная тулза. Контора не очень хороших людей github взяла привычку блокировать разработчиков. С помошью GoHome можно хостить библиотеки независимо от github. Сейчас приходится заморочиться, чтобы сделать вот так, например https://gitflic.ru/project/getapp/boosty (там в ридми написано как устанавливать)

Звучит так, что нужно писать статью как это сделать правильно

https://petersanchez.com/easily-host-go-modules-on-your-domain/

https://sazak.io/articles/an-applied-introduction-to-ebpf-with-go-2024-06-06
#ebpf #go

Эта информация адресована тем, кто планирует деплоить в прод в ближайшее время. Специально для нашего ресурса астролог Ксения Тимуровна Рогова высчитала наиболее подходящие даты календаря для этой процедуры всем знакам зодиака (см. таблицу).

CVE-2024-6387 - regreSSHion: Remote Unauthenticated Code Execution Vulnerability in OpenSSH server

Debian Security
Зарепортили Qualyz Threat Research Unit, новость от них

Уязвимость в openssh server, занесённая коммитом, который рефакторил систему логирования. Под угрозой версии, начиная с 8.5.p1 исключительно до 9.8p1 (вышла 7 часов назад) .

Проверить, какая у вас сейчас версия: sshd -V
Определить версию вашего удалённого сервера: nc ip-or-domain 22

Security-патчи уже есть в репозиториях Ubuntu и Debian:

apt update
sudo apt install --upgrade openssh-server openssh-client

Как пропатчиться из сорсов (используйте только в случае, если вы знаете, что до вас обновление не долетит, так как способ нарушает принцип управления пакетами):
На всякий случай сделал инструкцию по установке 9.8p1 на Debian-based (Debian, Ubuntu, Mint, ...):

apt-get update
apt-get install build-essential zlib1g-dev libssl-dev libpam0g-dev libselinux1-dev
wget https://github.com/openssh/openssh-portable/archive/refs/tags/V_9_8_P1.tar.gz
tar -xzf V_9_8_P1.tar.gz
cd openssh-portable-V_9_8_P1
./configure
make
make install
mv /usr/sbin/sshd /usr/sbin/sshd.bak
ln -s /usr/local/sbin/sshd /usr/sbin/sshd
mkdir -p /usr/local/etc && for file in /etc/ssh/*; do [ -f "$file" ] && ln -s "$file" /usr/local/etc/; done
systemctl restart sshd


———
Сейчас гуляет архив с poc от 7etsuo, он лежал здесь: https://github.com/7etsuo/cve-2024-6387-poc/ - но сейчас тут 404. Один из последних коммитов гласил, что "poc нерабочий, но для начала сойдёт"

В статье Qualyz Threat Research Unit есть ссылка на технические детали эксплуатации, поэтому не затягивайте с апдейтом.

И снова о немного странном, но интересном и кому-то даже важном. ktunnel – тула, поднимающая туннельчик от кубового кластера до локальной машины и делай с ним что хочешь. Почувствуй себя нодой, так сказать.

https://github.com/omrikiei/ktunnel

От проектов странных к вещам понятным и полезным в хозяйстве: SSH over HTTPS. Особо великой науки в этом нет, просто пара ловких пассов руками на стороне клиента и сервера. Зато как только ты оказываешься в сети, где параноидально закрыто всё кроме 80/443 и 53, ты на коне.
P.S. Повесить SSH на 443 порт слишком просто. Нужно больше инкапсуляций!
https://trofi.github.io/posts/295-ssh-over-https.html

📡 impala - интересный tui для настройки wifi в системе. Использует iwd для взаимодействия системы с беспроводными сетями...

https://github.com/pythops/impala

P. S. И да, я знаю что есть nmtui, но всё же.

#wifi #network #tui

Редактор Zed теперь и на linux

Самый быстрый хайповый смузи редактор, написанный на Rust теперь можно запустить на linux. Кто уже успел затестить?

https://zed.dev/linux

https://github.com/zed-industries/zed/releases/tag/v0.143.6

🛠 Proxmox vs FreeBSD: Which Virtualization Host Performs Better? Сравнительные тесты Proxmox и Bhyve...

https://it-notes.dragas.net/2024/06/10/proxmox-vs-freebsd-which-virtualization-host-performs-better/#conclusion

#virtualization #proxmox #bhyve

JSBarebox
https://www.barebox.org/demo/?graphic=1

Если у вас есть статичный сайт, который лежит в публичном репозитории, то как вы будете его сервить? Очевидно, склонировать в публичную папку и настроить nginx

Но, на самом деле, клонить не обязательно, если репа и так публичная. Об этом подходе автор рассказывает в статье

Обожаю такие решения. Очевидные, но гениальные. Пример кода, кстати, на #rust

Serving a Website From a Git Repo Without Cloning It

https://mediocregopher.com/posts/git-proxy

https://github.com/pressly/sup
#github #remote

Хорошая реклама Линукса сегодня вышла, конечно.

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