Great article. We'll need a better integration of security tracking and handling in our containerized infrastructure soon.

You have to be a little bit careful when it comes to version numbers and matching them to security issues. Most linux distributions for example apply security patches to older releases.

E.g. Ubuntu 14.04LTS comes with Apache 2.4.7-1ubuntu4.4 which one might parse as 2.4.7 which has multiple security issues.

The article references to distribution specific vulnerability ratings so I assume they als matched those versions correctly.

Study co-author here. We did observe that it's essential to be careful about comparing package version numbers on a per-bistro basis, and there are some tricky cases such as the one you pointed out, and rpm epoch numbers as another example. I believe we handled them correctly in the study.

I like the idea. The only problem I see from a companies' perspective is that open source technology suddenly becomes costly which then makes commercial options more viable and in long term could harm OSS.

How many problems do you miss until you start debugging? Getting complex models and systems right in your head is a matter of training.

Also: How good is your documentation? The more experience you gain the more you will be able to plan ahead and build the a scaffold first before you start fiddling with details. This often leads to well documented code where the documentation always matches the code. A lot of tinkering often means that the documentation and your code won't match.

How well do you know your tools/frameworks/language? Can you start coding or do you find yourself trying out something in a REPL or a small test project before implementing it? (Note: This may vary since even quite senior developers have to learn new tools)

How well can you explain your code / your program / your project? Once again getting a good grasp at complexity is a matter of training.

Compare your code to open source projects and other code you can find. You'll see that there are always some good practices one still can learn. On the other hand becoming more experienced will make you see code and decide that there is room for improvement or you would have structured it better.

This analysis doesn't just prove the attack orriginated in China, it shows that it takes place immediately inside the first Chinese network the connection reaches on it's way into China. The second piece of analysis shows that this is the same network layer in which the network blocking performed by the Great Firewall occurs. So the great firewall and this attack are both being implemented at the same point in the network infrastructure.

I think an interesting question is how likely it is that some of the great firewall is compromised.

(It could be by some party outside of China, or by some group inside of the Chinese government that does not have an official mandate to use it for things like the Github attack)

Extremely unlikely. GFW is, ironically, considered "critical infrastructure" and is closely monitored.

Ironically? How is it ironic that a centerpiece of the he Chinese Government's control and monitoring of information is considered critical infrastructure and closely monitored by the Chinese Government?

I was saying "ironic" as this article classifies GitHub as important infrastructure. But anyway I totally agree with you.

I have been toying with reactjs a few weeks ago and this would have helped a lot to get going. Great guide!

From what I understand your created a Flash Clone to create smartphone apps (The VM, the simple programming language, it's all there). This sounds quite nice but where do you see yourself making money? On the creator's side (like Adobe did?) or on the customer's side (like the AppStore)?

I like your idea, and the vimeo video doesn't look bad BUT: You seem to make a mistake I often see with (being one myself) Dev/Tech people: Our own enthusiasm a product or idea prevents us from verifying the actual market need. Instead we start doing what we love: Building. Unfortunately the more we build the less we are open to criticism or potential customer's feedback. For this reason we start only talking to people who like our product (but aren't customers) and get stuck in a positive feedback loop that isolates us from the hard truth that we might move in a wrong direction. Wrong, not because the idea isn't good but wrong because without a market the idea won't be sustainable.

I wish you all the best guys. Revenge can be great motivator but don't fight wind mills.

A good start would be EFF's Secure Messaging Scorecard. They measured all existing solutions using 7 security features(from end-to-end encryption to open source and public reviews).

A few solutions fulfill all requirements (e.g. Telegrams code hasn't been publically reviewed while TextSecure was).

One problem is though, that many open source solutions aren't available for iOS due to issues between Apple's ToS and the GPL.

[1] https://www.eff.org/de/secure-messaging-scorecard

The EFF scorecard is technically unsound and not a good place to start. It actually caused a small controversy among crypto and security people when it was released.

To clarify, the most criticism that the EFF secure messaging scorecard had was:

* CryptoCat got a perfect rating, despite it's long history of insecurity, attack vectors, and questionable audits.

* Skype got rated more favorably then is likely the truth. It has since been corrected though.

* PGP got buried as a recommendation.

* A good number of tools were missing on initial release.

The big issue with the scorecard is the lack of rigid definitions, such as code audits. Developers will audit and review each other's code all the time. But most won't qualify that as a "security audit". So, does a security audit require a cryptographer to audit the code? A third party security agency? How in depth do audits go? Are there any standards or "best practices" to go by when auditing crypto code, or is it just a rubber stamp?

With that said, it does list (incompletely) a good set of tools that you can investigate, that you may not have heard of.

So what are your recommendations?

The problem with that report is that it's more of an assessment than a report. EFF didn't (or couldn't) evaluate or grade the technical merits of any of the chat systems. For example, a professional audit was merely a binary state - there either was one, or there was not. The results of the audit were not considered.

There will have to be a more thorough follow-up at some point.

I liked Atlas Shrugged when I read it. But I think if Dagny Taggart would see today's world she wouldn't be too happy as well. While capitalism won over communism the corruption of governments didn't die out it just became more clever.

I sometimes toy with the thought of writing a second ending to be Atlas Shrugged where old Dagny looks at our world and can't grasp what is wrong with it.

In Atlas Shrugged she didn't just rail at communism, but also at the use of political "pull" over merit to shape (distort) the economic landscape. That's still very relevant in many domains today, though I think the "Dagney's" of the world (and most hackers and other astute observers) just as easily grasp it then as now.

It's not only about the "pull" over merit as you state it but about politically established priorities that harm good businesses. Just as the US cloud business was harmed by the NSA when national security (and intl. espionage) was put above competitiveness.

Those political priorities still come from "Washington" and rule over NY (or Silicon Valley). Both cities are meant within context of the book.

And the Java Plugin as well. Outside the corporate world it's rarely used anyways (the plugin, not java in general)

Click-to-play is the best feature ever for these kinds of things - pick who you trust. I wish it were made the default.

Now that Apple has killed flash in so many use-cases, I think it would be palatable for major browsers to start forcing plugins like Flash, Java, Silverlight, and Unity to be "click to activate".

Current versions of Java more or less default to allowing nothing to work anyway.

Couldn't they create a challenge/response type authentication that proofs that liz has the private key for her public key?

Liz wants to authenticate. Keybase sends her a challenge, which she encrypts using her private key. Keybase uses her public key to verify that liz owns the private key for her public PGP key. Easy peasy.

Keybase seems to want identity proofs to be independently verifiable, which would not work with challenge/response mechanism.

Yeah, I know this is somehow the point. On the other hand it (maybe?) would be more useful if they would just verify that certain online-personas (e.g. github, pgp, blog) are the same person, which you could do.

I want to know that liz, is the liz that blogs and liz who forks on github, not necessary her facebook/linkedin/real name.

This is exactly what Keybase does.