Github использует Smart HTTP
Я настраиваю кеширование паролей, но это странно, поскольку я думал, что я уже это сделал. Из сообщения электронной почты в github, кажется, что они немного изменили ситуацию:
Привет, Thufir,
Что вы видите, так это то, что все вновь созданные репозитории теперь используют Smart HTTP вместо SSH по умолчанию. У нас есть статья справки о том, что объясняет, как изменить его здесь: https://help.github.com/articles/why-is-git-always-asking-for-my-password
У нас также есть сообщение в блоге об этом здесь: https://github.com/blog/1104-credential-caching-for-wrist-friendly-git-usage
Честность, которую я вижу, заключается в том, что я, похоже, вспоминаю эти точные указания некоторое время назад для кэширования пароля.
Кроме того, разве нет лучшего подхода, возможно, с открытым ключом? Я не совсем уверен, где мой пароль кэширован, но я знаю, что это не такая замечательная идея. (Я на Linux, поэтому не могу использовать предлагаемый .exe в сообщении электронной почты.)
Ответы
Ответ 1
Вы можете использовать SSH для подключения к Github. У них есть руководство SSH, если вы еще не добавили свой открытый ключ в свою учетную запись Github, а затем все, что вам нужно сделать, это использовать URL репозитория SSH вместо URL-адреса ретранслятора HTTPS для клонирования вашего репозитория.
Вы можете найти URL-адрес SSH, нажав кнопку рядом с URL-адресом репо. Если вы уже клонировали репозиторий HTTPS, вы можете добавить новый удаленный указатель на URL SSH и использовать его для push/pulling без пароля!
Ответ 2
Вам нужно быть более конкретным в отношении того, что вы подразумеваете под "лучшим подходом", потому что в зависимости от того, как вы это интерпретируете, вы получите разные ответы. Попробуйте уточнить свои вопросы немного больше, чтобы они были более конкретными и конкретными.
Более глубокий взгляд на то, о чем вы говорите, привел к тому, что я обнаружил git-credential-store, что, по-видимому, указывает на то, что пароли хранятся в простой текст.
Как я понимаю, вы будете полагаться на модель безопасности ОС, чтобы гарантировать, что файл не будет доступен или изменен неавторизованными сторонами. Ни одна из этих данных, похоже, не хэшируется солью. Короче говоря, безопасность вашей учетной записи будет сильно зависеть от безопасности компьютера, на котором вы храните кеш.
Что касается того, почему поддержка HTTP является большим фокусом для git, в будущем хорошо объясняется здесь.
Как резюме, однако, HTTP является стандартным и имеет высокую степень принятия, он поддерживает как безопасные, так и небезопасные обмены в сочетании с тем фактом, что порт 80 открыт в большинстве случаев и брандмауэрах в любом случае, делает использование HTTP относительным без проблем.