You can use the powershell command Add-MPPreference -ExclusionPath[0] and ship a script with your app if you want. I do the same for Terraform providers - whenever a new version comes out, for a time the process can be randomly killed as I suppose a process that spawns a child process that starts talking to lots of endpoints looks somewhat suspicious.
I'd make it a pluggable middleware with a document on how to implement your own and provide a reference configuration that uses something like Vouch [0] which will redirect the user to another identity provider.
You could also provide another implementation that implements Cloudflare's zero trust authentication [1].
In other words, I don't think I'd want to actually take responsibility for authentication these days and use an authenticating proxy. The less security infrastructure you have, the less there is to go out of date.
You can always start with this approach and then implement your own built-in user directory later.
One of the techniques for a voice assistant to distinguish its own voice from background sound is called a Fourier transform, although I expect that the state of the art in this area also includes some other techniques and research.
If you've used one, you might know that you can easily talk to a smart speaker even when it is playing very loud music, it's the same idea.
Companies can quite happily hold two opposing viewpoints when it suits them. Apple's products usually have some kind of pleasing consistency but that doesn't mean their corporate dealings have to be.
In a similar vein, a startup will be very happy to talk about how valuable it is, except when it comes to talking to tax authorities, whereupon suddenly their shares are borderline worthless.
Eh, this is at least a little different. Startups talk themselves up to investors where they need to convince the investors that they will be really valuable at some point in the future. This is compared to tax authorities who are only concerned about current value, which is often essentially zero when it comes to startups.
This is relevant to a discussion I am having at work right now. I am not a fan of using a templating language as such to generate string templates, especially for a whitespace sensitive language.
I would rather use Terraform's Kubernetes or Kubectl module for this. Are there any pros or cons I should consider?
I think one of the key things I like about it is that Terraform will show me what it plans to change whereas Helm doesn't (last time I checked)
The kubernetes provider, and kubectl works, but its not the nicest way of making changes. Its slow, quite clunky, and its not particularly intuitive. If your just getting started, and you know terraform its ok though. Its useful to bootstrap gitops tools like Argo or FluxCD though.
Helm diff will show you a similar diff to terraform. Running Helmfile in CD isn't a bad move, its really simple, and its a pattern that is easy to grok by any engineer. I think this is still a valid approach in a simple setup, its what some people call "CD OPS". It's a push model instead of pull, and there are downsides, but its not the end of the world.
Ultimately, at scale, i think gitops tooling like Flux and ArgoCD are some of the nicest patterns. Especially Flux's support for OCI artifacts as a source of truth. However then you will venture into the realm of kustomize, and much more complex tooling and concepts, which is not always worth doing.
Cons: The provider tries to manage its own state, as terraform normally does. This makes it slow to diff and the state often get out of sync with what is really in k8s. When it does, it fails loading the manifest during diff phase, so you can’t apply, even if all you want is to overwrite.
The diffs are very noisy to read because they show every possible attribute, even those you didn’t write.
The ready-made resources can some times be a bit behind on versions but you also have a raw manifest resource as an escape hatch if you depend on bleeding edge
Pros: The templating capabilities are fantastic, because it leverages terraform. Bye bye string templates. This also makes it easy to use values from other data sources.
YAML is just some data, like JSON or CSV. Ask yourself whether you'd use a third-party JSON templating or CSV templating tool, or whether you'd use your shop's language of choice and write a program to spit out the generated data.
You can also save yourself a step by just spitting out JSON, which is valid YAML.
every time I hear someone suggest such a thing, I remind them that now you have two systems who believe they own the state of the world: .tfstate and etcd and let me assure you that no matter how much our dumbass TF friend thinks it knows what's going on, etcd wins hands down every time
that's why I strongly suggest that if anyone is a "whole TF shop," they go the operator route, because trying any lower level management is the road to ruin
Terraform wants to be the only thing that owns a K8S object, but the way things work in reality is you have a dozen things that want to write back to this attribute, or that overwrite objects in other places, etc, and you're constantly fighting with TF about this or that triviality.
> Obviously, this would be less convinient and wouldn't sync between devices. But would do the job.
Seems like you answered your own question. While it is less secure, my password safe is synced across all devices. I can also easily share passwords with my family members and I can assist them with lockout issues. I don't think there's a nice solution for this with Keepass.
Also, a typical implementation is that the decryption is performed on your device. I don't think you send your key material to the provider but I don't know about all of them.
It is certainly a "keys to the kingdom" issue as you noticed, and I don't put 2FA reset credentials in the same place for example.
I love the idea, unfortunately having read a few of these contracts (albeit not for a space so large), they do specify what the premises are to be used for and what they should not - I read one which specifically mentioned that paintballing or adjacent activities was not allowed, which makes me wonder if there was a story behind that. It would be very easy to terminate the lease for breach of contract sadly.
The two came out at roughly the same time and for the first few years it wasn't really obvious which was better.
Personally, I chose Mercurial to start with, because I liked the Windows tooling available and it felt a lot more like Subversion, which is what I used previously.
However, Git won the mindshare war in the end, so I moved over to that.
Happened the SAME thing to me. Mercurial felt more natural than git. Back then, Github allowed you to choose the VC and Mercurial and Git were available, I'd always choose Mercurial. I was also using Google Code that allowed for mercurial as well.
Oh that's right - I'd forgotten about that april fools joke that wasn't. It was just client compatibility right - the backend was still git from memory?
What I mean was that it wasn't like Bitbucket where you chose whether you wanted git or hg for starting your project.
The Xen Project chose Mercurial to replace Bitkeeper (the proprietary but free-as-in-beer-to-open-source-projects-for-a-while VCS that Linux used before it became no-longer-free-as-in-beer) as well. There were things that were nicer about it; but in the end it just made more sense to move over to git.
That was over a decade ago, however; I'm actually pretty surprised it took Mozilla so long to switch.
12 years ago I decided to try using Mercurial for tracking history of my plain text notes. I chose Mercurial for it's supposed better Windows support. Turned out that it couldn't work with unicode filenames. While git could.
After all the years, do you think mercurial still offers tangible benefits in terms of versionning workflow ? faster operations, more extensibility, things that are somehow only possible in hg and not git (or way too hard in git)
I'm a happy git user but I'm really curious about losing good ideas from other tools due to mindshare.
I now haven't used Mercurial in about 8-10 years or so. However, I recall enjoying the workflow a bit more, and I did like how commits were explicitly linked to branches as opposed to branches being effectively pointers to commits - it was nice to find out the original branch of any given commit.
However the killer feature of Git is the ecosystem. I was always having to do lots of custom work to get Mercurial to work with CI providers, whereas Git just worked and had first class support. It was clear after a while that our team would always be outsiders if we continued down that path, and there wasn't enough of a compelling reason to stay with Mercurial.
[0] https://learn.microsoft.com/en-us/powershell/module/defender...