Как лучше всего работать с паролями в git-репозиториях?

Подход может состоять в том, чтобы установить пароль (или ключ API), используя переменную среды. Таким образом, этот пароль находится вне контроля версий.

С Bash вы можете установить переменную окружения, используя

export your_env_variable='your_password'

Этот подход можно использовать с такими службами непрерывной интеграции, как Travis, при этом ваш код (без пароля), хранящийся в репозитории GitHub, может быть выполнен Travis (с вашим паролем, установленным с помощью переменной среды).

С помощью Bash вы можете получить значение переменной окружения, используя:

echo "$your_env_variable"

С помощью Python вы можете получить значение переменной окружения, используя:

import os
print(os.environ['your_env_variable'])

PS: имейте в виду, что это, вероятно, немного рискованно (но это довольно распространенная практика) https://www.bleepingcomputer.com/news/security/javascript-packages-caught-stealing-environment-variables/

PS2: это dev.to статья под заголовком "Как безопасно хранить ключи API" может быть интересно читать.

Что сказал Грег, но я бы добавил, что неплохо проверить файл foobar.config-TEMPLATE.

Он должен содержать имена примеров, пароли или другую конфигурационную информацию. Тогда очень очевидно, что должен содержать реальный foobar.config, без необходимости искать во всем коде, для которого значения должны присутствовать в foobar.config и в каком формате они должны быть.

Часто значения конфигурации могут быть неочевидными, например строки подключения к базе данных и т.д.

Можно использовать Vault, который защищает, сохраняет и контролирует доступ к токенам, паролям, сертификатам, ключам API и т.д. Для Пример Ansible использует Ansible Vault, который заключает сделку с паролями или сертификатами, используемыми в playbooks

Вот техника, которую я использую:

Я создаю папку в моей домашней папке с именем: .config

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

Я обычно использую обратный синтаксис доменного имени, такой как:

com.example.databaseconfig

Затем в скрипте bash я делаю это:

#!/bin/bash
source $HOME/.config/com.example.databaseconfig ||exit 1

|| exit 1 || exit 1 приводит к завершению работы сценария, если он не может загрузить файл конфигурации.

Я использовал эту технику для скриптов bash, python и ant.

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

Если конкретное приложение требует более одного файла, я создаю подпапку, а не один файл.

Если вы используете рубин на рельсах, драгоценность Figaro очень хорошая, легкая и надежная. Он также имеет низкий коэффициент головной боли в рабочей среде.