On 02/20/14 17:03, Michael DeHaan wrote: > "and other > members in the community, as well as Ansible's leader Michael DeHaan, > had agreed with that" > > I am really not happy with the tone here.
I really had no intention to have a specific tone that would make you unhappy. I just mentioned your name because you are Ansible's leader, the one who makes final decisions, and nothing is wrong about that. What surprised me was that, while you were positive with what me and other people in the list were concluding about the requirement to have encryption at variable-level and not at file-level, it ended up that you choose not to make things that way. > > ansible-vault was designed from the result of lots of threads about > this, as well as making it as simple and usable at it could possibly be. > I am referring to a very specific and expressed by a few people requirement: Have variable-level encryption instead of file-level. Please take another look at this discussion: https://groups.google.com/forum/#!searchin/ansible-project/secret$20variables/ansible-project/jAX8N3RMr-I/htkn74Zoxe4J In case you don't have time to pass through the whole discussion, I summarize the positions that were in favor of a design with variable-level encryption below: JP Mens: He was the one who started the discussion and must be the one that, at that time, spent the most time thinking and even actually implementing his proofs of concept Mavimo: He was the first to mention the tottaly crypted files at his "Cons" section of his git-crypt-based solution Dave Cottlehuber: Agreed with Mavimo Me: also expressing the reasons for a variable-level encryption approach (meaningful diffs for history, auditing, troubleshooting, etc.) Vincent Van der Kussen: Agreed with JP Mens's summarization of design requirements Brian Coca: suggested his own version of a YAML interpreter hook for variable-level encryption Michael DeHaan: you were positive and suggested a YAML encryptor algorithm for encrypting "leaf" values of YAML data structures A lot of voices, some being heard by some great contributors I know of (JP Mens, Brian Coca). Also it seems that the implemented design for the actual encryption/decryption interface is not very different with the one you had suggested then: > ansible-vault agent <get prompted for password> > ansible-vault create <YAML FILE> # spawns $EDITOR but on save will > encrpt file > ansible-vault edit <YAML FILE> # spawns $EDITOR ... if the file is > unencrypted, just edit it like normal YAML, otherwise edit as > encrypted file, on save, re-encrypts. Be careful of temp files of course > ansible-playbook ... # works fine because we started the vault agent, > but transparently works on all files as unencrypted. Magic code lives > in utils.parse_yaml_from_file. In fact, I think that you were the only one in that discussion who talked about a whole-file encryption interface. So, it's questionable how much attention was given to the "variable-level vs file-level encryption" discussion. > If it doesn't fit *your* specific needs, that's unfortunate, but I'm > also exceptionally happy with the simplicity and interface of this design. > > It certaintly wasn't done to slight anyone, and I think everyone does > need to understand how hard it is to balance the needs of a half > million different Ansible users and make everyone 100% happy. > > Vault is a great addition, and if this doesn't work for someone, they > can *still* write a lookup plugin to do something different. That's a > primary reason that ansible is pluggable. > I guess that it is still possible to implement a '--leaf-only-encryption' mode option for ansible-vault without loosing the current behavior. The question is whether you would accept such an addition in the core, or you have reasons not to. And sure, even if it does not evolve to meet an IMHO important requirement, people will still find the Vault feature useful. Above all, thank you for your work. > > > > On Thu, Feb 20, 2014 at 9:58 AM, Petros Moisiadis <ernes...@yahoo.gr > <mailto:ernes...@yahoo.gr>> wrote: > > On 02/19/14 20:20, James Tanner wrote: > > We just merged a new feature called "Ansible Vault" to devel (1.5). > > Please read through Michael Dehaan's blog post about the tools for > > basic usage: > > > > http://blog.ansibleworks.com/2014/02/19/ansible-vault/ > > > > Follow the typical bug reporting process for any issues you may > find. > > > > Other notes: > > > > 1) The default encryption cipher is AES, but the framework is > > "pluggable" to encourage community contribution for other cipher > methods. > > > > 2) All files used for a single playbook must be encrypted with the > > same password. > > > > > > Please test away! > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Ansible Project" group. > > To unsubscribe from this group and stop receiving emails from > it, send > > an email to ansible-project+unsubscr...@googlegroups.com > <mailto:ansible-project%2bunsubscr...@googlegroups.com>. > > To post to this group, send email to > ansible-project@googlegroups.com > <mailto:ansible-project@googlegroups.com>. > > For more options, visit https://groups.google.com/groups/opt_out. > > In previous discussions in this list around the problem that > ansible-vault is trying to solve, I had demonstrated the need of an > interface that does encryption at a variable value level (like > having a > leaf-node-only YAML encryptor/decryptor to use Michael's term) and > other > members in the community, as well as Ansible's leader Michael DeHaan, > had agreed with that. The use case for such an interface is quite > standard: You want to commit your Ansible stuff to your revision > control > system and keep your sensitive data secret *without* destroying the > readability of your data structure (Ansible is all about data) and > *without* loosing the ability to review and audit changes (a must in > many security-sensitive environments). Looking at how > ansible-vault has > actually been implemented, it seems that the whole discussion around > that requirement was not considered at all, and, instead, files are > encrypted as a whole. What was the reason for that decision? > > It is surely an important step forward to have an official approach to > encryption of Ansible's data, but it is IMHO disappointing the > fact that > community feedback was not taken into account. > > -- > You received this message because you are subscribed to the Google > Groups "Ansible Project" group. > To unsubscribe from this group and stop receiving emails from it, > send an email to ansible-project+unsubscr...@googlegroups.com > <mailto:ansible-project%2bunsubscr...@googlegroups.com>. > To post to this group, send email to > ansible-project@googlegroups.com > <mailto:ansible-project@googlegroups.com>. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- > You received this message because you are subscribed to the Google > Groups "Ansible Project" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to ansible-project+unsubscr...@googlegroups.com. > To post to this group, send email to ansible-project@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscr...@googlegroups.com. To post to this group, send email to ansible-project@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
