Nadim Kobeissi

@bugissue This is indeed what is planned.

It's coming.

@andersbateva No, it wouldn't. Also, please stop commenting on every single issue with one-sentence comments. You're spamming my GitHub inbox.

Sorry, no. I'd like to offer users some basic abilities like that.

I thought I had fixed this previously, but maybe not completely. A friend had complained to me about the issue and the fix worked for them. I'll do more testing.

I am aware of this shortcoming, but the thing is that I'm not sure whether I can fix it completely. Here are things I _can_ (and will) do to improve...

> Notably, because updates are served from a different subdomain, an adversary could just MITM all connections to download.crypto.cat to interfere with updates. Actually, I just remembered something. Even if...

Noting that the best way to do this would be to have separate `HTTPS` request constructors for the different URIs being validated that execute a `GET` request callback in case...

This is mostly dealt with now in fa6939ea4d696c265ee1a198e7b60cf7d6c3deff: - All `download.crypto.cat` and `crypto.cat/sas` connections are now pinned directly and only requests that pass pinning are allowed to continue. - WebSockets...

@jkzinzindohoue: > So the standard library will no longer be unified under the FStar name ? There's nothing here that implies that the standard library would no longer be unified...