New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug in BVariantCopy() in src/burn/engine/variant.cpp #4609
Comments
Bug reproduces on three separate installers. Bundle installs fine, but attempts to Repair, Uninstall, or Upgrade are met with an access error when a connection string variable marked with the Hidden attribute is accessed. The Hidden variable has a Value attribute for a default. Workaround was to remove the Hidden attribute. Less than ideal, but it will work for now.
|
|
WiX v3.9.1208.0, a candidate for the WiX v3.9 R2 servicing release with this fix, is now available. It's not publicly visible on the list of weekly releases but you can get the installer at http://wixtoolset.org/downloads/v3.9.1208.0/wix39.exe. Please take a look and see if that release fixes your problem. If we don't hear back by 21-Jan, we plan on releasing v3.9 R2 shortly thereafter. |
I have performed the following tests:
2A) Validate Repair with Unmodified Bundle 2B) Validate Uninstall with Unmodified Bundle
Previously, I would see signs of the bug on repair, uninstall, and upgrade. I have not been able to replicate, so 1208 (Beta R2) looks like a fix.
|
|
There's really two bugs here, with the same root cause.
Bug #1: If you declare a variable as hidden and supply a default value (even if it is the empty string) you cannot change the variable's value (either from the command-line or from a BA) without incurring an error when you subsequently try to retrieve it (including when serializing from the UI engine to the Apply engine).
Bug #2: If you don't supply a default value to a hidden variable, it will actually be stored for most of its life in plaintext (it is encrypted and immediately decrypted).
The problem occurs because BVariantSetEncryption() assumes that the variant passed is correctly marked as to whether it is already encrypted or not, and that the fEncrypt flag is a "command", while what BVariantCopy() effectively passes to it is the opposite (in almost every case pSource is not encrypted).
What that method should instead do is preserve the value of pTarget->fEncryptValue, set pTarget->fEncryptValue = pSource->fEncryptValue, then pass the preserved value from pTarget as the "command" flag to BVariantSetEncryption(). That would result in the desired behavior in all cases.
The workaround for the failure to retrieve the "hidden" values is to never set a default value in the bundle authoring.
There is no workaround for the plaintext in memory storage of the variable's value.
The text was updated successfully, but these errors were encountered: