Isn't Blackphone to Blackphone voice and messingen supposed to be end to end encrypted? If so then it doesn't matter that the NSA has access to the GSM encryption code from the SIM since the phone encrypts the data before it is encrypted by the SIM.

They don't want writable SIMS out on the market, that is why. Of course they are they anyways just like you can buy illegal weapons and drugs but that is probably the main reason why they implemented the SIM standard to be "burn at the factory only".

Agreed, systemctl status is a big winner. Actually I think that in a few years time most admins will warm up to the idea and wonder what all the fuss was about.

I agree that binary logs is not something that I fancy either. I do however understand why he went that way since he want's to enable meta-data to the logging and also I must say that the log search in RHEL7 is lightning fast compared with grep and that it's nice to issue a "journalctl " and get all the syslog aswell as all the stderr and stdout from combined in one place.

Actually that would have been a great thing considering how horrible the EventLog in Windows are. Something like Journald would be heaven in comparison. And the people who compares the two have obviously never programmed against either.

The thing is that they cannot beat it with facts because the vast majority of these people wouldn't know systemd even if it hit them on the head. I bet a large percentage of them also isn't even Linux-users to begin with.

+1

They would need that anyway since each new ip would add another row so it's probably more that they wrote a single image to all devices instead of autogenerating a new ssh key upon first boot.

They probably will but ssh will force you to manually remove the key from the known_hosts file if the key doesn't match, atleast openssh does that.

No they cannot, they can pretend to be the device to some user though without ssh complaining that the key is wrong. If they use the same ip and if they somehow can get between the user and his router.

You seam to talk about something complete different from what the article is about. This is about a web store storing end users passwords in clear text in their database, not your internal system for employees or what ever. For a web store there is no reason what so ever to use the customer provided password for anything other than authenticating the user for the web service, all other access deeper in the system should use credentials set up between these services.

And even for you set up there is no reason that some deep back end have to use the same password for user X than user X typed in when accessing the web service, if you must need per user passwords inside your system then let the system auto generated credentials upon account creation for b2b authentication.

Yes failing to properly validate that first warning is one really nasty way to open up for a MITM. Which is why when I built a competitor to Amazon EC2 I made the newly started instance to upload the ssh public key to the meta-server so customers could verify that the warning message matched what they could pull from the web service (always curious why Amazon never thought about that) since one doesn't have physical access to the server when running in "the cloud".

Didn't stop Snowden though :)

The password is sent over the encrypted channel that ssh sets up so it's never sent in clear text as in say telnet. Then of course no one is using passwords since everyone should be using public keys instead anyways.

A fresh install of SSH will not just let anyone in, by default you would need a password which with SSH is never sent on the wire. Curious though who sets up something like SSH remotely, how do you connect to that machine before ssh is set up?