Как убрать private в github
Setting repository visibility
In this article
You can choose who can view your repository.
About repository visibility changes
Organization owners can restrict the ability to change repository visibility to organization owners only. For more information, see «Restricting repository visibility changes in your organization.»
We recommend reviewing the following caveats before you change the visibility of a repository.
Making a repository private
Making a repository public
For information about improving repository security, see «Securing your repository.»
Changing a repository’s visibility
On GitHub.com, navigate to the main page of the repository.
Under your repository name, click
Settings. 
Under «Danger Zone», to the right of to «Change repository visibility», click Change visibility. 
Select a visibility.
To verify that you’re changing the correct repository’s visibility, type the name of the repository you want to change the visibility of.
Click I understand, change repository visibility.
Немного о приватности реальных Git-репозиториев
Введение
Здравствуйте, уважаемые читатели. Сегодня на повестке дня у нас небольшое тестирование —
первых ≈100 тысяч по популярности сайтов в интернете (ранжирование на основе статистики посещаемости с Alexa Rank). Стоит отметить, что оное тестирование будет достаточно узконаправленным, а именно — проверим каждый сайт на предмет существования и открытости Git-репозитория без аутентификации прямо из веба по url-адресу искомого. Напомню, что такая брешь в безопасности зачастую позволяет прочитать актуальные исходные коды на сервере, получить чувствительную информацию (файлы конфигов, структуру системы и т.д.) и, в последствии, получить определенного рода права на сервере. Рай для различного рода негодяев, да и только 🙂
Совершенно аналогичную проверку я делал для себя порядка 100 дней назад, и сегодня мы сделаем это ещё раз, посмотрим что изменилось и что с этим делать.
Разумеется, использовать будем список сайтов, полученный в рамках первого тестирования.
Для заинтересовавшихся милости прошу под кат.
*Вся информация, описанная в статье, предоставлена исключительно с исследовательско-ознакомительной целью.
Что происходит?
Итак, для начала нужно понимать, что кол-во сайтов не самое маленькое, и проверку вручную, разумеется, сделать невозможно. Решение — напишем автоматизированную утилиту для проверки.
Вообще говоря, на практике достаточное условие проверки очень простое:
Будем считать, что Git-репозиторий является открытым и доступным из веба без авторизации, если доступен на чтение файл конфигов по адресу http(s)://sitename.com/.git/config (забавно, что иногда в этом файле также содержатся данные для подключения к git-серверу, но нам это совершенно не обязательно).
Тут основной момент в том, что многие разработчики закрывают доступ на просмотр директории /.git/, но забывают закрыть доступ на сами файлы/директории внутри оной. Таким образом, если нам удалось прочитать конфиг — то практически всегда мы сможем прочитать и файл /.git/index (список, содержащий все файлы), и, собственно, сможем прочитать и все доступные исходники (из директории /.git/objects/, преобразовав blob-объекты в исходное представление файлов). Для этого можно использовать любой git-дампер (например этот), или написать свой.
Тесты и анализ
Тестирование #1
Дата: 11 декабря 2016 года
Кол-во тестируемых сайтов: 99991
Открытых Git-репозиториев: 639 (0,64% от общего числа)
Тестирование #2
Дата: 21 марта 2017 года
Кол-во тестируемых сайтов: 99991 (тот же лист сайтов, что и в первый раз)
Открытых Git-репозиториев: 599 (0,60% от общего числа)
Тестирование #3
Дата: 21 сентября 2020 года
Кол-во тестируемых сайтов: 99991 (тот же лист сайтов, что и в первый раз)
Открытых Git-репозиториев: 63 (0,06% от общего числа)
Примечательно, что время работы утилиты на домашнем ноутбуке (при скорости интернет-соединения в 20 мбит/с) составило около 16-ти минут, что совсем не много.
Итак, за 100 дней кол-во «открытых» репозиториев (из моей выборки) сократилось на 40 штук. Это порядка 6% от изначального количества.
Много ли разработчиков одумалось? Нет, не похоже (такими темпами только через года 4-5 можно ожидать исправления проблем на данной выборке).
В целом, конечно, процент открытых репозиториев небольшой. Но с другой стороны, взяв выборку скажем в один миллион сайтов — это уже порядка 10 000 сайтов с подобной брешью.
При том нужно понимать, что это самые популярные сайты по версии Alexa Rank, а значит они обязаны быть защищенными. Предположительно, чем дальше по списку — тем чаще будут попадаться открытые репозитории.
Среди найденных сайтов были обнаружены сайты с весьма большой аудиторией (> 1кк уникальных/сутки), а также ресурсы различных учебных заведений (включая российские ведущие вузы, среди них некоторые выпускают по направлению веб-безопасности) и организаций. Этим грешит даже сайт одного небезызвестного архиватора.
(* Пример полученных исходных кодов. Обратите внимание на SQL дампы и лист авторизации)
Вариант вектора атаки
Самое интересное, что практически весь процесс (от добычи url’ов сайтов до получения исходников) можно автоматизировать. Более того, подобные решения уже существуют, и злоумышленники успешно монетизируют ваши ресурсы.
Списки проверяемых сайтов и файлы результатов я, разумеется, не привожу. При желании вы сможете взять ТОПы сайтов, и протестировать их самостоятельно.
Как защититься?
С вами был Петр,
спасибо за внимание.
Как убрать из Git-репозитория файлы с конфиденциальной информацией
Файлы проиндексированы, написано сообщение коммита, данные отправлены на сервер… И вдруг хочется повернуть время вспять. В коммит попал файл, которого там быть не должно. Когда такое случается, приходит время обращаться к поисковику.
Каждый разработчик когда-то по ошибке коммитил в общедоступный репозиторий файлы с конфиденциальной информацией. Как справиться с такой проблемой? Как сделать так, чтобы ничего подобного больше не случилось бы?
В этой статье я расскажу о том, что делать в том случае, если в репозиторий случайно попал файл, которому там совершенно нечего делать. Здесь же я приведу команды Git, которые позволят подправить историю, и поделюсь некоторыми рекомендациями по организации безопасной работы с конфиденциальной информацией.
Минимизация ущерба
▍Коммит пока не отправлен в удалённый репозиторий
Если вы пока не отправили коммит в репозиторий, то, в общем-то, возникшая ситуация никакой угрозы не несёт. Для того чтобы всё исправить, достаточно просто вернуться к предыдущему коммиту:
Файлы останутся в рабочей копии репозитория, вы сможете внести в проект необходимые изменения.
Если же вы хотите сохранить коммит и вам нужно просто удалить из него определённые файлы, тогда поступите так:
Это позволит исправить неправильный коммит и поможет не потерять изменения, внесённые в проект остальными коммитами.
▍Коммит отправлен в удалённый репозиторий
Если вы уже отправили коммит в удалённый репозиторий, то, в первую очередь, вам нужно знать о том, чем отличаются публичные и приватные репозитории.
Если ваш репозиторий является приватным, и при этом он не доступен ботам или людям, которым вы не доверяете, вы можете просто внести поправки в последний коммит, воспользовавшись парой вышеприведённых команд.
Если вы отправили в репозиторий, после проблемного коммита, и другие коммиты, это не помешает вам убрать файлы с конфиденциальными данными из истории Git, воспользовавшись командой git filter-branch или инструментом BFG Repo-Cleaner.
Вот пример использования git filter-branch :
Но, делая это, учитывайте два важных аспекта подобных изменений, вносимых в репозиторий:
Нужно ли создавать новые секретные ключи в том случае, если их актуальные версии попали в публичный репозиторий?
Если кратко ответить на вопрос, вынесенный в заголовок, то — нужно. Если ваш репозиторий общедоступен, или если вы, по любой причине, полагаете, что он — не место для хранения секретных данных, вам необходимо будет счесть попавшие в него конфиденциальные данные скомпрометированными.
Даже если вы удалили эти данные из репозитория, вы ничего не сможете сделать с ботами и с форками репозитория. Как же поступить?
Рекомендации по хранению конфиденциальных файлов в проектах, в которых для контроля версий применяется Git
Для того чтобы не допустить утечек конфиденциальной информации стоит придерживаться следующих рекомендаций.
▍Используйте, если это возможно, ключи API
Скомпрометированные ключи API легко деактивировать, такие ключи легко создать заново. Если это возможно — используйте именно их, а не нечто вроде логинов и паролей.
▍Храните ключи API, пользуясь средствами вашего инструмента для сборки проектов
Управление переменными окружения
Сделайте так, чтобы Git не отслеживал бы файлы, содержащие конфиденциальную информацию.
Наличие подобного шаблонного файла помогает тем, кто работает над проектом, добавлять в проект ключи API, избавляя их от необходимости чтения документации.
▍Не меняйте историю Git в удалённых репозиториях
Постарайтесь строго придерживаться этого правила. Если вы следовали вышеприведённым рекомендациям, то историю Git вам менять и не потребуется.
Итоги
Надеюсь, мой материал поможет вам в безопасной работе с конфиденциальными данными.
А вам случалось отправлять в общедоступный репозиторий что-то такое, что туда попадать не должно?
Github добавил настройки доступа к веткам (protected branches)
Гитхаб — великолепный агрегатор репозиториев и инструмент для коллективной работы. К сожалению, многие возможности конфигурирования на стороне сервера (вроде коммит хуков) остаются недоступными. Но ситуация постепенно меняется в лучшую сторону.
Случилось то, чего многие ждали довольно долго. А именно: недавно была анонсирована фича, под названием protected branches, которая позволяет настроить правила работы с ветками в рамках репозитория. Да, теперь можно запретить force push в master!
Под катом скриншоты и выдержки из блога разработчиков.
Функция защищенных веток (protected branches) дает возможность администраторам репозиториев запретить операцию force push в заданные ветки.
Если опция активна для ваших репозиториев, мы можете настроить ее на вкладке в настройках репозитория:
В дополнение к возможности блокировки force push, можно выставить список обязательных проверок (status checks). Эта функциональность работает благодаря Status API, соответственно поставить на проверку можно любое интегрируемое действие, такое как запуск сборщика, прогон тестов, прогон статического анализатора и т.п.
Если хотя бы одна из обязательных проверок не проходит, кнопка «Merge» не будет активна:
Чтобы статусам можно было верить, ветка должна быть актуальной. Это позволяет гарантировать, что после слияния ничего не сломается. Новая кнопка «Update branch» позволяет одним нажатием влить последнее состояние базовой ветки (например master) в текущую, а затем выполнить проверки:
Больше информации по теме можно получить на странице помощи.
От себя добавлю, что запрет на force push, с моей точки зрения — это самое толковое, что появилось на гитхабе за последнее время. Теперь можно не переживать, что джуниор испортит мастер ветку неаккуратным пушем. Конечно, данная проблема решалась и другими способами. Запретить форс пуш можно было в корпоративных репозиториях, но только для основной ветки, либо на весь репозиторий целиком.
До появления защищенных веток, отдельным разработчикам рекомендовали выставлять хуки на операцию push, чтобы локально предотвратить святотатство. Понятное дело, что это все равно не давало 100% гарантий.
В иных коллективах бывает принята модель, при которой каждый сотрудник должен сделать форк репозитория и выставлять пул реквесты из него. Соответственно, прямой доступ к репозиторию дается только избранным. Однако это не всегда оказывается удобным.
Будем надеяться, что гитхаб будет радовать нас и впредь.
Обновление репозитория git без ввода паролей
При обновлении репозитория на сервере через консоль командой git pull система каждый раз запрашивает пароль. Ввожу пароль аккаунта «В» и команда успешно выполняетя.
Вопрос: как сделать так, чтобы при вводе команды из консоли, система не запрашивала пароль? Это должно позволить выполнять обновление репозитория из php.
Что для этого нужно, размещать какой-то специальный ключ на сервере?
1 ответ 1
Если это https, то будет примерно следующий путь:
Для ssh будет такой:
https
Требуется Git версии не ниже 1.7.10
В этом случае вам всегда требуется указывать пароль при общении с сервером. Git можно попросить сохранять на некоторое время (по умолчанию на 15 минут) введённые данные командой:
При желании можно изменить стандартное время запоминания командой
(время указывается в секундах)
Вы можете также указать git хранить ваши данные постоянно:
Обнулить настройки этой возможности можно командой:
Вы можете указать информацию для авторизации в url, по которому осуществляете доступ к репозиторию, для этого его нужно преобразовать так:
Измените текущий url в remote на указанный (как это сделать, описано ниже в ответе) и авторизация не будет запрашиваться.
Помните, что и в этом случае ваши данные будут храниться в открытом виде.
Существует возможность настроить netrc
Про работу с запароленным ключём SSH знаю лишь то, что можно настроить ssh-agent, который аналогично позволит не вводить каждый раз пароль от ключа ssh.
Для начала создайте ssh-ключ с помощью команды:
Она попросит ввести имя файла (во многих случаях можно оставить имя по умолчанию) и пароль. Пароль при желании можно оставить пустым, для этого просто дважды нажмите Enter при запросе пароля (обычно рекомендуется устанавливать пароль).
По умолчанию пара ключей появляется в каталоге
После этого можно перейти к настройке ssh-agent :
Запускаем ssh-agent в фоне:
Теперь осталось добавить сгенерированный ключ в ssh-agent :
Если вы настроите доступ по ssh к своему репозиторию с использованием ключа, то работу, вероятно, можно будет производить и из программ.
Для уже созданного репозитория можно изменить способ доступа, используя команду
где задаёт путь, в котором используется нужный протокол