Comment puis-je enregistrer mes clés secrètes et mon mot de passe en toute sécurité dans mon système de contrôle de version?


134

Je garde des paramètres importants comme les noms d'hôte et les ports des serveurs de développement et de production dans mon système de contrôle de version. Mais je sais que c'est une mauvaise pratique de garder des secrets (comme les clés privées et les mots de passe de base de données) dans un référentiel VCS.

Mais les mots de passe - comme tout autre paramètre - semblent devoir être versionnés. Alors, quelle est la bonne façon de contrôler la version des mots de passe?

J'imagine que cela impliquerait de garder les secrets dans leur propre fichier de "paramètres secrets" et de faire chiffrer ce fichier et contrôler la version. Mais quelles technologies? Et comment faire cela correctement? Y a-t-il une meilleure façon de procéder?


Je pose la question en général, mais dans mon cas spécifique, je voudrais stocker des clés secrètes et des mots de passe pour un site Django / Python en utilisant git et github .

De plus, une solution idéale ferait quelque chose de magique lorsque je pousse / tire avec git - par exemple, si le fichier de mots de passe chiffrés change, un script est exécuté qui demande un mot de passe et le déchiffre en place.


EDIT: Pour plus de clarté, je me demande sur l' endroit où stocker la production secrets.


1
En fait, amassez de l'argent pour que le repo reste privé.
John Mee

29
@JohnMee En fait, je paie déjà pour un dépôt privé, mais le point demeure - vous ne devriez pas garder les informations sensibles dans votre dépôt.
Chris W.20

1
Je pense qu'une grande partie de la raison pour laquelle il sera difficile d'obtenir des réponses satisfaisantes est que le mot de passe en clair à l'ancienne pour se connecter à une base de données est une relique d'une époque moins hostile. La bonne réponse est quelque chose comme "votre code ne devrait pas avoir besoin d'un secret", mais les systèmes auxquels vous accédez ne vous donnent pas beaucoup de choix.
msw le

4
Pourquoi? Il y a une valeur zilch dans la version contrôlant les mots de passe pour les services externes. La principale valeur du contrôle de version est que vous pouvez inspecter les révisions historiques de votre application connues pour être en état de fonctionnement et les exécuter . Cependant, les anciens mots de passe sont inutiles pour vous. S'ils ont été révoqués, ils ne fonctionneront plus jamais.
Colonel Panic

Réponses:


100

Vous avez parfaitement raison de vouloir crypter votre fichier de paramètres sensibles tout en conservant le fichier dans le contrôle de version. Comme vous le mentionnez, la meilleure solution serait celle dans laquelle Git cryptera de manière transparente certains fichiers sensibles lorsque vous les poussez afin que localement (c'est-à-dire sur toute machine possédant votre certificat) vous puissiez utiliser le fichier de paramètres, mais Git ou Dropbox ou qui que ce soit le stockage de vos fichiers sous VC ne permet pas de lire les informations en texte brut.

Tutoriel sur le cryptage / décryptage transparent pendant Push / Pull

Cet essentiel https://gist.github.com/873637 montre un tutoriel sur la façon d'utiliser le pilote de filtre smudge / clean de Git avec openssl pour crypter de manière transparente les fichiers poussés. Il vous suffit de faire une configuration initiale.

Résumé de son fonctionnement

Vous allez essentiellement créer un .gitencryptdossier contenant 3 scripts bash,

clean_filter_openssl 
smudge_filter_openssl 
diff_filter_openssl 

qui sont utilisés par Git pour le déchiffrement, le chiffrement et la prise en charge de Git diff. Une phrase de passe principale et un salt (corrigé!) Sont définis dans ces scripts et vous DEVEZ vous assurer que .gitencrypt n'est jamais réellement poussé. Exemple de clean_filter_opensslscript:

#!/bin/bash

SALT_FIXED=<your-salt> # 24 or less hex characters
PASS_FIXED=<your-passphrase>

openssl enc -base64 -aes-256-ecb -S $SALT_FIXED -k $PASS_FIXED

Similaire pour smudge_filter_open_sslet diff_filter_oepnssl. Voir Gist.

Votre dépôt contenant des informations sensibles doit avoir un fichier .gitattribute (non chiffré et inclus dans le dépôt) qui fait référence au répertoire .gitencrypt (qui contient tout ce dont Git a besoin pour chiffrer / déchiffrer le projet de manière transparente) et qui est présent sur votre machine locale.

.gitattribute Contenu:

* filter=openssl diff=openssl
[merge]
    renormalize = true

Enfin, vous devrez également ajouter le contenu suivant à votre .git/configfichier

[filter "openssl"]
    smudge = ~/.gitencrypt/smudge_filter_openssl
    clean = ~/.gitencrypt/clean_filter_openssl
[diff "openssl"]
    textconv = ~/.gitencrypt/diff_filter_openssl

Désormais, lorsque vous transférez le référentiel contenant vos informations sensibles vers un référentiel distant, les fichiers seront chiffrés de manière transparente. Lorsque vous effectuez une extraction à partir d'une machine locale qui a le répertoire .gitencrypt (contenant votre phrase de passe), les fichiers seront déchiffrés de manière transparente.

Remarques

Je dois noter que ce tutoriel ne décrit pas un moyen de chiffrer uniquement votre fichier de paramètres sensibles. Cela cryptera de manière transparente l'ensemble du référentiel qui est poussé vers l'hôte VC distant et décryptera l'intégralité du référentiel afin qu'il soit entièrement décrypté localement. Pour obtenir le comportement souhaité, vous pouvez placer des fichiers sensibles pour un ou plusieurs projets dans un sensitive_settings_repo. Vous pouvez étudier comment cette technique de chiffrement transparent fonctionne avec les sous-modules Git http://git-scm.com/book/en/Git-Tools-Submodules si vous avez vraiment besoin que les fichiers sensibles se trouvent dans le même référentiel.

L'utilisation d'une phrase secrète fixe pourrait théoriquement conduire à des vulnérabilités de force brute si les attaquants avaient accès à de nombreux dépôts / fichiers cryptés. OMI, la probabilité de cela est très faible. Comme une note au bas de ce tutoriel le mentionne, le fait de ne pas utiliser de phrase secrète fixe entraînera des versions locales d'un dépôt sur différentes machines montrant toujours que des modifications ont eu lieu avec 'git status'.


1
Oh très intéressant. Cela ressemble presque exactement à ce que je veux (à l'exception du chiffrement de tout le référentiel).
Chris W.

Vous pouvez soit conserver tous les fichiers de paramètres sensibles pour plusieurs applications dans un référentiel chiffré, soit ajouter le référentiel chiffré avec les paramètres sensibles à votre projet en tant que sous-module Git comme décrit ici git-scm.com/book/en/Git-Tools-Submodules .
dgh

Le stockage des mots de passe / paramètres de production dans un sous-module (chiffré) n'est pas rare. stackoverflow.com/questions/11207284/… . Cela faciliterait même la gestion des paramètres entre les projets.
dgh

Cela vaut peut-être la peine de vérifier github.com/AGWA/git-crypt pour une solution mise à jour. Il a l'avantage de permettre l'écriture de fichiers individuels, et il prétend être "prouvé sémantiquement sécurisé". L'auteur de l'essentiel lui-même a suggéré que cet outil est meilleur, sur github.com/shadowhand/git-encrypt .
geekley

52

Heroku pousse l'utilisation de variables d'environnement pour les paramètres et les clés secrètes:

L'approche traditionnelle pour gérer ces variables de configuration est de les mettre sous source - dans un fichier de propriétés d'une sorte. Il s'agit d'un processus sujet aux erreurs, et est particulièrement compliqué pour les applications open source qui doivent souvent maintenir des branches séparées (et privées) avec des configurations spécifiques à l'application.

Une meilleure solution consiste à utiliser des variables d'environnement et à garder les clés hors du code. Sur un hôte traditionnel ou travaillant localement, vous pouvez définir des variables d'environnement dans votre bashrc. Sur Heroku, vous utilisez config vars.

Avec Foreman et les .envfichiers, Heroku fournit une chaîne d'outils enviable pour exporter, importer et synchroniser les variables d'environnement.


Personnellement, je pense qu'il est erroné de sauvegarder des clés secrètes à côté du code. C'est fondamentalement incompatible avec le contrôle de code source, car les clés sont pour des services extrinsèques au code . Le seul avantage serait qu'un développeur peut cloner HEAD et exécuter l'application sans aucune configuration. Cependant, supposons qu'un développeur vérifie une révision historique du code. Leur copie comprendra le mot de passe de la base de données de l'année dernière, de sorte que l'application échouera par rapport à la base de données d'aujourd'hui.

Avec la méthode Heroku ci-dessus, un développeur peut vérifier l'application de l'année dernière, la configurer avec les clés d'aujourd'hui et l'exécuter avec succès sur la base de données d'aujourd'hui.


1
Cette réponse n'a pas assez d'attention, mais elle coïncide le plus avec la méthode Linux.
Nikolay Fominyh

11
Donc, si les variables d'environnement sont définies dans votre bashrc et que vous déployez un nouveau serveur, qu'est-ce qui crée le bashrc? Cela ne fait-il pas que déplacer les mots de passe de votre référentiel de code source vers votre configuration de déploiement? (qui est probablement aussi dans le repo de code source, ou dans un repo de son propre?)
Jonathan Hartley

@JonathanHartley votre .bashrc ne doit pas être dans le référentiel de code de votre application Django.
Steve

4
Désolé, mon commentaire est ambigu, mais c'est parce que je suis vraiment confus. J'adore le son du point de vue de cette réponse, mais je ne l'ai jamais entièrement compris. Si je déploie dans plusieurs environnements différents, dont chacun contient plusieurs hôtes, et peut-être plusieurs types d'hôtes, alors je dois évidemment automatiser la création des fichiers .bashrc qui existeront sur chaque hôte pour définir ses variables d'environnement. La réponse dit-elle donc que je devrais avoir un deuxième dépôt, distinct de ma source, qui contient tous les paramètres qui deviendront des variables d'environnement dans .bashrc lors du déploiement?
Jonathan Hartley

1
Ils ne doivent être configurés qu'une seule fois par machine sur laquelle vous déployez. Si votre processus de déploiement consiste à "faire tourner une nouvelle machine et tester que c'est OK avant de rediriger le trafic vers elle, puis de tirer sur l'ancienne dans la tête", ce qui à mon humble avis est la meilleure pratique, alors vous devez vraiment automatiser la création de tout ce qui définit le env vars.
Jonathan Hartley

16

Le moyen le plus propre à mon avis est d'utiliser des variables d'environnement. Vous n'aurez pas à gérer les fichiers .dist par exemple, et l'état du projet sur l'environnement de production serait le même que celui de votre machine locale.

Je recommande de lire le chapitre de configuration de l' application Twelve-Factor , les autres aussi si cela vous intéresse.


6
Il semble que les variables d'environnement soient un bon moyen d'exécuter l'application avec les paramètres secrets ... mais cela ne répond toujours pas à la question de savoir où conserver ces paramètres.
Chris W.

2
Vous devriez généralement avoir un fichier README pour chacune de vos applications. Ici, spécifiez les variables d'environnement à définir et chaque fois que vous déployez un projet, suivez simplement les étapes et définissez chacune d'elles. Vous pouvez également créer un script shell avec plusieurs export MY_ENV_VAR=, et lorsque vous déployez, remplissez-le simplement avec les bonnes valeurs et sourcecela. Si par garder vous entendez la version des paramètres, vous ne devriez pas faire cela en premier lieu.
Samy Dindane

Également, vote favorable pour l'application Twelve-Factor - vraiment super.
Chris W.

4
@Samy: Et si vous avez automatisé le déploiement?
Jonathan Hartley

3
@Samy Je ne comprends toujours pas comment les variables d'environnement seraient définies. La page de l'application à 12 facteurs ne le précise pas non plus (sauf si vous êtes sur Heroku, ce qui n'est pas mon projet actuel.) Sommes-nous en train de dire qu'un script générateur doit demander à un magasin de configuration central "Je suis la machine X, s'il vous plaît donnez-moi mes données de configuration », et cela répond avec les valeurs des variables d'environnement qui devraient être définies. Dans ce cas, je ne pense plus que vous ayez besoin d'un script généré. Je spécule follement ici, est-ce que j'aboie le bon arbre?
Jonathan Hartley

10

Une option serait de placer les informations d'identification liées au projet dans un conteneur chiffré (TrueCrypt ou Keepass) et de le pousser.

Mettre à jour comme réponse de mon commentaire ci-dessous:

Question intéressante btw. Je viens de trouver ceci: github.com/shadowhand/git-encrypt qui semble très prometteur pour le cryptage automatique


Ce serait bien d'avoir quelque chose que je pourrais automatiser. De telle sorte que si mon fichier de mot de passe crypté change, il décrypte automatiquement le nouveau fichier.
Chris W.20

7
Question intéressante btw. Je viens de trouver ceci: github.com/shadowhand/git-encrypt qui semble très prometteur pour le cryptage automatique.
schneck

1
Wow, super. La description de git-encryptressemble exactement à ce que je recherche «Lorsque vous travaillez avec un référentiel git distant hébergé sur un serveur de stockage tiers, la confidentialité des données devient parfois un problème. Cet article vous guide à travers les procédures de configuration des référentiels git pour lesquels vos répertoires de travail locaux sont normaux (non chiffrés) mais le contenu validé est chiffré. " (Bien sûr, je ne veux qu'un sous-ensemble de mon contenu chiffré ...)
Chris W.

@schneck publie votre commentaire en tant que réponse afin que Chris puisse l'accepter - on dirait que c'est ce qu'il recherche.
Tony Abou-Assaleh

9

Je suggère d'utiliser des fichiers de configuration pour cela et de ne pas les versionner.

Vous pouvez cependant version des exemples des fichiers.

Je ne vois aucun problème de partage des paramètres de développement. Par définition, il ne doit contenir aucune donnée valable.


1
Mais alors où stocker les enregistrements de mots de passe canoniques? Cela me rendrait nerveux d'avoir ces données dans un fichier de configuration sur une machine qui pourrait exploser un jour.
Chris W.20

@ChrisW. Si la machine explose, vous n'avez plus forcément besoin du mot de passe ... Cependant, si vous n'avez qu'une copie des données sur votre machine de production, cela devrait soulever un drapeau rouge. Mais cela ne veut pas dire qu'il devrait être dans VCS. Il devrait y avoir des sauvegardes RAID complètes complétées par des sauvegardes incrémentielles sur supports magnétiques et optiques. De nombreuses entreprises ont une procédure de contrôle des modifications qui peut également dicter comment et où stocker les mots de passe et autres documents sensibles sur papier.
Steve Buzonas

@ChrisW Je ne veux pas être brutal mais il semble que vous ne nous dites pas la vérité et les mots de passe que vous souhaitez stocker ne sont pas utilisés en développement mais en production. N'est-ce pas vrai? Sinon, pourquoi vous souciez-vous d'une machine de développement ou de test et de mots de passe de développement? Personne ne ferait ça.
tiktak

BTW, dans notre entreprise, tous les mots de passe de développement sont disponibles sur papier et sur l'intranet. Parce qu'ils n'ont aucune valeur. Ils sont là parce que le logiciel que nous développons nécessite une authentification.
tiktak

@tiktak, vous avez raison - ma question est de savoir ce que faire des mots de passe de production. Je ne me soucie pas particulièrement de stocker les mots de passe de développement dans A VCS en clair. Désolé si je ne l'ai pas suffisamment expliqué.
Chris W.

7

BlackBox a été récemment publié par StackExchange et même si je ne l'ai pas encore utilisé, il semble résoudre exactement les problèmes et prendre en charge les fonctionnalités demandées dans cette question.

D'après la description sur https://github.com/StackExchange/blackbox :

Stockez en toute sécurité les secrets dans un dépôt VCS (c'est-à-dire Git ou Mercurial). Ces commandes vous permettent de chiffrer facilement par GPG des fichiers spécifiques dans un référentiel afin qu'ils soient «chiffrés au repos» dans votre référentiel. Cependant, les scripts facilitent leur décryptage lorsque vous avez besoin de les afficher ou de les modifier, et de les décrypter pour une utilisation en production.


7

Depuis que j'ai posé cette question, j'ai opté pour une solution, que j'utilise lors du développement d'une petite application avec une petite équipe de personnes.

git-crypt

git-crypt utilise GPG pour crypter de manière transparente les fichiers lorsque leurs noms correspondent à certains modèles. Pour intance, si vous ajoutez à votre .gitattributesfichier ...

*.secret.* filter=git-crypt diff=git-crypt

... alors un fichier comme config.secret.jsonsera toujours poussé vers des dépôts distants avec cryptage, mais restera non crypté sur votre système de fichiers local.

Si je veux ajouter une nouvelle clé GPG (une personne) à votre référentiel qui peut décrypter les fichiers protégés, exécutez-la git-crypt add-gpg-user <gpg_user_key>. Cela crée un nouveau commit. Le nouvel utilisateur pourra déchiffrer les commits suivants.


5

Je pose la question en général, mais dans mon cas spécifique, je voudrais stocker des clés secrètes et des mots de passe pour un site Django / Python en utilisant git et github.

Non, ne le faites pas, même s'il s'agit de votre dépôt privé et que vous n'avez jamais l'intention de le partager, ne le faites pas.

Vous devez créer un local_settings.py, le mettre sur VCS ignorer et dans votre settings.py faire quelque chose comme

from local_settings import DATABASES, SECRET_KEY
DATABASES = DATABASES

SECRET_KEY = SECRET_KEY

Si vos paramètres secrets sont aussi polyvalents, je suis impatient de dire que vous faites quelque chose de mal


9
Mais j'aurai encore besoin de garder une trace de ces secrets quelque part . Par exemple, un clavier ou quelque chose du genre, non?
Chris W.20

La réglementation et la mise en œuvre du stockage des données privées dépendent de la politique de l'entreprise pour laquelle le projet est destiné. Je doute fortement que le code source du projet soit le bon endroit, car tout testeur ou programmeur tiers pourrait les voir
Hedde van der Heide

4

EDIT: Je suppose que vous voulez garder une trace de vos versions précédentes de mots de passe - par exemple, pour un script qui empêcherait la réutilisation du mot de passe, etc.

Je pense que GnuPG est la meilleure solution - il est déjà utilisé dans un projet lié à git (git-annexe) pour crypter le contenu du référentiel stocké sur les services cloud. GnuPG (gnu pgp) fournit un cryptage à clé très puissant.

  1. Vous gardez une clé sur votre machine locale.
  2. Vous ajoutez «mypassword» aux fichiers ignorés.
  3. Lors du hook pré-commit, vous cryptez le fichier mypassword dans le fichier mypassword.gpg suivi par git et ajoutez-le au commit.
  4. Sur le hook post-fusion, vous décryptez simplement mypassword.gpg en mypassword.

Maintenant, si votre fichier 'mypassword' n'a pas changé, le chiffrement entraînera le même texte chiffré et il ne sera pas ajouté à l'index (pas de redondance). La moindre modification de mypassword entraîne un texte chiffré radicalement différent et mypassword.gpg dans la zone de préparation diffère beaucoup de celui du référentiel, donc sera ajouté au commit. Même si l'attaquant met la main sur votre clé gpg, il doit encore forcer brutalement le mot de passe. Si l'attaquant obtient un accès au référentiel distant avec du texte chiffré, il peut comparer un tas de textes chiffrés, mais leur nombre ne sera pas suffisant pour lui donner un avantage non négligeable.

Plus tard, vous pouvez utiliser .gitattributes pour fournir un décryptage à la volée pour quit git diff de votre mot de passe.

Vous pouvez également avoir des clés séparées pour différents types de mots de passe, etc.


3

Habituellement, je sépare le mot de passe dans un fichier de configuration. et faites-les dist.

/yourapp
    main.py
    default.cfg.dist

Et quand je cours main.py, mettez le vrai mot de passe dans default.cfgcelui copié.

ps. lorsque vous travaillez avec git ou hg. vous pouvez ignorer les *.cfgfichiers à créer .gitignoreou.hgignore


Les fichiers .dist sont ce dont je parlais: des exemples de vrais fichiers de configuration. Une bonne pratique est qu'il devrait être possible d'exécuter le logiciel uniquement en le renommant en supprimant l'extension ".dist" (ou mieux: copier), c'est-à-dire que vous devriez pouvoir essayer le logiciel en quelques secondes, sans avoir à le configurer pendant toute la journée.
tiktak

3

Fournir un moyen de remplacer la configuration

C'est la meilleure façon de gérer un ensemble de valeurs par défaut saines pour la configuration que vous archivez sans exiger que la configuration soit complète, ou contenir des éléments tels que les noms d'hôte et les informations d'identification. Il existe plusieurs façons de remplacer les configurations par défaut.

Les variables d'environnement (comme d'autres l'ont déjà mentionné) sont un moyen d'y parvenir.

Le meilleur moyen est de rechercher un fichier de configuration externe qui remplace les valeurs de configuration par défaut. Cela vous permet de gérer les configs externes via un système de gestion de configuration comme Chef, Puppet ou Cfengine. La gestion de la configuration est la réponse standard pour la gestion des configurations séparées de la base de code afin que vous n'ayez pas à faire une version pour mettre à jour la configuration sur un seul hôte ou un groupe d'hôtes.

Pour votre information: le chiffrement des crédits n'est pas toujours une bonne pratique, en particulier dans un endroit aux ressources limitées. Il se peut que le cryptage des creds ne vous apporte aucune atténuation des risques supplémentaire et ajoute simplement une couche de complexité inutile. Assurez-vous de faire l'analyse appropriée avant de prendre une décision.


2

Cryptez le fichier de mots de passe, en utilisant par exemple GPG. Ajoutez les clés sur votre machine locale et sur votre serveur. Décryptez le fichier et placez-le en dehors de vos dossiers de dépôt.

J'utilise un passwords.conf, situé dans mon dossier personnel. À chaque déploiement, ce fichier est mis à jour.


Ensuite, le logiciel doit déchiffrer le fichier de mot de passe.
tiktak

Eh bien, ce n'est que lors du déploiement du site que le mot de passe est décrypté et écrit dans un fichier de mot de passe en texte brut
Willian

2

Non, les clés privées et les mots de passe ne relèvent pas du contrôle des révisions. Il n'y a aucune raison de charger tout le monde avec un accès en lecture à votre référentiel de connaître les informations d'identification de service sensibles utilisées en production, alors que très probablement, tous ne devraient pas avoir accès à ces services.

À partir de Django 1.4, vos projets Django sont désormais livrés avec un project.wsgimodule qui définit l' applicationobjet et c'est un endroit idéal pour commencer à appliquer l'utilisation d'un project.localmodule de paramètres qui contient des configurations spécifiques au site.

Ce module de paramètres est ignoré du contrôle de révision, mais sa présence est requise lors de l'exécution de votre instance de projet en tant qu'application WSGI, typique des environnements de production. Voici à quoi cela devrait ressembler:

import os

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "project.local")

# This application object is used by the development server
# as well as any WSGI server configured to use this file.
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()

Vous pouvez maintenant avoir un local.pymodule dont le propriétaire et le groupe peuvent être configurés pour que seuls le personnel autorisé et les processus Django puissent lire le contenu du fichier.


2

Si vous avez besoin de VCS pour vos secrets, vous devez au moins les conserver dans un deuxième référentiel séparé de votre code réel. Ainsi, vous pouvez donner aux membres de votre équipe l'accès au référentiel de code source et ils ne verront pas vos informations d'identification. De plus, hébergez ce référentiel ailleurs (par exemple sur votre propre serveur avec un système de fichiers chiffré, pas sur github) et pour le vérifier sur le système de production, vous pouvez utiliser quelque chose comme git-submodule .


1

Une autre approche pourrait consister à éviter complètement de sauvegarder des secrets dans les systèmes de contrôle de version et à utiliser à la place un outil comme le coffre-fort de hashicorp , un stockage secret avec roulement et audit de clés, avec une API et un cryptage intégré.


1

C'est ce que je fais:

  • Gardez tous les secrets en tant que vars env dans $ HOME / .secrets (go-r perms) que $ HOME / .bashrc sources (de cette façon, si vous ouvrez .bashrc devant quelqu'un, ils ne verront pas les secrets)
  • Les fichiers de configuration sont stockés dans VCS en tant que modèles, tels que config.properties stockés sous config.properties.tmpl
  • Les fichiers de modèle contiennent un espace réservé pour le secret, tel que:

    my.password = ## MY_PASSWORD ##

  • Lors du déploiement de l'application, un script est exécuté qui transforme le fichier de modèle en fichier cible, en remplaçant les espaces réservés par des valeurs de variables d'environnement, comme la modification de ## MY_PASSWORD ## par la valeur de $ MY_PASSWORD.


0

Vous pouvez utiliser EncFS si votre système le fournit. Ainsi, vous pouvez conserver vos données cryptées en tant que sous-dossier de votre référentiel, tout en fournissant à votre application une vue décryptée des données montées de côté. Comme le cryptage est transparent, aucune opération spéciale n'est nécessaire sur pull ou push.

Il faudrait cependant monter les dossiers EncFS, ce qui pourrait être fait par votre application sur la base d'un mot de passe stocké ailleurs en dehors des dossiers versionnés (par exemple, les variables d'environnement).

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.