摘要

  • 新测试把 Commons FileUpload 的缓冲阈值设为一个字节，迫使非空样本落盘，再逐字节核对 Wicket FileUpload.getBytes() 的输出。
  • organizations.xlsx 实际只是两行 UTF-8 文本，carta-ce.pdf 也只有 PDF 文件头和一行注释；测试没有打开 OOXML 工作簿，也没有解析完整 PDF。
  • 正确做法不是删掉这项快速测试，而是准确命名其证明范围，并用真实格式、领域规则、授权流程和有界执行测试补齐证据地图。

一项测试的名字可能比断言走得更远

2026 年 9 月 11 日，LACNIC 在公开的 elections-open-source 代码库中加入了一个名为 wicketFileUploadGetBytesWorksForDiskBackedExcelAndPdf 的方法。单看名称，它很像一份紧凑的验收结论：Excel 与 PDF 上传在磁盘存储条件下可以正常工作。打开方法本身，实验范围要窄得多，也因此更容易被准确理解。

测试首先创建 DiskFileItemFactory，把 JUnit 提供的临时目录交给它，并把缓冲大小设成 1。两个非空样本都超过这个阈值，于是内容不能只停留在内存里，而要进入临时文件。辅助方法向上传项写入字节，用 Wicket 的 FileUpload 包装它，调用 getBytes()，将返回数组与原数组做精确比较，最后在 finally 中删除临时项。

这不是无意义的绕路。Commons FileUpload 会根据阈值决定把较小内容留在内存，还是把较大内容写入磁盘。框架或依赖升级后，内存分支正常并不自动代表磁盘分支正常。临时文件的创建、关闭、重新读取和清理都可能形成独立故障点。把阈值压到一个字节，正是为了让小样本也必然经过目标分支。

所以，测试给出的第一条证据非常坚实：在所构造的环境里，写入磁盘支持上传项的字节，被 Wicket 读回时没有改变。若升级破坏了 Commons FileUpload 与 Wicket 之间的交接，这个小测试可以在文档解析器、选举数据和后台任务介入前发出警报。

问题出在格式名称所暗示的第二层含义。名为 spreadsheet 的变量只含 ORGID、换行和 ALFA-001。真正的 .xlsx 是一套 OOXML 压缩包，内部有内容类型、关系、工作表和 XML 部件。名为 pdf 的变量只含 %PDF-1.1、换行、%carta 和换行。它有常见开头，却没有构成完整 PDF 所需的对象、交叉引用和结尾结构。

测试给两段字节分别安上 organizations.xlsx 与 carta-ce.pdf 的客户端文件名，但没有调用 XSSFWorkbook，也没有调用 PDF 解析器。文件名是来访者提供的标签，MIME 同样通常来自请求边缘；文档格式则是内容结构。标签可以帮助描述用途，不能替结构替自己作证。

准确的结论因此应该是：磁盘支持的 multipart 项能够通过 Wicket 保持字节恒等。它没有证明样本是有效工作簿或完整信函，没有证明字段满足某场选举的要求，没有证明提交者有权操作，也没有证明最终数据发生了预期变化。限制结论不是贬低测试，而是让绿色结果在下一次升级、审计或故障分析中仍然可信。

同一个代码库里，其他测试已经跨过内容边界

如果只读新增方法，很容易得出对 LACNIC 不公平的判断：系统似乎只看扩展名。相邻代码给出了更细的画面。在同一个兼容性测试类中，一项测试把普通文本命名为 photo.jpg，送入候选人照片校验器，并期待“格式无效”的结果。另一项测试真正生成 800×600 的 PNG，经过处理后要求输出为 JPEG，再次解码，确认宽高都不超过 400 像素。

这两个图像案例不再满足于“字节能读”。内容必须能被图像解码器理解，还要完成格式转换与尺寸约束。它们恰好说明测试分层的价值：传输层可以使用极小、易读的合成字节；内容层则必须使用真实对象，才能证明解析和变换。

组织工作簿的实际上传路径也没有停在文件名。OrganizationExcelFileValidator 在边缘做的第一道判断比较宽松：客户端文件名以 .xlsx 结尾，或者声明的内容类型是 OOXML 工作表 MIME，任一条件成立便继续。这个“或”依赖请求方提供的信息，只适合作为初筛。

在欠费组织与删除流程中，校验器随后把字节交给远端验证；新增与更新则在提交时进行详细验证。ExcelUtils 把字节写进临时文件，要求 OOXML MIME，使用 Apache POI 的 XSSFWorkbook 打开，选择第一张工作表，读取表头并遍历行。欠费清单必须有 ORGID；批量新增或更新需要更多列。缺失列、空值、重复组织标识和不合规则的数据，会触发不同的领域错误。

组织上传面板还会在排队前执行操作特定的检查。例如，删除或覆盖不能只凭一个能打开的工作簿就获得许可。面板把文件内容、选举标识和相关选项交给验证过程；只有在通过后才请求排队。如果相同类型的处理已经进行，新的请求不会再创建第二项工作。

这让看似矛盾的结果同时成立。两行文本可以通过新增的字节恒等测试，因为它确实完整到达。它又可以在真正的 XSSFWorkbook 构造处失败，因为它根本不是 OOXML。前者保护库接口，后者保护格式，之后的列与行校验保护选举数据。每一层都在回答自己的问题。

选民名册上传也采用相似的阶段划分。页面从 Wicket 上传对象取得字节，先调用与具体选举相关的“能否应用”验证，再尝试把更新放入队列。新测试覆盖的是取字节这一动作的兼容形状，不会运行名册表头、行内容、选举条件或排队结果。

结果信函则是另一套控制。其表单开启 multipart，并把整体大小上限设为 10 MB。保存时，页面重新加载目标选举，强制检查访问权限；如果选举已经关闭，操作立即停止。西班牙语、英语与葡萄牙语三份可选信函先分别验证，全部通过后，选中的字节才会连同管理员与客户端地址语境写入。

不过，这里的 PDF 识别仍然很窄。ElectionResultLetterSupport.isPdf 只检查前四个字节是否为 %PDF。测试中的短样本满足这条规则，却不表示任何阅读器能够打开它，也不表示内部对象与交叉引用完整。10 MB 上限、授权、选举关闭状态和审计语境都是真实控制；它们只是不能替代结构解析。

把“上传可用”拆成五张收据

面对这类代码，最危险的表达是“上传已经测试”。它没有说明测试的是哪一个边界，也没有说明失败会阻止什么。更可审计的做法，是为五个不同问题分别保留收据。

第一张是传输收据。它应同时覆盖内存与磁盘，明确断言目标项确实处在 isInMemory() == false 的状态，比较原始字节，检查输入输出流关闭，并验证临时项能够清理。LACNIC 的新增方法已经完成核心部分。若把名字改成“磁盘支持的 FileUpload 经 getBytes 保持字节恒等”，文件扩展名仍可作为代表用途，却不会借用解析器的权威。

第二张是格式收据。OOXML 需要由 POI 或等价工具生成的小型真实工作簿，包含预期工作表和列头；同时要有普通 ZIP 冒充工作簿、被截断的包，以及产品政策覆盖的加密或受保护文件。PDF 至少需要一个被选定解析器接受的完整最小文档，再加入只有文件头、被截断、含异常尾部或其他相关欺骗形式的反例。扩展名、MIME 与魔数都可以贡献信号，但没有一个应该独占最终结论。

第三张是领域收据。真实工作簿必须进入组织或名册规则。测试要区分“文档无法打开”“必需列缺失”“某行为空”“ORGID 重复”“国家或票数不合法”等不同结果。若系统会生成错误报告，收据还应确认报告指出正确行。拒绝的输入不能留下排队工作；接受的输入则要与已知选举状态相符。

第四张是流程收据。获授权的管理员可以操作开放选举；无权限会话或已经关闭的选举不可以。有效文件只产生一次预期任务，并带有正确审计语境。两次并发提交应触发“正在处理”的保护，而不是生成两份工作。对三种语言的结果信函，任意一份新上传失败都应发生在三项更改应用之前，以防出现部分更新。

第五张是资源收据。字节相同并不回答请求有多大、内存会增长多少、临时文件放在哪里、何时删除、解析多久超时、压缩内容解开后膨胀到什么程度。Commons FileUpload 文档描述内存与磁盘阈值，也提供请求大小控制。Apache POI 的安全指引明确提醒：处理外部文档时，库内检查不能覆盖所有破坏性效果，需要额外隔离与资源防护。

POI 的 ZipSecureFile 暴露了最小压缩比、单个解压条目最大值等限制，用于识别压缩炸弹并约束内存风险。OWASP 的文件上传指南则建议组合授权、允许扩展名、MIME、签名、文件大小和解压后大小。这里引用这些通用建议，不是用它们反推 LACNIC 存在漏洞，而是用来定义一份完整验收记录应该能回答的问题。

不要从代码快照推断生产事实

证据边界还包括版本。所冻结的管理模块 POM 声明 Wicket 10.9.0，WildFly 模块文件引用 POI OOXML 5.0.0。它们可以描述这个提交中的构建意图，却不能证明某次真实选举使用了相同版本、相同配置或相同临时目录策略。

同样，依赖变更之后很快出现兼容性测试，也不能证明先前发生过故障，更不能证明升级造成事故。开发者可能主动补回归覆盖，也可能在构建过程中发现需要固化的边界。缺少提交说明之外的证据时，因果判断应当停在门外。

文章也不应把 %PDF 前缀检查直接称为安全缺陷。它可能是产品有意选择的初步类型筛选；代码显示的事实只是它没有执行完整结构验证。是否需要更深解析，取决于信函如何展示、存储、下载，提交者是否可信，以及风险政策如何权衡兼容性、复杂度和拒绝误差。审计应先把现状说准，再讨论选择。

小测试最宝贵的地方，是失败时指向清楚

把所有事情塞进一个端到端样本，并不会自动增加把握。它可能让工作簿解析、权限、网络调用、队列与数据库结果同时介入。一旦失败，定位成本很高；一旦成功，也很难知道每一个分支是否真正经过。快速、孤立的传输测试恰好避免了这种模糊。

真正需要修正的是“它在组织记忆里叫什么”。发布评审者、管理者和审计者通常看到测试名或简短摘要，而不是逐行阅读实现。“磁盘上的 Excel 与 PDF 可以工作”比“磁盘支持上传的字节经 Wicket 保持一致”更容易传播，也更容易在多年后被当成整条文档路径的证明。

因此，最小成本的改进包括三件事：保留现有测试；增加一项确认确实落盘的显式断言；把测试名、构建版本和所链接的格式、领域、流程收据写在同一张证据地图中。这样，绿色结果不会越权，红色结果也能迅速找到责任边界。

测试数据的管理也会因此更好。传输样本应当小、透明、无需依赖解析器；真实文档样本应当有生成方式、版本和负例；领域样本应当有已知行与预期结果。若让一个庞大二进制文件承担所有职责，后续维护者很难判断一次差异来自格式、依赖还是业务。分层并不是额外仪式，而是让每个样本保持最小且仍然真实。

真文档测试也需要防止制造新的错觉

把两行文本换成一个真实工作簿，并不意味着证据工作已经结束。二进制样本如果没有可重复的生成方式，很容易在代码库里变成无法解释的黑箱。后来者只知道它“曾经能打开”，却不知道由哪个版本生成、为什么包含这些列、哪些异常是有意保留的。更稳妥的做法，是用测试代码生成最小 OOXML，或者同时保存生成脚本、摘要和预期工作表结构。这样一旦 POI 升级导致文件不同，差异可以被解释，而不是简单更新样本让测试恢复绿色。

真实 PDF 也有相同问题。最小文档应该明确由什么工具产生、解析器应看到几页、页面是否必须包含文字、元数据和外部引用如何处理。只有文件头的反例固然重要，但还应区分“不是 PDF”“PDF 被截断”“PDF 可以解析但不符合信函政策”三种失败。若把它们都归为一个无效格式提示，运维人员会失去判断故障位置的线索，使用者也难以知道应该修复文件还是联系管理员。

格式验证越深入，兼容性取舍越明显。过于宽松会让与业务无关的内容进入存储；过于严格又可能拒绝合法但不常见的生成器输出。LACNIC 无需从通用指南中照搬唯一答案，而应记录自己的接受边界：结果信函需要可下载即可，还是必须能由指定解析器打开；是否允许加密、嵌入文件、脚本或超大页面；失败时是阻止保存还是隔离待审。这些都是产品与治理决定，不能由四个魔数字节暗中代替。

原子性是结果信函路径的关键问题

结果页面一次面对三种语言的可选信函。代码先逐个验证，再执行应用，这一顺序本身值得保留为明确的测试事实。最重要的负例不是“坏 PDF 会收到错误”，而是西班牙语和英语文件有效、葡萄牙语无效时，三者都不应发生部分变化。随后还要覆盖删除现有信函、没有上传新文件时保留旧信函、同时删除并替换等组合，确保页面意图与最终状态一致。

原子性测试还应观察异常边界。验证全部通过后，若保存过程失败，使用者看到的反馈、旧文件的可用性和审计记录应该如何表现？公开代码显示保存调用携带管理员与客户端地址语境，但新增兼容性测试不触及这些后果。把失败后的可恢复状态写入流程收据，能避免“文件本身有效”被误解为“整次操作已经安全完成”。

组织工作簿的异步路径则需要另一种原子性。排队成功不等于所有行已经应用；排队拒绝也不应被显示成文件无效。验证结果、排队结果、处理进度与最终创建、更新、删除数量，是四个不同时间点。测试若能为每个时间点保留稳定标识和预期计数，管理员就能把格式失败、领域失败、并发冲突和执行失败区分开来。

资源收据必须记录测量位置

10 MB 表单上限是结果信函页面的明确事实，但不能自动外推到组织或名册面板。共享框架可能有全局默认值，部署也可能有代理层限制；没有证据时，审计不应把这些可能性写成已验证保障。同样，POI 内部存在压缩炸弹防护并不表示应用选择了特定阈值。收据应说明限制在哪一层设置、测试在哪一层观察、超过限制后由谁生成反馈。

内存边界尤其值得与getBytes()分开记录。这个方法按定义返回完整字节数组，因此即使上传先落盘，调用时仍可能需要把全部内容放入内存。流式接口存在，不代表当前领域解析与远端调用可以不经设计便切换过去。若未来要改变读取方式，应先梳理验证器和持久化接口对byte[]的依赖，再决定是限定文件规模、隔离解析进程，还是重构为流式处理。不能把一般性能建议伪装成无成本修补。

临时文件的生命周期也需要可见。单元测试在finally里主动删除自建项，这很好地证明了测试本身的清理意图。真实请求中的项由 Wicket 与 Commons 的生命周期管理，应用另外把工作簿字节写成临时文件。两类文件是否使用同一目录、何时删除、异常时是否残留，应分别核实。只有把创建者、所有者和删除时机写入收据，才能在磁盘压力或权限错误出现时快速定位。

对外说明应保留“不知道”

开源代码让外部读者能检查具体断言，这是治理优势。但透明并不意味着观察者可以填补所有空白。我们知道提交中增加了什么，知道样本是什么，知道若干实际处理路径做了什么；我们不知道私有测试是否覆盖更多情况，也不知道生产构建、代理限制、运行参数和运维程序是否一致。诚实的文章必须同时写下已知与未知。

这种写法不会削弱对维护者的评价。相反，它把值得肯定的工作放在准确位置：LACNIC 固化了一个磁盘回退兼容边界，图像路径展示了内容级负例，工作簿路径包含真实 POI 与行级验证，结果页面包含访问和关闭状态控制。接下来可以改进的是这些证据之间的索引与命名，而不是凭空宣判现有系统没有防护。

一份成熟的发布说明可以直接列出五张收据的状态和范围。读者看到“传输通过”时，知道它覆盖哪个库版本与存储分支；看到“格式通过”时，知道使用哪些真实文档；看到“流程通过”时，知道哪类账户和选举状态被测试。这样的说明比一句“文件上传已修复”更长一点，却能在几年后仍被准确复用。

最后还应为每张收据设定失效条件。只要 Wicket、Commons FileUpload、临时目录策略或上传包装方式变化，传输收据就需要重验；只要 POI、PDF 接受政策或样本生成器变化，格式收据就要重验；只要列定义、选举状态规则、权限模型或队列语义变化，领域和流程收据就要重验。没有失效条件的绿色结果会无限期存活，哪怕它所描述的环境已经消失。把触发条件写进记录，才能让“曾经通过”与“对当前版本仍有效”保持区别。

这也为发布决策建立了比例原则。一次只改页面文案的提交，不必重做所有二进制解析；一次更换 multipart 库的提交，则不能只依赖领域测试偶然通过。变更触及哪条证据边，就重验哪张收据及其直接依赖。这样既避免把共享代码库当成全量重测的理由，也避免以快速测试为借口跳过真正受影响的格式和流程。证据地图最终服务的不是更多测试数量，而是更准确的选择。

来源