I think you can be more strong on this point. The reality is that this *is* the mainstream. 'The Cloud' work is important, but more than important, the people doing it are *louder* than everyone else and the media coverage high since it is novel, but mainstream is remarkably little changed over the last several years.

That is the facet I find concerning, 'RTM is no big deal' statement is bad because it *should* be a big deal.

Maybe they can juggle LTS and non-LTS effectively, but they have every risk of getting too caught up in the enthusiast perspective and pissing off a lot of their users. I know a fair number of people pissed that their google apps change drastically on a whim on their phones, and it seems MS may jump to that model. That said, the pissed off users don't really have anywhere to go. The developers rule the roost nowadays and all companies are enabling new and shiny and changing and no one is being pushed to drive for a stable experience.

It would be bad form to reset the password when anyone clicked 'reset this accounts password' anyway. So until the link is followed, no action should be taken with regard to the account password anyway. This way a malicious person can't just denial of service a valid account by clicking 'reset my password'.

This means if an attacker is able to intercept your SMTP, they could still hijack your account through requesting a password reset at will, so it's not perfect, and yes some 2 factor authentication would be nice *if* it were an important site. Account creation needn't have this particular hole, just password reset.

If you didn't want to SMS, you could use TOTP (e.g. google authenticator is one implementation, but not the only one). Though either way that's something to potentially lose so it would be a suggestion option for those increasing security.

The UUID is discarded on first login. Additionally, the UUID is useless without the password/credentials.

The idea is that the user set his password via (presumably) secure https. The purpose of the random hash is so that you provide the legitimate email user a transient secret that must be used *in conjunction* with the password they had chosen (or some session cookie sent via https to avoid making them log in twice when clicking on the email).

So here the password is to authenticate that the original person that accesses the site, the hash authenticates a valid email account. Both together are required to verify the account is valid. This way someone intercepting SMTP doesn't get access to hijack account and someone without a valid email can't get an account activated.

eth0 being renamed to biosdevname and then 'consistent' device naming happened outside of systemd per se. It's one of the various questionable things that came along at about the same time as systemd, and systemd gets the blame for *all* of them, when it only brought some of it. E.g. complaining about binary logs, you can aim that square at systemd. Most of the other prominent rants commonly fired at systemd are either dbus, networkmanager, udev, or something else in reality.

The network device naming is one facet where they can't win. The ethX has problems, and so does the current state of consistent device naming (notably that if an adapter veers off into being enumerated by pci, it's probably a lost cause in all but the most extremely homogenous environment and doing those names is just causing more trouble than helping)

I agree that Torvalds isn't the authoritative god of all that makes up a distribution and as such his opinion is one to be considered, but no the only one.

Also he speaks to the biggest fundamental controversy, the log strategy/format. I agree with Torvalds, that the capabilities of systemd are interesting, but I personally find the bathwater that comes with it troublesome enough to not want it. That and how they engage with the community at times. A lot of the other gripes about systemd are more implementation mistakes that are unintended and often addresed, but this part is very explicitly intentional and counter arguments have been dismissed out of hand.

Sometimes you don't have a choice in an interoperable piece of software. In an aggresive world that tosses away backwards compat in the name of security, you'd either have to toss out a bunch of perfectly ok equipment because you *can't* talk to it anymore, or stick to outdated software to protect the investment, which may have unfixed vulnerabilities because the versions that fix things also dropped support for your needs.

All the known broken facets of MD5 have zero applicability to HMAC usage scenario. The only part of it that weakens HMAC is that SHA256/SHA512 are more computationally expensive.

If someone knows a weakness in HMAC-MD5, it's hard to imagine it would be related to any of the known broken parts of MD5, and thus HMAC-MD5's chances of being broken might not be so different than any other HMAC use of a hash.

Yes HMAC-SHA2 is the best choice now. Now it's not a good reason to go nuts over things that use HMAC-MD5 today.

That was my assumption going in. I'm saying that 'verifying that software is secure' is a complex beast that I don't think is such a trivial undertaking. I was thinking of a company that has a 'development' team and a 'security' team, which I have experience in. The security team generally devolves into effectively black box testing of a system without understanding the real purpose and potentially fishy stuff going on internally that will pave the way to future vulnerabilites. CyberUL would be in those shoes, doing largely black box testing because there is no way they could do full code audits. Sure they can probe it or demand source code to do some analysis tools on it, but the most notorious security problems have mostly been around new discoveries about widely deployed technology that had previously *eluded* such analysis that is already prevalent in the industry.

It may be good to have a CyberUL to formalize already known best practices, but I don't think it's going to get what people want out of it.

Which is quite important, since there are a *lot* of scenarios that still use MD5 (and HMAC-MD5 isn't even broken). So for things that need MD5 hashes even if it's not secure, you can still function, and for things that still use HMAC-MD5, you can still talk *securely*.

Well one, it's bad enough for a single company to have their 'security' teams meaningfully assess the security beyond the obvious. Good security really has to be ingrained throughout the process.

The obvious security issues that something like a 'CyberUL' would catch are generally not the issues. The problem is that once a new issue is discovered, the existing install base is not be updated. Either because updates are available but IT teams are slack, or because everyone has jumped on the bandwagon of using preloaded stuff baked into products that get subsequently abandoned by their vendor or the vendor just goes defunct.

For another, any US endorsed entity calling the shots for security faces a bad credibility problem. NIST is pretty well distrusted globally now, I don't know what would happen with this initiative.

The same could be said of pretty much every advancement. Guys with clubs are cowards because the barehanded guys don't have a chance. Guys with swords are cowards because the guys with clubs don't stand a chance. Guys with arrows are cowards because the guys with swords across the field don't stand a chance. So on and so forth.

Of the factors driving reluctance to engage in harming other people, I don't think giving the other guy a sporting chance to kill you is a good factor. As others have pointed out, without your own life on the line you may have the opportunity to be more careful about how you proceed. If you are in imminent danger of getting killed, you may be more likely to make hasty judgment calls, collateral civilian damage be damned.

That may be a valid concern, however that's orthogonal to the point about whether a pilot needs to be inside a craft or not.

Points can be made about how susceptible it would be to jamming attacks and such. However as it stands the statement that drones have no conscience is about as useful as saying a bullet has no conscience.

I would say no to the actually firing bit. Sure have it be able to evade and retreat or adjust flight to try to get around jamming, but there's a dangerous step to let the AI take hold of the trigger.

I know the same can be said of humans, but at least we know how to contend with that reality.

Drones with weapons aren't autonomous.