Add ECC Key Support #993
Add ECC Key Support #993
Conversation
directionless
force-pushed
the
seph/krypto2
branch
from
f8ab5d5 to
b6318ff
Compare
pkg/osquery/table/launcher_info.go
Outdated
| @@ -66,6 +75,22 @@ func generateLauncherInfoTable(db *bbolt.DB) table.GenerateFunc { | |||
| }, | |||
| } | |||
|
|
|||
| // No logger, so just ignore errors. generate the pem encoding if we can. | |||
| if eccKey := agent.Keys.Public(); eccKey != nil { | |||
There was a problem hiding this comment.
I would prefer it here if the agent package encapsulated the package level Keys var and we accessed Public() or PublicKey() via a package level func.
There was a problem hiding this comment.
I can't decide.
I instinctively don't like the global nature of the package vars. But they feel vaguely acceptable here?
We'll need to pass them to the challenge/response thing, so I think we need the full Signer interface, not just the exposed Public(). And I wanted to expose both the hardware one, and the DB one.
I feel like correct would be to create some underlying struct to hold these free floating things that get used across a bunch of launcher. Like, we have db, which is created over in main, and then threaded through everything. I sorta imagine the keys similar. Which makes me think about threading an object (or, interface really) through a bunch of places. But then I balk at it.
There was a problem hiding this comment.
I updated to
var hardwareKeys keyInt = keys.Noop
func Keys() keyInt {
return hardwareKeys
}
In some ways, it's the same. But in other ways, it feels a little closer to agent being an interface. So maybe?
Anyhow, happy to keep talking about it
Co-authored-by: James Pickett <James-Pickett@users.noreply.github.com>
No description provided.