<@U7QP20JQH> and <@U6EFFT5FG>, re: the build pipel...
# core
t
@seph and @alessandrogario, re: the build pipeline, I double checked that the Gist I made previously is good, it still more or less looks like the steps I follow to produce the signed packages. I'll update it with my test plan also: https://gist.github.com/muffins/7925e8bf8aed3230e82eb0f67f379389
s
I think I have a slightly older version of that in https://gist.github.com/directionless/767825510afc3cce99dfeb1d4eadb67a
t
Ah, yeah probably, I did a few updates this evening
a
This is great! Thanks šŸ™‚ I am integrating this in the signing workflow
Turns out that the Windows signing process seem to be the most sane one
s
I wouldn't go that far
a
it seems to be a simple call to signtool.exe regardless of target (.exe or .msi) šŸ¤”
s
Windows code signing, natively, uses signtool. Poorly documented, and it offers the promise of power and plugins but the reality is ugly. And I think you have to be at a console -- I can't get signtool to work remotely
Apple is basically the same. Codesign is trivial, with similar limitations and annoyance. (Notarize is a separate beast)
a
Ah yes i was also considering notarization
s
Other than the async part, it's pretty simple.
Oh. Unmentioned here is windows smart screen reputation. This part is horrible Windows code signing is based on easy to get x509 certs. This means malware authors have them too. Microsoftā€™s ā€œsolutionā€ to this is to add reputation to the smart screen checks. If you donā€™t have enough reputation, when you exec things, you get an extra ā€œare you sure you want to click thisā€ link. Reputation may be build by buying an expensive EV cert (which requires hardware HSMs). Or by having an unknown number of downloads of a regular cert.
Thereā€™s some indication that you can use cloud HSMs, but thereā€™s a lot of poorly documented ground,
a
I am currently using a simple self-signed cert; I am not sure how we are going to proceed here
I think Windows is almost ready, then it's macOS time
and after that, we'll need keys
s
I expect weā€™ll buy a standard cert
šŸŽ‰ 2
a
Do you happen to know what kind of key we are using for Linux?
s
Pretty sure we have a gpg key that Teddy uses. Itā€™s in 1password
a
i'm assuming we are going to rotate it, can you become our keymaster? šŸ˜„
s
I donā€™t have any plans to rotate it.
a
is that key personal or dedicated to osquery?
s
No clue! Letā€™s see
Iā€™d assume itā€™s a dedicated key)
a
if it's personal it may not be the best to make it available through the CI
i think i had access to 1password, but it was on the other laptop
s
Itā€™s key 1484120AC4E9F8A1A577AEEE97A80C63C9D8B80B Which is osquery@fb.com
šŸŽ‰ 1
We could rotate it, but šŸ¤·
Iā€™d say use a self signed key, and weā€™ll swap it out later?
a
oh yeah, I'll use a self-signed key for now
I was wondering what the next steps are when we need to start
seems like we have a plan for all three keys!
s
We should check with Nick for windows. I donā€™t know if we want to use his, or buy anew.
Long term, obviously buy. But maybe thereā€™s an argument for something else.
For macOS, do you know what format that key should be in? And where I should upload it?
a
macOS is where I'll need help the most
I was able to run codesign and do the notarization in the past, but for the keys I always had to log into Xcode and ask it to download them locally through the UI
s
I wonder if I should iterate on a github workflow.
a
i would appreciate a lot to get some help on the macOS side!
s
I suspect we need to find prior art ā€” my experience so far is that this all requires a console login, else the keychain stuff is weirdly locked
a
your go code is way cleaner than my hackish bash approach
s
Thatā€™s why I wrote go šŸ˜›
Looking at secrets ā€” github supports repo level secrets, and also org ones, And it looks like the org ones need to be opted in for repos
That makes me think our secrets should be org level, and then only exposed to this repo?
a
Are those secrets going to be shared to multiple repos?
s
No idea!
But it feel like an okay pattern since we might move this code around
Iā€™d feel less okay if it wasnā€™t selectable how it was shared
https://github.com/osquery/osquery-codesign/settings/secrets/actions is org level. Iā€™m not even sure you can see the contents outside of the org management panel and the workflow jobs
t
The only argument I'd make for continuing to use mine is what y'all have already uncovered - my rep is high enough that we don't get flagged I don't think, so I'd be happy to continue using mine. That being said we'll inevitably need to switch over to an osquery based Windows cert anyway, so might as well start building that rep now šŸ˜›
Sorry for the delay in my response!
Lemme know what y'all wanna do either way!