Usually `.env` files are sourced into your development shell and also ignored by `.gitignore`.
The problem with `.env` files is that you're leaving credentials unencrypted on disk and it's easy to leak these files during screen sharing and with multiple projects there will eventually there will be so many secrets spread/sprawled everywhere that you lose track of what credentials are being used and what are expired. You want to be able to inject the required keys only when needed and leave no trace behind when not needed.
We are still working out the kinks but I expect that one should be able to easily do `. <(polykey secrets env project-vault)` in whatever development shell you have, perhaps even reference a schema for expected keys.
Yes, you are right to point this out. We are dogfooding Polykey in our own company's operations, specifically integrating it into all of our team member's NixOS development platforms with the control plane beta PKE (Polykey Enterprise).
Using Polykey in the CI/CD situation as you point out in your links is actually one of the major complex usecases we designed Polykey for, however it's actually quite a complex problem domain. We expect to do a sort of "painkiller" phase 1 first where PK is used as the network for sharing secrets, and then a subsequent "vitamin" phase 2 where secrets are no longer shared at all, because authority is delegated through trust federation.
Right now PK is a decentralized secret sharing system (every agent is a P2P node), so there's no well-known trust anchor to form a trust federation via OIDC. However once we have PKE ready, then we plan to enable OIDC customer portals within PKE following ideas from https://openid.net/specs/openid-federation-1_0.html (e.g. yourcompany.enterprise.polykey.com). This requires a more sophisticated policy-logic system integrated into each Polykey node's sigchain, atm we have work in progress for public/private network segregation.
In our internal documentation, I have a diagram of how PK would integrate into a CI architecture, just haven’t shared it publicly yet. I’ll try to get it out soon. Let me know if you’re interested in more details!
The problem with `.env` files is that you're leaving credentials unencrypted on disk and it's easy to leak these files during screen sharing and with multiple projects there will eventually there will be so many secrets spread/sprawled everywhere that you lose track of what credentials are being used and what are expired. You want to be able to inject the required keys only when needed and leave no trace behind when not needed.
I wrote about this in our documentation for Polykey: https://polykey.com/docs/how-to-guides/developers/developmen...
We are still working out the kinks but I expect that one should be able to easily do `. <(polykey secrets env project-vault)` in whatever development shell you have, perhaps even reference a schema for expected keys.