Hypercube

So it is not enough to use `setSessionDynFlags` to set the `interactivePrint` record. Some additional work need to be done. Is my understanding correct?

I see. Thanks! (I'll leave this issue open since I still want this feature.)

？？？TTL=1？本来还想围观呢

这个 PR 被 merge 后我会相应更新 Hackergame 平台相关代码

考虑到旧系统仍然有一些用处，并且目前的链接会打开一个可以选择新旧两个系统的页面，暂时不改吧，等旧系统没用了，或者这个页面不工作了，再改。 另：看起来新系统里面说自己叫“研究生综合服务平台”，比起通知中用的叫法，我略倾向于用链接点开后自己显示的名字来命名链接。

没啥标准，历史原因，最初有 6 个，然后按统计数据只保留了 3 个。没展示过的自然不可能有统计数据，也就没法和当前在展示的比较。 可以加，我觉得还有很多校内网站也可以加，可以搞一些比较长的收集性质的列表（而不完全按“常用程度”来筛选）。但需要新的 UI 设计，我觉得现在这种大图标的风格就不合适了，或许应该专门有区域/页面是比较密集的整理。 就差一个前端工程师了.jpg

相关： https://github.com/USTC-Hackergame/hackergame-challenge-docker/pull/1 这里提议使用 hex 也不够好。好的 token 设计应该： - 能一眼看出来是 hackergame token，比如有前缀 - 唯一，不能通过改变大小写、改变前缀、加空格等方法做出都能验证通过但不同的 token（hex 不满足此要求） - 各种编程语言中都容易正确实现解析和验证逻辑（一些太冷门的方案，比如 base58，可能有点问题） - 只包含比较安全的字符

base64 在一些语言中也不唯一，去掉 padding 的等号也能解析成功。

> 但是我记得 url 编码的 base64 是没有结尾的等号的 至少 Python 的 `base64.urlsafe_b64encode` 是有等号的。 > 不过唯一真的这么重要吗 最主要的问题是我们的动态 flag 都是用 token 的哈希算出来的。如果一个非正规的 token 能通过验证，最终给出的 flag 却是错误的，就会很坑。 > 同一个证书对同一个输入的签名真的是唯一的吗 参见上面发的那个 pull request，我正在尝试换成 libsodium 生成的签名（其实是 ed25519），它不仅是确定性的（同一个私钥对同一个消息只会生成一个固定的签名），而且是没有...

机器上的参数如下，我怎么看着像是没有被exclude，但实际上我们的镜像就是旧了，很奇怪。 ``` --exclude=/unofficial/non-free/cd-including-firmware/daily* --exclude=/unofficial/non-free/cd-including-firmware/archive --include=/unofficial/non-free --include=/openstack/current --include=openstack/testing --exclude=/.* --exclude=/archive --exclude=/blends-live --exclude=/cd-sources --exclude=/daily-builds* --exclude=/release --exclude=/openstack/archive --exclude=/experimental-live --exclude=/snapshot* --exclude=/stretch* --exclude=/tmp --exclude=/unofficial/* --exclude=/project* ```