packages icon indicating copy to clipboard operation
packages copied to clipboard

Signed Flat Distributions with Referenced HTTP/S Packages Fail to Run

Open zackbennis opened this issue 6 years ago • 6 comments

When building a flat distribution with referenced https packages, it will work fine if the package is not signed, but if I sign the package, I get the error, "installer.pkg can’t be installed because its digital signature is invalid. The package may have been corrupted or tampered with. Get a new copy of the package and try again."

I also tried the 'productsign' command line tool on the unsigned pkg, which produced the same result.

I do not get this issue when I convert to a bundle, but I would prefer to deploy this as flat distribution, if possible.

zackbennis avatar Jan 30 '19 22:01 zackbennis

are you signing it with an application certificate or an installer certificate?

rudyrichter avatar Jan 30 '19 22:01 rudyrichter

Installer certificate.

zackbennis avatar Jan 30 '19 22:01 zackbennis

I should also mention that this particular distribution has around 40 included packages, 38 that are local and 2 referenced https packages. As a test, I removed the referenced https packages, and then ran a signed build with the remaining 38. The resulting pkg ran fine.

zackbennis avatar Jan 31 '19 14:01 zackbennis

It's not possible to use the signing feature when your distribution includes external packages (remote http(s) ones or local ones on other discs or a related directory).

Personally, I don't see how this could be dealt with in a secure way:

  • it's not possible to ensure that all the payloads, scripts and resources are the correct ones at the time of the signing.
  • there is/was an attribute to provide a hash value in the reference to the external package but if you think about it, this does not make sense as one of the points of having an external package is that you want to be able to modify it without having to update the distribution.
  • if you are referencing raw packages produced by another entity (and possibly signed with a certificate other than the one used to sign the distribution), it's not possible to verify it against the identity used to sign the distribution.
  • maybe you could add the public certificate for the raw packages above at the time of the signing. But considering this does not even work with packages using the same certificate as the distribution, this is probably not the biggest issue.

packagesdev avatar Feb 11 '19 00:02 packagesdev

@packagesdev - That makes sense. It is a little frustrating, since I can have a pre/post-installation script in a signed pkg that curls another pkg and runs it, but I understand the reason for it. You can mark the issue closed if there won't be any further action on this.

zackbennis avatar Feb 15 '19 13:02 zackbennis

edit: I forgot I had already put a comment in here and had an old tab open without my most recent comment. Sorry for the spam!

@packagesdev - That all makes sense, and I understand the reason for it. However, I could (and do) have signed packages that curl another pkg from a remote source and installs that pkg on the target using a pre/post installation script.

I don't think that justifies exploring a solution for this issue, but the end result is still technically possible.

Please mark as closed if there won't be any further investigation into this, and thanks for building and maintaining such a great application!

zackbennis avatar Feb 20 '19 21:02 zackbennis