[00:04] <meena> minimal: a root cert, valid for the next 20 years…?
[00:09] <minimal> meena: well for your own (self-signed) use you can use whatever you want ;-)
[00:09] <minimal> if you're asking about policy for official Root CAs you'd need to check the CAB Forum documents
[00:12] <meena> aye
[00:12] <meena> Let's start by removing some certificates!
[00:13] <meena> cuz I'm too tired to go creating fresh ones
[00:17] <meena> meena: wait, we can't just delete one of the currently trusted certs, they're *all* deleted?
[00:22] <minimal> meena: yupe, that was why I suggested you test on a throwaway VM and mentioned curl/wget/etc having problems due ot missing CAs ;-)
[00:26]  * meena creates a snapshot
[00:36] <meena> minimal: first problem found!
[00:36] <minimal> don't keep me in suspense....lol
[00:39] <meena> minimal: if we're adding FrcccccclvlvgrufghghchhvdjbblebnjkcreublllteiceeBSD
[00:39] <meena> to the module, we also need to enable the module in cloud.cfg.tmpl
[00:40] <meena> minimal: but at least i got my setup back in order for being able to actually test this.
[00:41] <meena> also, i think I should be easily able to test remove_defaults, and reinstall it, because pkg's certificate validation is independent of the rest of the system.
[00:41] <minimal> ah, doh! let me look at cloud.cfg.tmpl
[00:42] <meena> do, I'll look at going to bed now
[00:43] <minimal> right, there's a "if not variant.endswith("bsd")" in the template, I'll change that and update the PR
[00:45] <meena> we support FreeBSD, not even dragonfly yet: https://man.dragonflybsd.org/?command=certutil&section=ANY
[00:45] <meena> and pkg puts its keys into /usr/share/keys/pkg/trusted/ so that's safe…
[00:45] <meena> okay gotta go now after the dog
=== meena4 is now known as meeena
=== meeena is now known as meena
[16:14] <esv> hey folks, when using custom data on a new deployment, is it required the shebang for the interpreter be added in the file? 
[16:15] <esv> I think it just makes sense as cloud-init needs a way to differentiate the scripts from a clound-config file, but not sure if it is mandatory 
[16:15] <minimal> esv: you mean user-data (when you say "custom data") ?
[16:16] <minimal> esv: look here: https://cloudinit.readthedocs.io/en/latest/explanation/format.html
[16:16] <esv> well, azure api calls it custom-data but if it is better known as user-data, I'd go with that. 
[16:16] <minimal> that defines the various formats of user-data
[16:17] <esv> thanks
[16:17] <minimal> for a shell script the section "User data script" says: "Begins with: #! or Content-Type: text/x-shellscript when using a MIME archive"
[16:22] <esv> thank you
=== arif-ali_ is now known as arif-ali
[20:14] <minimal> FYI: Amazon have implemented a configuration system for their BottleRocket OS that is similar to cloud-int except it uses TOML: https://github.com/bottlerocket-os/bottlerocket/blob/develop/PROVISIONING-METAL.md
[22:01] <meena> something less awful than https://noyaml.com/ ?!
[22:17] <meena> minimal: well, it works and it doesn't work…
[22:28] <meena> we have two certificate stores… most of ports software uses ca_root_nss; I'm just surprised that fetch (from base) also uses it, must be a fallback
[22:33] <minimal> meena: so what works? and also what does not work? lol
[22:37] <meena> minimal: removing all the default system worked. but I'm surprised that everything still works. because ca_root_nss is installed for some ports like git
[22:38] <minimal> meena: perhaps there is still a "bundle" file somewhere that is used?
[22:38] <meena> it installs into /usr/local/share/certs, and this is a location all ssl linked software checks
[22:38] <meena> minimal: that *is* the bundle. ca_root_nss that is.
[22:39] <meena> anyway, this is a FreeBSD problem, not a you problem.
[22:39] <meena> I'll test installing a certificate next.
[22:39] <minimal> ok, thanks. There was little docs online that I could find about how FreeBSD deals with certs
[22:42] <meena> time for you to share your script :P