Update PostBuildSigning.md

Documentation/CorePackages/PostBuildSigning.md

@@ -37,6 +37,10 @@ The process works as follows:
 
 The crux of the SignTool algorithm is determining the certificate for a specific file. *Side note: Certificates are associated with a specific file name or file extension, though they cannot be associated with a specific path. For instance, 'foo/bar/baz.zip' is only dealt with as 'baz.zip'*. When dealing with a single repo, SignTool just interprets the signing info as applying to all files passed to it. A baz.zip found anywhere in the input file set is treated identically. When dealing with post build signing, it's possible that a foo.dll found in an sdk asset may actually come from the runtime, which may have indicated that *.dll get a different certificate. *So SignTool needs to track where foo.dll originally came from*. Did it come from the build of dotnet/runtime, or from dotnet/sdk? To do this, SignTool associates each input top level item to sign and the signing info for a build with a 'collision priority ID' This collision priority ID serves as a way to disambiguate the source signing information for a nested artifact. As each top-level asset is unpacked, the hash of each nested file is determined and looked up in a map. If the map already contains a file with the same name and hash, the collision priority ID's are compared. If the current one in the map is lower, the signing info for the existing file is used. Otherwise, the certificate information is recomputed based on the lower collision priority ID.
 
+## Post Build Signing a single repo vs full product
+
+Post build signing is intended to sign a full set of product inputs.  Given that some repos produce artifacts that repackage artifacts from other repos, the full graph of builds and dependent builds are required to *fully* sign artifacts.  If you only have the artifacts from an individual repo, then post build signing will sign what it can, given the information available.  If it is repackaging an MSI from another repo, and that repo's manifest / metadata are not available, then post build signing will sign the packaged artifact, but not its contents because it is unable to repackage an MSI without the light command package data from that dependent repo.  The result will be that signing validation would fail and properly report unsigned files.  It is up to the repo owner to investigate whether those unsigned files are valid, invalid, or should be ignored because they are the result of post build signing with partial input (false positives).
+
 ## Additional Information
 
 More information about the file types that are signed and the certificates used to sign them can be found here: