Sae5waip's comments

Or not.

0, in a suitable color space.

> If this is what EA is doing then they had better have a really good explanation.

Or?

The problem with S/MIME is that it is strictly hierarchical. That already hasn't worked well for TLS.

The aim of email encryption is in a large part to prevent government-level parties from reading the emails. It doesn't really make sense to then go back to a system controlled by the very same parties.

OpenPGPs web-of-trust model seems more appropriate.

But both approaches share a significant number of problems, so...

Here are some problems, from the top of my head, in no particular order:

  - Subjects can't be encrypted.
  - Encrypted mailing lists are complicated. Do you reencrypt in the middle?
    What software do you use? The mailing list manager you use right now probably doesn't support it.
  - Enigmail still doesn't support storing e-mails decrypted*. As a consequence, full-text search doesn't work.
  - There's also S/MIME.
  - Theres no software to manage public/private keys enterprise-wide.
  - Legitimate server-side email retention requirements for enterprises
  - Many people are quite alright with "most other people won't be able my email; maybe governments can".
  - Most emails quite simply aren't that important.
  - How do you deal with lost keys?
  - Webmailers
  - Often, as a sender at a company, you can not afford to inconvenience contacts.
  - No easy way to synchronize keyrings.
  - Server side spam filtering not possible
  - Out-of-office auto-forwarding
  - The other side uses gmail.
  - Your mother keeps asking why you aren't on Whatsapp.
  - The "metadata" (who mail whom? when? how long are the emails?) is quite telling.

Please solve all of these.

Sorry for the unreadable list. Thank pg for the shitty markup format.

As a German, I feel very much the same.

Because modern configuration management tools like Ansible (or Puppet, or Salt, or whatever) allow you to do more things more easily.

Also, because Bash is a particularly horrible language. I have a lot of experience writing bash scripts, and I hate bash.

HN is a YC marketing tool, it pays for itself quite easily.

The article has nothing to do with Snowden. At all.

Yes, but it's easier to teach admins to never use "PermitRootLogin yes" "because it's bad for security" than to teach them to never use weak passwords.

Automated 0-day attack: fair point.

Though direct remote code execution is probably much, much more likely than authentication bypass.

@Passwordless sudo: Because then you have effectively made your user root, and compromising your user account is enough to get root access immediately. If you do that, then why have a seperate user at all?[3]

@Partitions: Seperating /home and / prevents normal users from filling up /. (And if you put both on LVM, you can grow them as needed.) Yes, I've only had this on some of the servers I've run.

@Impractical: it's one additional command for something I do quite often[4], and I still don't see the benefit (reminder: I fully agree with never using "PermitRootLogin yes").

[3] Granted, it does provide some context seperation in the sense that if you want to perform an administrative task, you have to explicitly use sudo. But it doesn't increase security, and it offers no advantage over "direct root access + normal user account".

[4] Not just scp, but also things like "less /var/log/messages" or "git clone root@host:/etc".

And again: what does "PermitRootLogin no" gain you over "without-password"? Why restrict it for no additional benefit?

tl;dr: "disallow root login entirely, everything else is bad" is cargo culting.

I said "impractical", not "impossible". Of course I can use sudo. But it's more work. I require root access a lot. It adds up quickly.[2]

And I hate typing passwords/passphrases. In fact, many of my passwords I can't remember. I've got an SSH agent for that, which reduces passphrase entry to yes/no (tab-space/space, actually).[1]

Also, I prefer my normal user account not to be a sudoer at all.

Besides, please consider that disallowing root access actually only gets you protection against root password guessing anyway. The "stolen key + passphrase" scenario in a sibling subthread is so absurd I felt the urge to bang my head against my desk. Sudo won't help you there either.

[1] Now please don't suggest "passwordless sudo".

[2] And there is another inelegance: /home is usually on a different partition than /, so your way will involve an additional copy. If /home is even large enough to fit that file.

Did you ever stop and think about this or are you just repeating something you read on "Hacker""news"?

Getting by /without/ direct SSH root access is often impractical (think about scp), and without-password is a secure way to have it.

Also, the more people know about "without-password", the less people will set PermitRootLogin to "yes".

Because then root login would be disabled entirely. With "without-password" SSH-key based login is still possible (and no, that's not much of a security risk).

Electrically powered multicopters can carry DSLRs quite easily. If it's supposed to carry expensive equipment, you'll want to use a hexa- or octocopter though.

Of course multicopter flight times, especially with payloads, are problematic.

Wikipedia is an encyclopedia, not a company index.

I don't. So is mine, but resizing it for each individual website is unnecessary work. And some websites have a legitimate need for a wider format, so you can't even say "all websites should be like this".

Anyone want to host their mission critical project with a team so small that individual employees have to be on call 24/7?

If the company requires more than what can be done in a 40-hour work week, it should hire more employees.

That's precisely why you only use subkeys in daily life and only use the root key for keysigning (and ideally store it safely and offline).