我在 Windows 中生成了一个.tar.gz文件，其中包含一些通过 Linux 设备更新固件的文件。更新失败，同事提到问题是因为.tar.gz没有Linux signing它期望的。。。这真的是这样吗？我不得不假设它是，但我相当好奇。我知道文本/xml 文件需要有Unix LF EOL约定 vs Windows CRLF，我怀疑我的初次尝试失败是因为我最初忘记了这一点。
.tar.gz这里的主要问题是，在 中创建的文件是否Windows与在 中创建的文件相同Linux，如果相同，那么如何以Windows Environment编程方式检测/修改此信息？。当我自己的研究似乎没有相关数据时，Windows 中是否有一种编程方式可以检测/强制 .tar.gz 文件为“ Linux Signed”，或者这是我同事的误解？（在 Google 上搜索任何相关内容.tar.gz都会Windows产生许多针对这个特定问题的无用文章。...
以下信息是我在 Windows 操作系统中使用不同文件时所能找到的最佳信息。。。
我在 7-Zip 中制作了初始包，其中的文件在嵌入的 .tar 中显示为 -rwxrwxrwx，而 .tar 本身显示FAT为Host OS
接下来，我使用新命令重新制作了包Windows Tar（太棒了！！）7-Zip 显示里面的文件为，-rw-rw-rw-所以我假设它们是可读写的。使此过程正常运行所需的所有其他约定都匹配。除了权限之外，唯一的区别是Host OS显示方式不同Unix。
然后我的同事给了我一个由我们的软件团队制作的实用程序，它生成的软件包与我制作的几乎相同。但有一些不同 - 里面的文件-rw-r--r--和Host OS列出的内容与FAT7-Zip 一样。
尽管我的第二次尝试“成功”了，但仍然发生了一些奇怪的问题，他再次坚持说这是因为 .tar.gz 文件不是Linux Signed。。。我在这里说的话有点误导，但我想确认这是否真的是一个问题，如果是这样，如何以编程方式检测/强制文件.tar.gz可以通过或来Linux Signed? 完成？我对/和相当熟悉，但其他的还不多。CMDPowerShellVB.Netc#Batch
根据同事的说法，第一个文件是“只读”的 - 假设这是因为它CRLF EOL在 Linux 系统中，并且我相信主要问题就是这个。我还假设“奇怪”的事情发生是因为我试图再次推送同一个包。（我相信我们的系统没有内置机制来检查它是否与之前和之后的版本相同，所以它永远不会完成......）
答案1
很难知道你的同事是否把某个东西的名字说错了，或者根本就错了。
“签名”几乎肯定是指对某物进行数字签名，而为此需要有一个秘密不会分发给所有人的密钥。
Linux 没有数字签名来证明它来自 Linux。如果存在这样的东西，它就需要放在每台 Linux 机器上，因此不是秘密的，因此完全没用，也不能证明什么。没有可靠的方法可以确定 tar 文件来自 Linux 机器。
由于您正在讨论固件更新，因此硬件可能希望内容由第三方进行数字签名。也就是说，硬件可能会拒绝接受任何未经硬件供应商签名的固件。在这种情况下，硬件供应商将持有密钥，您将无法对其进行修改。这是我对您同事的评论最接近的猜测。坦率地说，这听起来不像是您的同事的意思。