SSL 设计目标:
- 防内容篡改
- 防冒充服务器身份
- 加密通信内容
而翻墙的目标:
- 不被检测出客户端在访问什么网站
- 不被检测出服务器在提供翻墙服务
dipper:/ # ls -l /dev/block/platform/soc/1d84000.ufshc/by-name/ | |
total 0 | |
lrwxrwxrwx 1 root root 15 1970-01-21 06:45 ImageFv -> /dev/block/sdf4 | |
lrwxrwxrwx 1 root root 16 1970-01-21 06:45 abl_a -> /dev/block/sde32 | |
lrwxrwxrwx 1 root root 16 1970-01-21 06:45 abl_b -> /dev/block/sde33 | |
lrwxrwxrwx 1 root root 16 1970-01-21 06:45 aop_a -> /dev/block/sde14 | |
lrwxrwxrwx 1 root root 16 1970-01-21 06:45 aop_b -> /dev/block/sde15 | |
lrwxrwxrwx 1 root root 15 1970-01-21 06:45 apdp -> /dev/block/sde6 | |
lrwxrwxrwx 1 root root 15 1970-01-21 06:45 bk01 -> /dev/block/sda3 | |
lrwxrwxrwx 1 root root 15 1970-01-21 06:45 bk02 -> /dev/block/sda4 |
SSL 设计目标:
而翻墙的目标:
{ pkgs, sumFile }: | |
with pkgs; | |
let | |
mod2prefix = path: version: hash: | |
let | |
fullpath = "${path}@${lib.strings.removeSuffix "/go.mod" version}"; | |
manifest = runCommand "${fullpath}.manifest" | |
{ | |
outputHashMode = "flat"; | |
outputHashAlgo = "sha256"; |
I was at Amazon for about six and a half years, and now I've been at Google for that long. One thing that struck me immediately about the two companies -- an impression that has been reinforced almost daily -- is that Amazon does everything wrong, and Google does everything right. Sure, it's a sweeping generalization, but a surprisingly accurate one. It's pretty crazy. There are probably a hundred or even two hundred different ways you can compare the two companies, and Google is superior in all but three of them, if I recall correctly. I actually did a spreadsheet at one point but Legal wouldn't let me show it to anyone, even though recruiting loved it.
I mean, just to give you a very brief taste: Amazon's recruiting process is fundamentally flawed by having teams hire for themselves, so their hiring bar is incredibly inconsistent across teams, despite various efforts they've made to level it out. And their operations are a mess; they don't real
{ | |
/* Override symbols so other apps can bind */ | |
/* ~ stands for option, ^ stands for control */ | |
"~j" = "noop:"; | |
"~i" = "noop:"; | |
"~;" = "noop:"; | |
"~a" = "noop:"; | |
"~2" = "noop:"; | |
"~g" = "noop:"; | |
"~y" = "noop:"; |
Basic unit type:
λ> replTy "()"
() :: ()
Basic functions:
(define-record fitem (result ready mutex cond)) | |
(define future | |
(lambda (thunk) | |
(let ([item (make-fitem #f #f (make-mutex) (make-condition))]) | |
(fork-thread | |
(lambda () | |
(let ([result (thunk)]) | |
(with-mutex (fitem-mutex item) | |
(set-fitem-result! item result) |
127.0.0.1 api.ad.xiaomi.com | |
127.0.0.1 sdkconfig.ad.xiaomi.com | |
127.0.0.1 ad.mi.com | |
127.0.0.1 ad.xiaomi.com | |
127.0.0.1 ad1.xiaomi.com | |
127.0.0.1 adv.sec.miui.com | |
127.0.0.1 test.ad.xiaomi.com | |
127.0.0.1 new.api.ad.xiaomi.com |
MesaLink是百度安全实验室开发的一个内存安全并兼容OpenSSL的传输层安全(Transport Layer Security, TLS)协议栈。近年来TLS漏洞频发,以2014年的OpenSSL"心血"为代表的内存安全漏洞对业界造成了巨大损失。MesaLink的主要目标是用Rust这样一个保证内存安全的语言,根除TLS协议栈中威胁通信安全性和完整性的内存安全漏洞,减小攻击面且保证攻击面收敛可审计。此外,MesaLink支持跨平台,提供兼容OpenSSL的C API,更可在安卓和libcurl中无缝替换OpenSSL。这极大地降低了开发成本,方便智能设备厂商快速获取安全通信的能力,从而实质性提升智能设备生态的安全性。MesaLink已经在Github上以BSD协议开源,同时MesaLink也是OASES智能终端安全生态联盟的核心开放技术之一;我们欢迎更多合作伙伴的加入,共建安全生态。
为提供完善的功能,并保证强健的安全性,MesaLink 将遵循 Rust SGX SDK 项目中提出的混合代码内存安全架构三原则: