HN user

precurse

36 karma
Posts0
Comments20
View on HN
No posts found.

Yep, me too. I have Thunderbird running in the background essentially as an email backup, but I wind up using the web version more. However Thunderbird and Bridge work extremely well that I forget they're running in parallel.

I'm a recent Google GSuite refugee, so it's hard breaking the habit of web based mail I suppose.

Yep, same. After this last G Suite fiasco, I finally moved my domain off Google onto another host that I pay for. It's nice to know I'm supporting a platform that cares more about privacy than Google.

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.

They won't even create a fix for their software after blatantly disabling TLS server validation in their FortiSIEM product: https://packetstormsecurity.com/files/154702/Fortinet-FortiS...

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.

I agree with most of the article. However, what I do disagree with is how they lump "security experts" into a single category:

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.

Is it though? In most installation guides I've dealt with they recommend disabling it since it can cause random issues. i.e. The Percona XtraDB install guide.

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'm in the same boat as you. I use a work Chromebook at home and new MBP with touchbar shudder at work.

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.

Yes, some devices are getting more difficult to repair. However, Microsoft and Samsung aren't the ones lobbying to make it ILLEGAL to fix device.

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.

Apple isn't perfect either. I'm not trying to defend Google, but Apple is going after the right to repair and trying to make it illegal for you to repair your own device, let alone 3rd parties to.

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?

LE certs can still be used in those cases. We use LE extensively for the (somewhat critical) project I'm on. We centralize all certificate creation from our deployment server(s), so that we just push the certs out when the servers are built.

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 :)

Neat concept, but there's no cost to running your own internal CA and having MongoDB trust that instead. Since you're already likely going to be running automated tools to deploy MongoDB (I assume), you can generate your own certificate/key pair then. This is how we do it where I work.

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.

In the license file provided in the .tgz microcode file, under 3. Licensing Restictions section:

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.