On-demand, declarative-first secret management#14
On-demand, declarative-first secret management#14CertainLach wants to merge 28 commits intomasterfrom
Conversation
| } | ||
|
|
||
| #[tokio::main] | ||
| async fn main() -> Result<()> { |
There was a problem hiding this comment.
FIXME: Split, I would think about splitting my own deno implementation from things intended for my infra instead
CertainLach
force-pushed
the
push-xzkurnmtrspn
branch
from
89f2152 to
e987c6c
Compare
CertainLach
force-pushed
the
push-xzkurnmtrspn
branch
from
e987c6c to
f7d7283
Compare
| @@ -1,3 +1,3 @@ | |||
| [toolchain] | |||
| channel = "1.91.0" | |||
| channel = "1.92.0" | |||
| package.version = "0.1.0" | ||
| package.edition = "2024" | ||
| package.rust-version = "1.86.0" | ||
| package.rust-version = "1.89.0" |
There was a problem hiding this comment.
Is there a reason not to use the same version as in rust-toolchain.toml?
Even release-25.11 is currently at 1.91.1
| import: String, | ||
| // Magic values should have exactly two values to avoid pretty-printing | ||
| // as nix inline object value | ||
| __magic_marker: PhantomData<()>, |
There was a problem hiding this comment.
| __magic_marker: PhantomData<()>, | |
| #[serde(rename = "__magic_import")] | |
| _marker: PhantomData<()>, |
If I understand the intent correctly, there is no need to use weird field names if it' just part of ser-de
There was a problem hiding this comment.
This file is still full of todo!s
| @@ -0,0 +1,6 @@ | |||
| use fleet_base::primops::init_primops; | |||
|
|
|||
| #[unsafe(no_mangle)] | |||
There was a problem hiding this comment.
I would prefer it to have a safety comment referencing this function's doc / C-reference
| gc_now(); | ||
| } | ||
| let config = Config(Arc::new(FleetConfigInternals { | ||
| // TODO: Load from somewhere |
There was a problem hiding this comment.
Is this to be addressed in this or the following PRs?
| .await | ||
| .context("failed to copy generator to target host")?; | ||
|
|
||
| // TODO: Remove destdir after everything is done |
| }) | ||
| .unwrap(); | ||
| dbg!(&data); | ||
| // for v in 0..1000 { |
There was a problem hiding this comment.
Guess this can be dropped
| macro_rules! nix_go { | ||
| (@o($o:expr, $path:expr) . $var:ident $($tt:tt)*) => {{ | ||
| nix_go!(@o($o.get_field(stringify!($var)).context(concat!("getting nested ", $path))?, $path) $($tt)*) | ||
| nix_go!(@o(tokio::task::block_in_place(|| $o.get_field(stringify!($var))).context(concat!("getting nested ", $path))?, $path) $($tt)*) |
There was a problem hiding this comment.
| nix_go!(@o(tokio::task::block_in_place(|| $o.get_field(stringify!($var))).context(concat!("getting nested ", $path))?, $path) $($tt)*) | |
| nix_go!(@o(::tokio::task::block_in_place(|| $o.get_field(::std::stringify!($var))).context(::std::concat!("getting nested ", $path))?, $path) $($tt)*) |
Or, better, put the re-exports into a hidden __macro_support module to reference them with $crate
Same below
| mkImpureSecretGenerator, | ||
| }: | ||
| mkImpureSecretGenerator { | ||
| # TODO: Escape prompt/part (preferrably just use env) to prevent shell injection |
2 participants
Secret management commands replaced with interactive generators, secret generation is now nix-driven