erglkjahlkh

In fact that is why you even nowadays see "SELinux must be disabled" in application manuals. The early SELinux iterations really broke all the applications, and many people never took a second look at the technology. 9/10 of the application vendors that recommend disabling SELinux really don't do anything that would hit a targeted policy - the SELinux is already practically disabled for them. They just destroy the protection for the other software in the system...

Most common tweaking tasks can be found from booleans, and extra tweaks are easy to accomplish the help of audit2allow. However it baffles me to notice that audit2allow is not part of the default installations. It is a life saver that makes finding out why SELinux doesn't allow something really fast and easy.

I am not saying that he is correct, I am just interpreting!

Many organizations are mandated (by statutes etc) to use elliptic curve based cryptography already. It is not because RSA is broken, but because the key sizes would have to be uneconomically large.

The key size requirements are picked based on the advancement rate of technology (mathematics, calculation power / price), and the time the data should stay protected. Many security related standards aim for several decades, and for RSA key sizes that does not look so good.

If the system is not already in wide usage, rolling out a major protocol that does not contain support for ECC at this time is a very, very bad choice. Many organizations have simply to disable it already because it violates the requirements. (Oddly I have seen being not encrypted not violate anything, because "that's the way DNS is"... Go figure)

For instance NFS is pretty poor if your use case is serving shared network directories for workstations (not really great with complex ACLs), or if you require proper authentication for the resources (the Achilles' heel of NFS - where's my kerberos support?!?!!). You might be better off with CIFS.

As the other comments already pointed out, there are several alternatives for several needs. Performance alone should not guide your selection.

I'm not talking simple tooltips, I'm talking about real components. Sencha's tree.Panel comes first to my mind: http://docs.sencha.com/extjs/5.0/5.0.1-apidocs/#!/api/Ext.tr...

It has extremely powerful feature set (based on the other features of the framework) out of the box and you can very fast switch your focus on other things besides re-implementing the wheel.

I simply haven't found some of these things as simple libraries. They nearly always come within complete frameworks, because they have had to implement a lot of stuff that really just requires other features from frameworks. And, no, I'd rather not spend a year implementing that feature set.

If you want the best with insane price level, buy into Power/AIX. If you are not really sure, please don't. You need to train administrators (with larger setups) - or prepare to shell in a lot of money, the hardware contains nasty licensing surprises, the hardware is rather expensive, and so on. When you get it running, it's insanely powerful indeed, and the platform itself nearly never screws up (if you tested properly for Monday parts), and the virtualization is insanely good in practice.

Some potential customers have bought Power/AIX, some not. The ones that did are still years after customers, and to my knowledge pretty happy. I believe IBM is actually gaining customers. Slowly, but they are. Those that made the choice knew what they got into, and are not going to change their views.

On the other hand, nearly every attack against passwords is non-targeted, software trolling for matches with word lists and such. A user of qwertycard is paradoxically safe, especially as single password (from for instance hacked database) does not contain telltales of being generated by substitution cipher.

In order to be in danger someone would have to either do some mathematical analysis, someone should have already tools looking for substitution ciphers, or someone should set up some application (scripts, whatever) to look for substition ciphers and break them.

Now the crucial part: No one bothers. Typically almost 9/10 of the targets use the same "catdog123" password on every site. They will be used because it is less work.

Unless you are in a risk of targeted attacks, these cards actually can improve your overall security, even despite the flaw in logic. (Which could be mitigated by the way, there are several ways to that.) In other words, non-geeks can benefit from this. My mom could.

Imagine someone breaking into service provider's database, acquiring all the keys. That couldn't surely happen, could it?

There are so many tools supporting it properly, and many of them are extremely hard to change (especially HSMs) because there are actual dependencies, that I wouldn't bother.

The problems are mostly in SSL & TLS protocols, not in the certificates. We should get a new alternative that would be designed to be easily implementable, and it should get proper reference implementation (with proofs of correctness, which by the way are available for X509... That's the only part that is verifiable afaik).

That being said, it is well known that Golang's present GC performs poorly. It presently fails to free memory in certain cases, and has pretty high overhead. There is work done on improving the GC to be fully concurrent, but that is still probably still 2-3 major versions away.

Programming languages should be kind of boring, and support the average developers' work. That is why Haskell will ultimate fail and fade away - most of the developers on this planet are simply not skilled enough to touch any of that stuff. Attempting to add all Ninja concepts to a language will just lead to a massive failure.

Go does a very good job on forcing even the most average developers to reach surprisingly succinct and elegant solutions. However, the lack of generics really forces in some situations to either use the reflection or stop being very DRY or elegant. Go wouldn't have to implement full generics to fix that. Just adding something similar to what interfaces are to methods for variables would do, without the rest of the moving parts.

Presented by Spiegel are internal services that are designed on purpose to be more economical. They exploit more bad implementations. It doesn't really matter as long as the dirty tricks get the work done.

Also, NSA seems to troll for targets from the vicinity of their targets of interest. It is again more economical, and can be just as revealing. The risk there is that the broken target has nothing of use. The real movie style "let's break the encryption keys" stuff is done for sure targets when they get the extremely rare high value target on platter.

Accidentally disregarding known information-security vulnerabilities and exposures may lead to dire consequences. Tracking CVEs reliably requires great amount of work. Cvesync assists in previous by synchronizing new CVEs to an issue management system. After that the workflow included within issue management system can assist in the analysis, mitigation, and patching.

Operating like that you can make even hydroelectric power station extremely deadly, and kill a lot of people.

Why bother cracking RedPhone when you can just trigger something remotely on the completely unaccredited radio chip, or the SIM, or the OS platform itself. A modern phone does not have one operating system, but 3-4 and they all can - after you crack one - ask services freely from others.

The whole architecture of cellphones is so broken that installing RedPhone and thinking someone with resources can't do anything about it is plain laughable. Yes, it drops casuals and non-targeted attacks. But targeted? Never.

They might as well XOR'ed the data, but opted in for RC5 for some reason.

OAuth and alike might be, but when you work with internal users Kerberos is much much better. Also for web services because GSSAPI/spnego stuff just works.

By removing kerberos from base setup openBSD people have once more moved towards irrelevance outside their own closet setups. Kerberos is the only really working method you can use in corporate setups for large amounts of users and achieving SSO. When it's not in base setup, it's just easier to install any decent Linux distro, and skip openBSD. That as market placement decision was yet another major blunder from openBSD folks, and still they wonder why their donations have dried up the last a few years...