This week, I was first to arrive for the meeting and it was Rob who forgot, in this case to send the meeting request the day before the meeting. Nonetheless we had a quorum and triaged six issues.
Bug 4971 | XmlFile is improperly changing escaped text in attributes reports that using XmlFile causes entities in the target XML file to be replaced. XmlFile uses the wizened MSXML parser so is limited to its behavior—unless, of course, someone wanted to rewrite the XML custom actions to use a different parser, of course. We opened the issue in WiX v3.x for investigation.
Bug 4970 | Need to install the WiX toolset twice reports a failure installing WiX v3.10.1 on Windows XP. While the now-unsupported Windows XP isn't a target for developers using WiX itself, the installer shouldn't fail, so we requested logs for future follow-up.
Bug 4967 | Password isn't always hidden notes that Burn obfuscates the values of hidden properties while logging, it doesn't do so if your bootstrapper application handles hidden properties using a syntax other than NAME=VALUE
. Burn can't know about all possible syntaxes, so this isn't something that's feasible to implement, so we resolved this request with the suggestion that the user could open a new request to suppress command-line logging entirely.
Bug 4966 | Apparently unnecessary duplicated #define statements shows some sloppiness in the COM+ extension custom action code. Though not as severe as first reported, there is indeed some duplicate code there, so we opened the issue in WiX v3.x if someone wanted to do a quick scrubbing.
Bug 4956 | ExecXmlConfig, ExecXmlFile and ComPlusInstallExecute CAs expose sensitive data in log file came back this week as the reporter commented that the workaround (explicitly marking properties as hidden) didn't prevent MSI logging custom action data during scheduling. That's sadly true and why a total fix requires also marking the custom actions with the Hidden Target flag.
Bug 4943 | bootstrapper UpdateReplace with perUser InstallScope updates incorrectly was still open for the reporter to provide logs to better understand the problem. We didn't get logs but decided, as he wasn't there to defend himself, that Jacob would be the best person to see if his change in Burn v4.0 is related to this report.
As we mentioned last week, there was a report of a potential security vulnerability in WiX v3.10.1. A couple of us at FireGiant investigated the report, came to understand that there is a potential security vulnerability, and developed a fix to mitigate it. We're continuing the process of responsible disclosure and working with Microsoft on the issue.