Linux/BSD distribution mirrors don't control the package signing keys, maintainers do. Similarly, Google doesn't possess the ability to push out updates for third-party apps, without fundamentally redesigning the OS with a platform update, because the signing keys are owned by the app developers, and the existing OS rejects updates signed with different keys. In both of these situations, the key owners lack the ability to selectively push out signed updates, unless they also control the distribution infrastructure.
No, there's no effective difference between those examples, apart from maybe post mortem analysis. It's also a poor method of key discovery, as hueving said.
It doesn't take ridiculous confidence to analyze shell scripts. In the hundreds of scripts I have read, few were more than 100 lines long. It shouldn't take more than 60 seconds (probably 30 or less) to mentally build a list of all possible operations a short script can perform. Bourne shell scripts don't have much room to hide surprising behavior, and when they do, it immediately stands out. If they are permanently installed, and invoked later by other parts of the system, then they may need more probing, but we're talking about installation scripts.
.deb and .dmg can be easily extracted. The former is just an `ar` archive containing tarballs, which you can (and should) extract to read the install scripts. (.dmg specifics escape me, since I only dealt with them one time, years ago.)
Binary code isn't inscrutable. Some good tools for this are, among many, many more, IDA, Hopper, and radare2. How long this takes depends on what your goals are, how comprehensive you are, and the program complexity. I don't think I've yet spent years on one project, fortunately, but the months-long efforts, for undoing some once-prominent copyright protection systems, were pretty brutal. Smaller programs have taken me just several hours to appropriately examine.
> there is no intrinsic reason why code from one vendor ... should be more or less secure that from the OS developer
If you're writing a cross-platform application, it's often easier to be confident in platform-agnostic parsing code that uses the platform sandboxing primitives, versus yielding parsing to the operating system, which may decode in a different execution context, and be less secure compared to the application security policy.
您应该对 PGP 密钥进行额外的验证，要么通过参加密钥签名聚会（2018 年谁这样做？），检查您已经信任的人的签名，要么比较尽可能多的带外信息。
从头开始创建一个可信的密钥环并不难，这取决于 3 个网站中只有 1 个是合法的。例如：
kernel.org：ABAF11C65A2970B130ABE3C479BE3E4300411886 Linus Torvalds <[email protected]>
marc.info：647F28654894E3BD457199BE38DBBDC86092693E Greg Kroah-Hartman <[email protected]>
thunk.org：3AB057B7E78D945C8C5591FBD36F769BC11804F0 西奥多·曹 <[email protected]>
所有密钥均经过交叉签名，如 gpg2 --list-signatures 所示。
如果这听起来很麻烦，那是因为事实确实如此，而且 GPG 还可以做得更好。
具有讽刺意味的是，如果您无法获取开发人员的公共签名密钥，并且没有可用的受信任存储库，那么最好直接从他们的网站安装软件。如果您可以获得他们的签名密钥，最好不要直接从他们的网站安装软件，以避免选择性分发攻击。有点不直观。