The repo's README mentions a vim plugin to highlight Unicode homoglyphs. As an Emacs user, I did a quick M-x package-list-packages, thinking I'll find at least half a dozen equivalent Emacs packages.
To my dismay, there were none. So I spent the rest of my afternoon correcting this glaring deficiency. Fellow Emacs users, protect yourself from Unicode trolls and grab it here: https://github.com/camsaul/emacs-unicode-troll-stopper
So the Untrusted CTL has an expiration of 25 hours. Your screenshot says "Did you know? ... the Untrusted CTL is updated once per day". Doesn't that explain it?
In the screenshot, it says that CTL was last modified in March. Judging by the date, I'd guess it has an expiration of 6 months after it is issued. So, it's been nearly 6 months since the daily updates stopped occurring.
Is that the time it was last modified or the time it was last signed?
The last high-profile mis-issued cert was last week, and didn't even escape the control of people who were entrusted with the CA private key. So MS might not even be manually revoking it. Before that, the last blog post on googleonlinesecurity.blogspot.com about a mis-issued certificate was ... March 23.
I would guess that it's re-signed daily, but only changes when there's an actual change to be made.
Following up: if anyone wants to poke around at the file, the download URL is http://ctldl.windowsupdate.com/msdownload/update/v3/static/t... , a CAB archive that contains a single file disallowedcert.stl. That file itself is DER-formatted ASN.1, evidently a PKCS7-signed "Certificate Trust List" (1.3.6.1.4.1.311.10.1). `openssl asn1parse -inform der -in disallowedcert.stl` reads it just fine.
There's a reference to the date 150923203626Z (2015-09-23 20:36:26 UTC) somewhere in there, but I'm having trouble figuring out what it applies to.
Actually it's the expiration timestamp of signing certificate "Microsoft Certificate Trust List Publisher". I intended to add this info in the blog post but can't do it right now.
It appears to be a signed message, and for these sorts of things, I'm more of a fan of signed data (and the transport being unimportant) than a signed transport and unsigned data: there's a lot less attack surface on both ends.
apt, yum, PGP, etc. work the same way. There remains a decent argument for a secure transport anyway for privacy / avoiding side channels, or a general desire for HTTP delenda est, but it's nowhere near as strong an argument, HTTPS only provides marginal benefit to the side channels (Tor to a hidden service is much more effective), and other engineering concerns can legitimately override these concerns.
I think that may be purposeful. If your local certificate management system is on the fritz, you don't want that rejecting updates to the core cert lists. Probably better to fall back on some other cryptological system on the files themselves, since the content is not private, it's just the authenticity you care about.
I don't think it's really a big deal. Since the list is signed, an active attacker would only be able to replay an old version of the list... but it's hard to see how that would be worse than just blocking the request entirely.
An older version of the list might be missing a recently compromised certificate, though. Of course, you need to both MITM someone and compromise an important cert, so that's not the sort of thing just anybody could pull off.
Right, but assuming Windows isn't dumb enough to accept a remotely downloaded version that's older than the one it already has locally, the effect would be the same as if the attacker just prevented you from receiving new updates. And HTTPS wouldn't make it any harder for them to do that.
> the effect would be the same as if the attacker just prevented you from receiving new updates.
True, but it might be slightly less visible because you'd get an "update" instead of a failure. Also, I wonder if anyone has actually tested that scenario?
I'd like to believe that's true and that should be true, but I'd also have to actually test it before trusting it to be true.
Additionally, old versions will expire, so there's a limit to how far back you can keep someone, even if you continuously intercept the update attempts.
A word of warning for Elisp hackers: the Emacs Lisp part of that resource was written by someone with a CL background. I'm seeing various examples that are not conventional Elisp. For instance, ' is used instead of #' for function quoting in various places (prevents compilation of the function) and use of eval on a form instead of apply on a list (dangerous and also prevents compilation of the form). In addition, many of these features use the cl package at runtime, which will cause the compiler to throw a warning, because it's not allowed in Emacs proper.
That said, there's a lot of information here that's very useful for the starting Elisp programmer.
>For instance, ' is used instead of #' for function quoting in various places (prevents compilation of the function) and use of eval on a form instead of apply on a list
I don't see how these are evidence of the author having "CL background". CL is pretty much identical to Emacs lisp with regards to both of these things.
the #' in CL and Elisp are not the same. Elisp is a lisp-1 vs CL 'lisp-2'. The only similarity is that #'foo expands too (function foo). In CL (function foo) looks up foo in the function namespace (and iiuc can be omitted where functions are expected) in elisp the function form is like quote except for when byte-compiling. It allows the function to be byte-compiled.
Truth be told, I know nothing of CL. I do know quite a bit about Elisp, and since it's not an Elisp-ism, and the CL and Elisp columns share so much identical code (a lot from cl.el), I assumed it was a CL-ism. My bad.
You could try doing a cross-platform (iOS/Android) game with a C++ framework like Cocos2d-x. I read through Cocos2d-x By Example (http://www.amazon.com/Cocos2d-X-Example-Beginners-Guide-Enge...) last year and it was pretty good. Didn't assume a prior knowledge of C++
clang has -Weverything, I prefer to start with that and do #pragma clang diagnostic push/ignored/pop as needed and only turn off the really obnoxious ones, like -W-c++98-compat-pedantic
Worth a mention: In Objective-C with ARC, the compiler treats every pointer to an Obj-C object as a std::shared_ptr or std::unique_ptr (static analysis is used to optimize out unnecessary reference counting), unless it's marked otherwise with keywords such as __weak, __unsafe_unretained, etc.
