我的公司正在努力满足我们的应用程序的PA-DSS要求，其中一个是关于＆＃34;安全源控制＆＃34;，但是我们的审计员已将其解释为需要签署修订版。我看到＆＃34;签名提交＆＃34;在git和Hg中，但在perforce方面没有发现任何东西。
审计员关于他想看到的内容的例子如下：
＆＃34;支付应用程序供应商通过使用标准哈希算法在整个开发过程中维护源代码完整性，该算法在代码签入时创建和验证，并在签出源代码进行修改时进行验证。使用的散列算法是： •（示例）SHA-256 •（示例）SHA-512 •（示例）MD5＆＃34;
如果您查看http://en.wikipedia.org/wiki/Comparison_of_revision_control_software，请参阅＆＃34;功能＆＃34;表格中，有一列用于＆＃34;签名修订＆＃34;并且perforce部分说＆＃34;是＆＃34; ......有人认为它有某种形式的支持。
这是否可以使用提交触发器之前/之后完成？在提交前生成一个哈希，坚持（以某种方式）并检查它在我们在提交后创建的那个？我只是在5分钟前才了解perforce触发器，所以我甚至不知道他们是否会支持这个概念（不确定如何在触发事件中保持一个值，不确定我是否可以在结账前访问文件内容触发等）。
答案 0 :(得分：1)
实际上，提交给Perforce的文件具有在提交操作期间计算的加密摘要。
每次将文件同步到任何客户端工作站时，都会检查这些文件摘要，并且还可以使用＆＃39; p4验证＆＃39;直接在服务器上重新验证这些文件摘要。用于确定文件内容是否已直接在服务器上受到攻击的命令。
您还可以通过运行各种命令来观察这些摘要;例如，你可以运行＆＃39; p4 fstat -Ol //depot/src/file.c'并查看“摘要”＆＃39;字段。
顺便说一下，＆＃34; PA-DSS的要求是什么＆＃34;？这对我来说是一个新的缩写。
这里有关于Perforce服务器维护的文件摘要的一定数量的信息：
如果问题涉及维护代码审核流程的记录，要确定已审核的代码更改是实际提交的代码更改，您可以开发基于Perforce＆＃34;搁置＆＃的工作流程34;命令。
＆＃34; shelve＆＃34;最重要的方面。帮助这些工作流程的命令实际上在＆＃34;提交＆＃34;命令：＆＃34; p4 submit -e＆＃34;直接在他们的服务器上提交一个架子，没有从用户的工作站重新传输文件。
因此，如果您的流程仅允许提交-e＆＃39;提交到您的存储库的某些受保护区域，仅允许提交已经审核的货架（这些将是您通过更改提交触发器强制执行的操作），然后您可以放心使用该代码已审核的是已提交的代码。