前段时间，我在封装一个 OpenAI API 兼容接口。在查阅返回格式时，手头正好缺 Key。
中途也想过有没有人分享过 Key，不过当时搜了一下没找到。这几天回头来再来看这个问题，发现泄露的 Key 还是不少的。
寻找泄露的 Key 主要针对 HuggingFace 和 Github。
HuggingFace 的分词比较粗暴，比较难搜到 Key，不过一但出现有效率很高。
Github 搜索比较完善，还支持正则，所以能挖掘到大量 Key，当然有效率也会低。
OpenAI Key 的格式为，sk- 或 sk-proj 开头，然后20位字母数字，T3BlbkFJ（"OpenAI" 的 Base64），再20位字母数字。
在 Github 可以直接用正则，例如 /sk-(|proj-)?[0-9a-zA-Z]{20}T3BlbkFJ[0-9a-zA-Z]{20}/。
不过 Github 只支持查看前 5 页，可以靠限制条件搜索获得更多结果。
我从特定的语言浅浅爬了六千条 Key，大概有 100 个有效 Key，其中支持 GPT-4 的占了四成。Github 显示总数据量约 3 万条，这样大概明文泄露的规模至少有 500 条。由于搜索并非是全文，一个文档中泄露多条的情况还没计算在内。
通过查看原始数据，发现很多开发者喜欢把 Key 写在注释里，例如 //sk-******，非常的离谱。还有一些人会对 Key 前后加一些别的混淆字母，或者简单的明文拼装，也很容易泄露。
如果实在要图方便，简单的 base64 或者逆序输出也足够防爬虫了。
Huggingface 给每个人无限量的临时 Space 配额，试了试居然可以运行代理：一个简单的 Trojan 示例。
直接 Dumplicate，然后修改 PASSWORD 和 WS_PATH 两个 secret 就能启动了。
WS_PATH（伪装路径）不是必须的，删掉它就等同于跑在首页上。
HF Space 踩坑记录
① websocket 问题
代理协议要套用 websocket 才能连接成功。由于很多聊天 Demo 的流式输出都基于 websocket，倒是不用担心像 Colab 那样被掐。
② binding host 问题
始终使用 0.0.0.0 而非 127.0.0.1，否则可能会出现奇奇怪怪的状况。Space 必须要 Public，否则知道 hf.space 地址也不能连接成功。
③ 卡 Starting 问题
即使 Space 内的程序已经正常 Running，仍有可能卡在 Starting。
如果一切正常，且有服务占用 7860 端口（默认端口），Space 状态理应切换为 Running。但 HF 对端口占用检测有 Bug，此时 Space 就会无限 Starting。由于只有 Running 状态，端口才会转发数据，所以此时即使服务正常也无法访问。
解决办法：在启动脚本里加上一句 python -m http.server 7860 & kill $! 。也就是用一个 HF 能识别的服务进程占用 7860 端口后立刻杀掉，再在这个端口上运行其他服务。
④ 保活问题
每个 Space 的运行时间是 48h，之后”不活跃“的 Space 将进入睡眠。之前我猜测只要 .hf.space 有访问就能保活，后来看到确实有人引入 upapp 来检测自己保活。这样的话应该也可以用 UptimeRobot 这类第三方检测来定期访问保活。
⑤ 滥用问题
HF 好像没有具体说明代理是否属于滥用，不过大规模滥用应该是不可能的，只适合自用或备用。第一，HF 给每个用户（对，是账户下所有 Space）分配了 3 个 固定 IP，没有 AnyCast，所以不太可能被批量白嫖。第二，所有 IP 都在美国，延迟一般，也无法绑定域名。
之前提到，Qwen 官方提供了一个在线 Demo。本来是基于 Gradio 的，我将它转换成了 OpenAI 的接口，并且直接部署在了 HF 上： Qwen 1.5 minimal Chat
虽然名字叫 minimal，实际接入的是 110B…… 本地连 7B 都费劲，只能白嫖官方勉强维持生活。
碎碎念：HF space 的 Docker 还是有点奇怪的，调试完了新建项目再部署，就出现 .sh 文件找不到。折腾了半天用 bash 就可以，直接 ./ 就不行，莫名其妙。
因为 HF space 有 48h 不访问就 sleep 的限制，我加上了一个每隔一小时访问自己的脚本，看看能不能绕过这个限制。