恶意文件如何被 claude-obsidian 的归档防御逐关击退【免费下载链接】claude-obsidianSelf-organizing AI second brain for Obsidian Claude Code. Drop any source and Claude reads, links, and files it into one connected knowledge graph of plain Markdown you own. AI note-taking, personal knowledge management (PKM), and an open-source Notion alternative. Based on Karpathys LLM Wiki pattern.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-obsidianclaude-obsidian 是一个自组织的 AI 第二大脑把任意来源的资料丢进去Claude 负责读取、建立链接并归档成一组互相引用的 Markdown 笔记最终沉淀为可在 Obsidian 中反复查询的知识图谱。由于归档入口直接吞下外部文件归档安全贯穿了它的全部实现——项目把每一个进入inbox/的文件都当作潜在的敌意输入来对待。这篇文章不按层层设防的清单来写而是跟着一个恶意文件走一遍完整的闯关过程它在文件名校验、符号链接审计、内容寻址存储、并发锁这些关卡分别撞上什么机制又被哪个错误码击退。所有机制均可在仓库代码中直接核对。 文件与路径先过清洗恶意载荷最常藏在名字和路径里。源文件在接触归档流程前名字要先过一遍_validate_filename它拦截控制字符与不可见格式字符零宽字符、换行、首尾空格、以点或空格结尾的名字、Windows 保留名CON、COM1、NUL等并要求名称完成 NFC Unicode 归一化、长度不超过 240 字节。任何一条不满足都会抛出UNSAFE_FILENAME——这些规则防的是肉眼看不见的字符和在不同操作系统上行为不一致的名字。路径本身还有独立的词法规则。配置项里的收件箱目录由_validate_relative_directory校验拒绝绝对路径、反斜杠、./..段a/../b这类未规范化写法直接以INVALID_CONFIG_PATH失败。事务层的_normalize_vault_path更严格控制字符或反斜杠返回INVALID_WRITE_PATH未规范化的路径返回NONCANONICAL_WRITE_PATH非 NFC 名称返回NONCANONICAL_UNICODE_PATH。大小写与重音别名如何被排除在不区分大小写的文件系统上Note.md与NOTE.MD实际是同一个文件攻击者可以用这种别名混淆权限判断。_assert_no_existing_portable_alias会枚举目标路径同目录下的兄弟项只要发现 NFC casefold 之后与写入路径同名的既有文件就抛出CASEFOLD_PATH_ALIAS把歧义挡在写入发生之前。 符号链接逐段拦截符号链接相当于别名门名字指向库内实际通向库外。claude-obsidian 对归档链路上的符号链接采取零容忍覆盖四个位置且 Windows 上的 junction 和挂载点也按符号链接同等处理见is_name_surrogate。机制检查位置错误码收件箱与原始仓库根目录是否为符号链接discover_filesSOURCE_ROOT_SYMLINKinbox 内任意目录/文件条目是符号链接discover_filesSOURCE_SYMLINK.raw内容寻址存储目录及其既有副本_planned_destination、_find_existing_captureRAW_STORE_SYMLINK事务写入路径的每一段中间目录_safe_vault_pathSYMLINK_WRITE_PATH词法合法不等于安全a/b.md里的a可能是指向系统其他位置的别名。_allowed_source_path会沿路径逐段检查中间目录源文件即使自身无害只要穿过了某个别名目录进入收件箱就以SOURCE_OUTSIDE_INBOX被拒L614-L624。最终一道兜底是assert_within它在真实文件系统上解析符号链接确认最终落点仍在库内否则抛出PATH_OUTSIDE_VAULT。 预算硬限与内容寻址的不可变仓库资源耗尽是另一类攻击海量小文件或超大文件可以在归档前拖垮磁盘。批次进入任何 IO 之前要先过CaptureBudget单批最多 100 个文件COUNT_BUDGET_EXCEEDED、单文件不超过 64 MBFILE_BUDGET_EXCEEDED、整批不超过 256 MBTOTAL_BUDGET_EXCEEDED捕获队列文档另有 8 MB / 4096 条的上限L68-L69。这些限制属于失败即中止不是提示性阈值。通过预算的文件随后被复制为SHA-256 摘要.扩展名存入.raw/captured/扩展名不在白名单内时统一落到.binL885-L890。这个命名方案自带两层校验哈希期间的替换检测source_identity在计算摘要前后各取一次文件的 inode、大小、修改时间签名若文件在读取过程中被换掉抛出SOURCE_CHANGED冲突L703-L705保证进入仓库的就是检查时看到的那份字节。重复归档的字节复核_find_existing_capture发现同摘要的旧副本时会重新计算其哈希副本名字对但内容不对说明仓库被外部改写抛出IMMUTABLE_SOURCE_CONFLICT。原始资料区因此是只创建、永不修改的任何已有副本必须与摘要完全一致否则整批操作失败。 并发冲突锁、所有权令牌与确定性回滚多进程同时修改同一个库会出现两个进程互相覆盖的情况。捕获队列为此使用目录型锁CaptureQueueLock锁目录以原子方式创建创建失败说明已有持有者超时后抛QUEUE_LOCK_TIMEOUTL1545-L1549持有者把 pid、主机名和随机 token 写入owner.json释放前回读校验 token发现身份不符即抛QUEUE_LOCK_OWNERSHIP_LOST防止锁被并发偷换。死锁恢复刻意保守只有确认持有进程已死且锁超龄默认 3600 秒才允许清理且清理前还要复查锁身份未变。事务层的MutationLock采用同一套所有权模型LOCK_OWNERSHIP_LOST并在此基础上提供预检哈希 持久日志 原子替换 回滚每个写入都记录预期哈希回滚删除文件前由_confined_vault_unlink重新校验目标文件的字节与 inode发现被替换过就抛ROLLBACK_TARGET_CHANGED绝不删掉不属于自己的文件。所有此类冲突都归入CaptureConflict错误家族以确定性错误码暴露而不是静默失败。️ 外部 URL 的 SSRF 边界本地归档之外外部 URL 适配器同样被锁死。validate_https_url只接受 HTTPSURL_SCHEME_FORBIDDEN_validate_public_host拒绝localhost、.internal、169.254.*等非公网主机URL_PRIVATE_HOSTvalidate_redirect_chain则要求重定向不得离开已批准的主机白名单REDIRECT_HOST_FORBIDDEN。外部动作只能生成惰性计划必须用户明确同意才执行。克隆仓库https://gitcode.com/GitHub_Trending/cl/claude-obsidian后按 docs/install-guide.md 初始化一个独立知识库把文件放进inbox/即可触发上述全部校验归档事务的具体规则另见 skills/wiki/references/operation-transactions.md。这套体系的设计取向很一致任何一步遇到不确定状态宁可抛出带错误码的冲突停下来也不在模糊中继续写入——对把文件交给机器加工的工具来说这比尽量完成更接近用户真正需要的安全感。【免费下载链接】claude-obsidianSelf-organizing AI second brain for Obsidian Claude Code. Drop any source and Claude reads, links, and files it into one connected knowledge graph of plain Markdown you own. AI note-taking, personal knowledge management (PKM), and an open-source Notion alternative. Based on Karpathys LLM Wiki pattern.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-obsidian创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
恶意文件如何被 claude-obsidian 的归档防御逐关击退【免费下载链接】claude-obsidianSelf-organizing AI second brain for Obsidian Claude Code. Drop any source and Claude reads, links, and files it into one connected knowledge graph of plain Markdown you own. AI note-taking, personal knowledge management (PKM), and an open-source Notion alternative. Based on Karpathys LLM Wiki pattern.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-obsidianclaude-obsidian 是一个自组织的 AI 第二大脑把任意来源的资料丢进去Claude 负责读取、建立链接并归档成一组互相引用的 Markdown 笔记最终沉淀为可在 Obsidian 中反复查询的知识图谱。由于归档入口直接吞下外部文件归档安全贯穿了它的全部实现——项目把每一个进入inbox/的文件都当作潜在的敌意输入来对待。这篇文章不按层层设防的清单来写而是跟着一个恶意文件走一遍完整的闯关过程它在文件名校验、符号链接审计、内容寻址存储、并发锁这些关卡分别撞上什么机制又被哪个错误码击退。所有机制均可在仓库代码中直接核对。 文件与路径先过清洗恶意载荷最常藏在名字和路径里。源文件在接触归档流程前名字要先过一遍_validate_filename它拦截控制字符与不可见格式字符零宽字符、换行、首尾空格、以点或空格结尾的名字、Windows 保留名CON、COM1、NUL等并要求名称完成 NFC Unicode 归一化、长度不超过 240 字节。任何一条不满足都会抛出UNSAFE_FILENAME——这些规则防的是肉眼看不见的字符和在不同操作系统上行为不一致的名字。路径本身还有独立的词法规则。配置项里的收件箱目录由_validate_relative_directory校验拒绝绝对路径、反斜杠、./..段a/../b这类未规范化写法直接以INVALID_CONFIG_PATH失败。事务层的_normalize_vault_path更严格控制字符或反斜杠返回INVALID_WRITE_PATH未规范化的路径返回NONCANONICAL_WRITE_PATH非 NFC 名称返回NONCANONICAL_UNICODE_PATH。大小写与重音别名如何被排除在不区分大小写的文件系统上Note.md与NOTE.MD实际是同一个文件攻击者可以用这种别名混淆权限判断。_assert_no_existing_portable_alias会枚举目标路径同目录下的兄弟项只要发现 NFC casefold 之后与写入路径同名的既有文件就抛出CASEFOLD_PATH_ALIAS把歧义挡在写入发生之前。 符号链接逐段拦截符号链接相当于别名门名字指向库内实际通向库外。claude-obsidian 对归档链路上的符号链接采取零容忍覆盖四个位置且 Windows 上的 junction 和挂载点也按符号链接同等处理见is_name_surrogate。机制检查位置错误码收件箱与原始仓库根目录是否为符号链接discover_filesSOURCE_ROOT_SYMLINKinbox 内任意目录/文件条目是符号链接discover_filesSOURCE_SYMLINK.raw内容寻址存储目录及其既有副本_planned_destination、_find_existing_captureRAW_STORE_SYMLINK事务写入路径的每一段中间目录_safe_vault_pathSYMLINK_WRITE_PATH词法合法不等于安全a/b.md里的a可能是指向系统其他位置的别名。_allowed_source_path会沿路径逐段检查中间目录源文件即使自身无害只要穿过了某个别名目录进入收件箱就以SOURCE_OUTSIDE_INBOX被拒L614-L624。最终一道兜底是assert_within它在真实文件系统上解析符号链接确认最终落点仍在库内否则抛出PATH_OUTSIDE_VAULT。 预算硬限与内容寻址的不可变仓库资源耗尽是另一类攻击海量小文件或超大文件可以在归档前拖垮磁盘。批次进入任何 IO 之前要先过CaptureBudget单批最多 100 个文件COUNT_BUDGET_EXCEEDED、单文件不超过 64 MBFILE_BUDGET_EXCEEDED、整批不超过 256 MBTOTAL_BUDGET_EXCEEDED捕获队列文档另有 8 MB / 4096 条的上限L68-L69。这些限制属于失败即中止不是提示性阈值。通过预算的文件随后被复制为SHA-256 摘要.扩展名存入.raw/captured/扩展名不在白名单内时统一落到.binL885-L890。这个命名方案自带两层校验哈希期间的替换检测source_identity在计算摘要前后各取一次文件的 inode、大小、修改时间签名若文件在读取过程中被换掉抛出SOURCE_CHANGED冲突L703-L705保证进入仓库的就是检查时看到的那份字节。重复归档的字节复核_find_existing_capture发现同摘要的旧副本时会重新计算其哈希副本名字对但内容不对说明仓库被外部改写抛出IMMUTABLE_SOURCE_CONFLICT。原始资料区因此是只创建、永不修改的任何已有副本必须与摘要完全一致否则整批操作失败。 并发冲突锁、所有权令牌与确定性回滚多进程同时修改同一个库会出现两个进程互相覆盖的情况。捕获队列为此使用目录型锁CaptureQueueLock锁目录以原子方式创建创建失败说明已有持有者超时后抛QUEUE_LOCK_TIMEOUTL1545-L1549持有者把 pid、主机名和随机 token 写入owner.json释放前回读校验 token发现身份不符即抛QUEUE_LOCK_OWNERSHIP_LOST防止锁被并发偷换。死锁恢复刻意保守只有确认持有进程已死且锁超龄默认 3600 秒才允许清理且清理前还要复查锁身份未变。事务层的MutationLock采用同一套所有权模型LOCK_OWNERSHIP_LOST并在此基础上提供预检哈希 持久日志 原子替换 回滚每个写入都记录预期哈希回滚删除文件前由_confined_vault_unlink重新校验目标文件的字节与 inode发现被替换过就抛ROLLBACK_TARGET_CHANGED绝不删掉不属于自己的文件。所有此类冲突都归入CaptureConflict错误家族以确定性错误码暴露而不是静默失败。️ 外部 URL 的 SSRF 边界本地归档之外外部 URL 适配器同样被锁死。validate_https_url只接受 HTTPSURL_SCHEME_FORBIDDEN_validate_public_host拒绝localhost、.internal、169.254.*等非公网主机URL_PRIVATE_HOSTvalidate_redirect_chain则要求重定向不得离开已批准的主机白名单REDIRECT_HOST_FORBIDDEN。外部动作只能生成惰性计划必须用户明确同意才执行。克隆仓库https://gitcode.com/GitHub_Trending/cl/claude-obsidian后按 docs/install-guide.md 初始化一个独立知识库把文件放进inbox/即可触发上述全部校验归档事务的具体规则另见 skills/wiki/references/operation-transactions.md。这套体系的设计取向很一致任何一步遇到不确定状态宁可抛出带错误码的冲突停下来也不在模糊中继续写入——对把文件交给机器加工的工具来说这比尽量完成更接近用户真正需要的安全感。【免费下载链接】claude-obsidianSelf-organizing AI second brain for Obsidian Claude Code. Drop any source and Claude reads, links, and files it into one connected knowledge graph of plain Markdown you own. AI note-taking, personal knowledge management (PKM), and an open-source Notion alternative. Based on Karpathys LLM Wiki pattern.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-obsidian创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
)
)
