precurse
I'm a recent Google GSuite refugee, so it's hard breaking the habit of web based mail I suppose.
And my contingency plan if I can no longer self host, is export from one of my devices and import into the cloud version of Bitwarden. I don't see myself needing to do that, but you never know.
Then, if you've setup a new email account with another provider, you can connect using IMAP and copy your emails that way.
Plus, it lit a fire under me to rely on Google services less and less. I had a second Google One account that I stopped paying for as well, cause f them.
You need to setup an "App password" on your Google account. Then, when you create an alias, you enter smtp.gmail.com and your app password credential as the smtp server.
Here: https://support.google.com/domains/answer/9437157?hl=en
They use the "-k" curl flag throughout their code (disabling ALL certificate validation), since I assume is to make initial configuration easier. Rather than fix this going forward, they created a workaround document which all new and existing customers need to follow to secure their setup.
Computer experts like to pretend they use a whole different, more awesome class of software that they understand, that is made of shiny mathematical perfection and whose interfaces happen to have been shat out of the business end of a choleric donkey.
I'm sorry, but there are vastly different grades of security experts. Security experts make Kali Linux. I'm pretty sure everyone runs their user as root despite it being created by security experts.
Now, look at the OpenBSD developers in comparison. Sure, bugs are found as they inevitably are, but they make it very difficult to take advantage of bugs that might be disastrous on other operating systems. They use privilege separation throughout their operating system (and packages if possible), announced recently their way of making ROP-chain exploits basically useless, and relink their kernel any time it's booted so that no two instances are alike (even if it's the same version on another computer). Using defense in depth is key. Unfortunately it's easy to talk yourself up in this field and not walking the walk.
There's a reason OpenSSH is such a highly deployed application and yet isn't constantly having RCE bugs. Sure there are bugs (as all software inevitably has), but there are definitely different degrees of security experts that the article fails to mention and lumps them all in one bucket.
I find that it's way too complicated of a layer that most people can't/won't learn. Compare this to the OpenBSD pledge and unveil which doesn't get in the way, and there's no way to disable them.
If you make something overly complicated, with the ability to disable it all too easily, then it won't get used.
I love how "updating" the Chromebook is a simple restart. It's quite literally seconds to be back to where I was previously before the update.
I keep putting off OSX Updates since they can sometimes take 10-30 minutes and the machine becomes unusable during that time.
Apple has sued over people taking displays that were still good, but just needed the glass replaced. This is a trivial repair and has been done forever in the IT industry. To the car analogy: it's like replacing the windshield and selling the vehicle. Then Honda sues you because the Honda logo is still on the car.
Article: https://motherboard.vice.com/en_us/article/a3yadk/apple-sued...
This has nothing to do with security and is totally over Apple wanting full control over a device that someone purchased with their own dollars. To say it's to do with security is asinine.
So if you're someone who respects your right to repair and won't pay for Apple products, and the other option is an advertising company, what options are there left?
Doing it this way means we don't rely on the LE servers being up all the time, since we renew at the 1 month remaining point. If they're down for a day two, they'll just renew after they're back up. It also means our loadbalancers don't need access to the DNS system to handle the DNS-01 challenge required for wildcard certs :)
One of the big issues with generating the Let's Encrypt cert on demand is that if the LE API servers are ever down, you won't be able to create a cert.
> All right, title and interest in and to the Software
> and associated documentation are and will remain the exclusive property of
> Intel and its licensors or suppliers. Unless expressly permitted under the
> Agreement, You will not, and will not allow any third party to
> (v) publish or provide
> any Software benchmark or comparison test results.
It works very well from my experience.