I stand corrected, my testing was done prior to signing my external CABS. This is in fact a bug as far as I can tell.
Specifically in the 3.8 branch, in the src/wix/Inscriber.cs InscribeDatabase @~ 217, we are blindly creating a new table instead of merging the table. I believe the proper approach would be to create the table, merge in all the existing certificates, and then proceed to add the signing data to the MSI per CAB. The down side (of this approach) is if a MSI is signed multiple times with different certificates, you could have "certificate bloat" with multiple unused certificates in the table. I suppose one could prune the table before committing if the certificate is in the table but isn't referenced via the MsiDigitalsignature table or the MsiPatchCertificate table, but I don't know enough to be certain that the certificate couldn't be referenced elsewhere. Please log this defect. -----Original Message----- From: Georg von Kries [mailto:g...@creativbox.net] Sent: Monday, July 08, 2013 10:56 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] PatchCertificates element and Insignia.exe Hi David, Looking at the Inscribe.cs source code, there is no entry added to the MsiPatchCertificate table. So no, it's not doing everything for me. Kind regards, Georg von Kries -----Ursprüngliche Nachricht----- Von: David Watson [mailto:dwat...@sdl.com] Gesendet: Montag, 8. Juli 2013 17:24 An: General discussion for Windows Installer XML toolset. Betreff: Re: [WiX-users] PatchCertificates element and Insignia.exe Does it work if you remove the PatchCertificates elements? I.e. is insignia hand holding you and doing everything so you do not need to? -----Original Message----- From: Georg von Kries [mailto:g...@creativbox.net] Sent: 08 July 2013 15:54 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] PatchCertificates element and Insignia.exe Hi Jacob, signing is indeed working without any problem. But if you have a <PatchCertificates> element in your MSI, signing the MSI with insignia (actually it is done by an MSbuild target) will change the included certificates in the MsiDigitalCertificate table. The following snipped (e.g. in product.wxs) will create entries in the MSI tables MsiDigitalCertificate and MsiPatchCertificate: <PatchCertificates> <DigitalCertificate Id="MyCertificate" SourceFile="xyz.cer" /> </PatchCertificates> The certificate will get the identifier "MyCertificate" which is referenced in MsiPatchCertificate. If you are now using external cabs and sign the MSI, the "MyCertificate" is removed from the MsiDigitalCertificate table and a new one is added for any external cab. They will get the certificates thumbprint as the identifier but MsiPatchCertificate is still referencing "MyCertificate" which will break the MSI IMHO. It is currently not an issue for me, as I have no plans to use patches in the near future. But I was asking myself if this is an bug or if I did something wrong. Thanks for your help, Georg -----Ursprüngliche Nachricht----- Von: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] Gesendet: Montag, 8. Juli 2013 16:38 An: General discussion for Windows Installer XML toolset. Cc: wix-users@lists.sourceforge.net Betreff: Re: [WiX-users] PatchCertificates element and Insignia.exe I've been signing a msi and its external cabs without issue. Can you provide the steps you are using to see if I can spot anything? On Jul 8, 2013, at 9:30 AM, "Georg von Kries" <g...@creativbox.net> wrote: > Hi all, > > > > I've been using a <PatchCertificates> element in our installers for > several years now, just in case we want to provide a patch and allow > UAC patching. > After switching to use external cab files, I have mentioned that this > is broken. > > > > When using external cabs, singing them and inscribing the digital > certificate via Insignia.exe, it will remove the certificates provided > in the PatchCertificates element from the MsiDigitalCertificate table > and add a new entry with the certificate used for singing the cab > files. This is actually the same certificate (in our case), but the > identifier in the MsiDigitalCertificate table is being replaced. > Insignia (or actually the > Inscriber) will use the certificates thumbprint as the identifier. > This invalidates the foreign key in the MsiPatchCertificate table. > > Additionally I cannot just use the certificate thumbprint as the > identifier in the <DigitalCertificate> element, because it might > start with a number which makes it invalid as an identifier. > > > > Therefore I think there are two bugs in the Inscriber. > InscribeDatabase() > method: > > 1. It should not remove existing certificates from the > MsiDigitalCertificate table > > 2. The used identifier can be invalid, if the certificate thumbprint > starts with a number. E.g. an underscore should be added at the > beginning > > > > Am I missing something or is this a known limitation/bug? > > > > Kind regards, > > Georg von Kries > > > > > > ---------------------------------------------------------------------- > -------- This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users ---------------------------------------------------------------------------- -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ---------------------------------------------------------------------------- - - This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. ---------------------------------------------------------------------------- -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
