Sebastian Lackner sebastian@fds-team.de writes:
The MachineGuid registry key should exist even without calling CryptAcquireContextW. Optionally we could remove the remove the corresponding code from advapi32 afterwards.
This doesn't need to run at every boot, so you can probably stick it into the registration of some crypto dll like wintrust. And please also remove the advapi32 code.
On 11.06.2015 08:24, Alexandre Julliard wrote:
Sebastian Lackner sebastian@fds-team.de writes:
The MachineGuid registry key should exist even without calling CryptAcquireContextW. Optionally we could remove the remove the corresponding code from advapi32 afterwards.
This doesn't need to run at every boot, so you can probably stick it into the registration of some crypto dll like wintrust. And please also remove the advapi32 code.
I'm not sure if its a good idea to remove the advapi32 code. The behaviour that CryptAcquireContextW re-creates the MachineGuid key was even tested explicitly back then (see http://source.winehq.org/git/wine.git/patch/4c984e089a892a49e234bc09a62a2fe3... ), maybe because a specific app was depending on this behaviour. The same test was later removed because it caused test failures on wow64 machines, but non-wow64 machines behave basically all identical: http://newtestbot.winehq.org/JobDetails.pl?Key=14628. Do you think we should just ignore these tests, or should I add them back to justify why the advapi32 code stays there? Also, does this change your opinion regarding where to create the MachineGuid? Having code duplication in advapi32<->wineboot might be better than in advapi32<->wintrust.
Best regards, Sebastian
Sebastian Lackner sebastian@fds-team.de writes:
I'm not sure if its a good idea to remove the advapi32 code. The behaviour that CryptAcquireContextW re-creates the MachineGuid key was even tested explicitly back then (see http://source.winehq.org/git/wine.git/patch/4c984e089a892a49e234bc09a62a2fe3... ), maybe because a specific app was depending on this behaviour. The same test was later removed because it caused test failures on wow64 machines, but non-wow64 machines behave basically all identical: http://newtestbot.winehq.org/JobDetails.pl?Key=14628. Do you think we should just ignore these tests, or should I add them back to justify why the advapi32 code stays there? Also, does this change your opinion regarding where to create the MachineGuid? Having code duplication in advapi32<->wineboot might be better than in advapi32<->wintrust.
I forgot that we had this test at some point. So yes, it can stay in advapi32, but then there's no reason to duplicate anything, you can simply call CryptAcquireContextW from wintrust dll registration.
-
Alexandre Julliard -
Sebastian Lackner