Комментарии 41
del
Через поддержку можно удалить полностью коммит с сенситивными данными -
https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository#fully-removing-the-data-from-github
У этого способа есть описанные ограничения, и им лучше пользоваться когда commit ещё не был вмёржен в основной репозиторий и не расползся по рабочим копиям - в этом случае коммит можно полностью зачистить.
Если я правильно помню, эту уязвимость нашли ещё в прошлом (позапрошлом?) году и ещё тогда в гитхабе ответили мол это не баг, а фича. Могу ошибаться насчёт сроков, но это давно не новость.
любой код, закоммиченный в публичный репозиторий, будет доступен вечно
Надо исходить из этого. Если процесс удаления контролируется не вами, а сторонним ПО, скорее всего, так и будет.
Да. И правильная стратегия, если в код закоммитили какой-то секрет - не удалять его быстренько, в надежде, что никто не увидел, а менять секрет. Он скомпрометирован, все.
И для меня задача смена секрета кажется очень простой, а значит - надежной, эффективной. В отличие от непостижимой магии git, которую реально мало кто знает (и этот пост - тому пример. Люди которые действительно знают гит в достаточном для безопасности объеме, над каждой строчкой этой статьи пожимали плечами, мол, ну это же общеизвестно! Думаю, таких было мало).
Не надо полагаться на науку. Не надо полагаться на магию. Тяжесть - это хорошо. Тяжесть - это надежно. Даже если не выстрелит - этим всегда можно врезать по башке.
Обычно проблема не с секретом, а с кодом или документацией. Например, в компании есть закрытый репозиторий с приватными фичами и опенсорс зеркало, и разработчик по ошибке или недосмотру, перетаскивая изменение в опенсорс, перетаскивает с ним всю закрытую репу.
В идеале это когда есть сканер на секреты и тогда нужно секрет тоже удалить, чтобы сканер не ругался.
> В отличие от непостижимой магии git, которую реально мало кто знает (и этот пост - тому пример.
Гит тут не причём. Это магия ГитХаба по оптимизации форка.
Как дела с этим у GitLab и Bitbucket?
Так что оптимально - личный ресурс на хоумлабе для себя и корпоративный для работы, на своем железе в своей сети. Иначе никто ничего не гарантирует.
Решение проблемы с файлом, в котором содержится приватный ключ.
git filter-branch --force --index-filter \
'git rm --cached --ignore-unmatch <имя_файла>' \
--prune-empty --tag-name-filter cat -- --all
git push origin --force --all
git push origin --force --tags
По моему так.
Hidden text
Вопрос - сколько времени удалённые данные будут доступны? Я про "вечно" не совсем верю. Больше похоже на умолчание Git - 90 дней. Тогда это даже разумно.
Вы, наверное, про reflog. Он не имеет к проблеме никакого отношения, здесь доступ к коммитам выполняется по хешам коммитов (так или иначе добытым, брутфорс (24 бита всего нужно), трекеры, архивы).
Так что "вечно" - до тех пор, когда будут удалены все до последнего форки в сети репозиториев.
Вы, наверное, про reflog.
Не только. reflog как пример. Головы удалённых веток и всё, на что они ссылаются, хранятся до ближайшей большой сборки. Я не верю, что на github нет периодического запуска аналога `git gc`.
Он не имеет к проблеме никакого отношения, здесь доступ к коммитам выполняется по хешам коммитов
Для того, чтобы коммиты были в репозитории, нужно, чтобы они остались доступны. И вот почему они доступны, когда на них ничего не ссылается уже долгое время - сомнительно. Даже ответ с самого github тут может быть некорректным.
По-нормальному таки надо сделать тест с проверкой после большой паузы.
Они доступны, потому что у всей "сети репозиториев" (апстрим и все форки) под капотом один-единственный git-репозиторий, над которым есть слой контроля доступа. Пусть есть репозиторий python/cpython. Ветка master в нём - на самом деле ветка с именем типа python/master. Ветка master в моём форке - на самом деле ветка syrslava/master в том же самом git-графе.
Слой контроля доступа скрывает этот нюанс от клиентов, давая им работать "как бы" с разными репозиториями. Потом кто-то создаёт и мержит PR из форка в апстрим - а внутри просто одна ветка гита мержится в другую. (Могу ошибаться с деталями, но суть такая.)
Поэтому фокус в статье и работает. GitHub по id форка (syrslava/cpython) находит внутренний git-репозиторий, в котором есть коммиты всех когда-либо созданных форков python/cpython, и по хешу находит коммит.
Вы продолжаете в упор не понимать то, о чём я говорю, хотя я сказал это открытым текстом.
Да, может быть, что внутри github один репозиторий на всех. Может, там что-то вроде, например, 2^16 репозиториев, хэшированных по микросекунде создания первого оригинала, и клоны включаются к оригиналам. Это всё неважно. Важно то, что это хранилище должно периодически чиститься, иначе в нём будет накапливаться то, что никто никогда использовать не будет - убитые репозитории, целые удалённые юзеры, выброшенные ветки, выброшенные ошибочные коммиты (включая те, где случайно вкоммитили пару десятков гигов промежуточных файлов), и прочая и прочая.
Я не верю, что там вообще нет очистки. Иначе бы оно давно разрослось до объёмов, которые не выдержит ни одно хранилище в мире. Я думаю, что очистка есть. Когда, как она проводится - их внутреннее дело. Может, они раз в год чистят, или когда вырастет от предыдущего в два раза. Для GC существуют много алгоритмов и критериев. Но хоть когда-то это должно делаться.
Прежде чем продолжать дискуссию, прошу вас оценить самому необходимость чисток, её периодичность и типовые подходы. Можете начать с реализации команд prune, gc, repack в каноническом клиенте git. Только после этого будет смысл продолжать обсуждение.
А вас прошу оценить, сколько репозиториев/форков/веток создаются и забрасываются каждую единицу времени по сравнению с количеством репозиториев/форков/веток, о которых кто-то парится достаточно, чтобы их вообще удалять. И можно подумать о принципиальной целесообразности GC при масштабах и политиках гитхаба.
Это, кстати, должно быть не слишком сложно: https://www.gharchive.org/
Они накрутили с пул-реквестами, на каждый из которых создаётся скрытая ветка, или что-то такое. В результате эффективный GC там сделать толком не получается.
Интересно, что у GitLab вполне себе можно запустить GC. Результат виден по освободившемуся месту, доступному для аккаунта.
Непонятно, как при отсутствии GC считается место у GitHub. Получается, что нет способа реально освободить место.
Они накрутили с пул-реквестами, на каждый из которых создаётся скрытая ветка, или что-то такое.
И что? Ну пусть невыдаленный пулл-реквест хранит ветку. Там только изменения для этого PR и он виден в списке.
Gerrit вон вообще хранит каждую версию каждого коммита на ревью (хотя можно грубой силой зачистить старые).
В результате эффективный GC там сделать толком не получается.
Это всё не помешает. Список существующих голов плюс инкрементальная сборка, которая медленно в фоне хрустит по объектам. Специфика Git меняет только способ доступа к объектам (хэши вместо указателей в памяти), но не остальное, и все методы, наработанные десятилетиями для объектов в памяти в языках с AutoMM (LISP, Java, C#, JavaScript, Lua, тысячи их) - будут работать без принципиальных изменений. (Хм, разве что систему поколений придётся убрать... и то не уверен.)
Иначе бы оно давно разрослось до объёмов, которые не выдержит ни одно хранилище в мире.
Как думаете, сколько репозиториев/форков/веток/whatever "поместится" в одно десятиминутное 1080p видео на YouTube?
GC отчищает то, на что нет указателей. А в форке есть своя главная ветка.
То есть коммиты которые не принадлежат больше никакой ветке скорее всего удаляются. А вот коммиты которые в ветке форка будут на месте. Видимо гитхаб не удаляет ветки для удалённых форков.
Эффект Стрейзанд распространяется на всё, что попадает в сеть. Если держать эту константу в оперативной памяти - будет значительно меньше неприятных сюрпризов.
Похоже до людей стало доходить, что единственный способ ограничить доступ к репозитарий это Self-hosted решение….
Котлы мог подумать ….
Как будето с self-hosted ничего не утекало.
Как будето с self-hosted ничего не утекало.
Но в этом случае виновного можно было найти и прикопать!
Там по крайней мере метода ограничения доступа известные: Login+password :). Или сервер только в локальной сети доступен :)
Методы есть. Но есть и нюанс: нужны деньги на нормального специальста.
- Не все эти методы защиты используют. И не для всех окружений.
- Вектор атак с социальной инженерией работает.
- Ну у всех система а актуальном состянии.
- Уязвимости нулевого дня существуют.
Self-hosted можно сделать безопастнее, но это может оказаться дороже.
Любой может получить доступ к удалённым и приватным данным репозиториев GitHub