Github commit / push rule, проверьте, чтобы два файла имели одинаковый список переменных - PullRequest
Новая
       14

Github commit / push rule, проверьте, чтобы два файла имели одинаковый список переменных

0 голосов
/ 29 апреля 2019

В моем репозитории Github есть два файла, написанные на языке Ballerina . А именно,
, а именно ballerina.conf и ballerina.conf.example, которые используются для хранения аналогичного списка переменных конфигурации.

В этих файлах я храню АКТУАЛЬНЫЕ учетные данные пользователя (которые используются для подключения к нескольким системам) в файле ballerina.conf.
Но при фиксации проекта в GitHub я хочу зафиксировать только ballerina.conf.exampleфайл.Я могу опустить файл ballerina.conf в файле .gitignore.

Мой вопрос заключается в том, что пользователи могут иногда забыть включить одну и ту же переменную в файлы ballerina.conf и ballerina.conf.example.

ballerina.conf -> DB_USERNAME = 'cseuser'  
ballerina.conf.example -> DB_USERNAME = '[dbusername]'

Есть ли способ применить правило в Github для сравнения этих двух файлов после коммита / толчка, что вновь введенная переменная находится в обоих файлах?

Например, если пользователь ввел переменную ТОЛЬКО в файл ballerina.conf, я хочу отклонить коммит / толчок, указав причину пользователю.Т.е. добавьте ту же переменную к ballerina.conf.example с фиктивным значением.

Ответы [ 2 ]

6 голосов
/ 29 апреля 2019

Только что обнаружил, что сам язык балерины предоставляет способ шифрования пароля с помощью команды ballerina encrypt.

например, значение шифрования: 1234

Ниже приведен пример вывода, который я пробовал. 

$ballerina encrypt 
Enter value:

Enter secret: 

Re-enter secret to verify:

Add the following to the runtime config:
@encrypted:{DMTaGYeDc2B9SBJmy5ekUSsYW8TV1uipLPTofy4zjr2Ke8eZ7khQbyDnKnNJ1kZm}

Or add to the runtime command line:
-e<param>=@encrypted:{DMTaGYeDc2B9SBJmy5ekUSsYW8TV1uipLPTofy4zjr2Ke8eZ7khQbyDnKnNJ1kZm}

Я использовал зашифрованное значение в моем ballerina.conf следующим образом. 

DB_USERNAME = "@encrypted:{l1WoT/u1YMX2+njesLjzKdpHXT7Vk03d830mjCFTSB+75aeohAO2AkEScotn7Wry}"

Поэтому нет необходимости поддерживать дополнительный файл в Github.

Обновление

При запуске службы балерина балерина попросит ввести секрет, который вы использовали для шифрования паролей в файле ballerina.conf. 

$ballerina run integrator/
ballerina: enter secret for config value decryption: 
<type your encryption password here (not visible), 1234>

ballerina: started HTTP/WS endpoint 0.0.0.0:3001


2019-03-03 12:44:25,999 INFO  [integrator:0.0.0] - service started
1 голос
/ 29 апреля 2019

Другой возможностью может быть наличие некоторого sed или другого сценария преобразования, который заменяет действительные учетные данные на поддельные, например создать ballerina.conf.example из существующего (но не git commit -ed, поэтому .gitignore -d) ballerina.conf one.

И этот сценарий трансформации может быть даже git hook (возможно, пред-коммитным), чтобы обеспечить его автоматический запуск.

Если пользователь ввел переменную ТОЛЬКО в файл ballerina.conf, я хочу отклонить коммит / push, указав причину пользователю.

Для этого и нужны git-хуки.

Однако помните, что если вы публикуете git некоторую личную информацию о реальных гражданах Европы, вас может беспокоить европейский GDPR . Но я не юрист (а гражданин Европы, довольный существованием этого ВВПР), но он вам может понадобиться.

Если вы разрабатываете какое-либо приложение, которое также управляет паролями, я рекомендую поместить эти зашифрованные пароли в какой-то отдельный файл , отличный от места хранения пользовательской информации. Текущий способ Unix иметь отдельные /etc/passwd и /etc/shadow файлы может быть вдохновляющим (и Apache делает то же самое со своим htpasswd ). См. Например passwd (5) и shadow (5) . Вы никогда не будете git публиковать свой собственный эквивалент shadow данных. FWIW, я делаю аналогичные вещи в моем проекте bismon GPLv3 + (файл git -kept contributors_BM описание пользователей против .gitignore -d файла passwords_BM с зашифрованными паролями).

PS. Не публикуйте даже зашифрованные, но реальные данные паролей. Решительный хакер может использовать компьютерные ресурсы, о которых вы даже не мечтаете взломать.

...