.env files should support more file formats

Thanks for sharing this, Simon. I agree it would be very helpful if 1Password Environments could work with more file types, not only .env files. Many mobile developers use .swift templates, so having secrets added directly into those files would make things much easier. Hope the team adds this in the future.

Hello.

1. I have just started using .env mounting system.
   
   I would like to know if there is a way to access environment variables stored in 1p via one of the SDK or the CLI ?It doesn't seems like it's feasible, or at least the documentation is not clear about it because it always talk about vaults. And I don't know what is the path to access the ENV variables.
   
   
2. Secondly, I face the same issue as Simon, and would like to be able to mount any kind to file to any destination, like we do for .env files. My use case is that I have a database which is protected via user/pwd but also some certificates. Before the user and PWD were in the local .env file which is now stored and mounted via 1Password, but I still have those certificates which sensitives and are still unprotected on my HDD. Of course, I could probably find a way to get those files via the SDK/CLI - Wait, this is what I tried in point 1. And even though it was feasible, Then I still need those plain files for my database editor for example. So the ability to mount other things than .env file is really important in many use cases. I've also read somewhere that the limit is up to 10 mounted files ? is this limit per environment ?
   That would be a nice step forward but still lacking flexibility, because maybe in your dev environment you have some env variables that are for your front-end and some other ones for the back-end. For me I think the best approach is to Keep It Simple Stupid, and to treat everything as a file. A file that you can mount. Here I don't see any benefit of storing each environment variable individually, especially since as fas as I know the only way to access them from outside of 1p is by mounting them, since we can't access them via SDK or CLI. So no reason to keep them this way. Maybe there is a reason with AWS but we don't use GAFAM technlogiees
   
   
3. I find the concept of "environments" under used. Currently it seems you can enter as many variables for this environment, but you can only mount them in one .env file.
   As explained in point 2, there could be some cases where you have multiple files per environment and so currently, I don't see how it can be feasible except by creating multiple environments: 'dev-env-vars' 'dev-root-crt' 'dev-clien-key'. I don't think this approach is maintainable and is mor like a hack. An environment is semantically speaking a grouping of files, code, secrets that work together. So maybe here you could add a new tab "files" between "Variables" and "Destinations"
   
   
4. This is about another topic, but while I'm at it writing this novel:
   The issue about the limit of the "too many authentication failure" and the six ssh keys for connecting to a server is annoying. Of course the new bookmarks feature is nice, but we can't easily add a new bookmark, we need to do it from history. But if you have no history for this connection, then you need to download the SSH key from 1P, store it in .ssh folder, make the connection with -i option, and then you can finally add it in the bookmarks. Not easy. Why not permitting in the UI to add a new entry, select the ssh key and add the connection string?
   Also, annoying thing, even though you have defined the bookmarks, that still doesn't prevent you from encountering the issue if you directly connect to the server via SSH. you MUST do it via the bookmarks tab.
   Yet, I do think there are chances this can be avoided. Here is the .ssh/config file after the 1P ssh agent is configured:
   

   Host *            
                  IdentityAgent ~/.1password/agent.sock

   
   As per the man pages of SSH config (https://man.openbsd.org/ssh_config#IdentityAgent) it seems the IdentityAgent can receive parameters (TOKENS). And there is a token I find particularly interesting "%h -> The remote hostname"
   So maybe something like this:
   
   

   Host * 
               IdentityAgent ~/.1password/agent.sock %h

   Could permit your ssh Agent to receive the hostname (there's also %r for the user) and match this against the bookmarks to return the correct key ?
   
   
5. Lastly (I promise). I would love that the 1P CLI (or maybe it is not needed, just documentation) would permit to programmatically mount the .env (and others to come) files.
   The reason behind that: We've streamlined our process of developer laptop bring up, and with this we could have a new developer ready to operate in minutes because in one script, his private SSH key (stored in 1 password) will be binded to git, permitting him to clone the repositories. Once cloned, the rest of the script would mount the necessary .env and other files. then, we're just one docker-compose away from a whole stack ready to operate. A nice improvement compared to the current situation where it can take up to half a day, requiring a senior dev to assist with the setup.
   
   Regards

Similar to Simon, we would like to use Java Properties files for Android development with Gradle.
`.properties` files should be easier because they are basically `.env` files but with another extension.

Hi simonbs​ ,

Another great request, thank you for sharing this.  It is helpful to know you are using 1Password in your development flow for iOS apps. I too used to develop iOS apps and can relate to your pain. From your note, it sounds like the request is to output different types of files that could be defined by a template and then the Environments feature would replace the secrets (like you mentioned like 'op inject' does from the command prompt).

Something like this:

1) Define a template file with 1Password URIs (could be swift, could be .env, or any other format, but basically a text file)
2) Create a new environment that knows about this template file (from #1) define the secrets linking to the URIs
3) Define a destination 
4) Attempt to run a build process, that tries to access the destination from #2.

Let me know what you think.

Regards,
Phil & Team