When I submitted the feature, I had no idea about how burn variables were 
implemented.  I just knew that my managed BA had a password in a SecureString, 
and that converting it to a System.String would not be secure.  The comment on 
the feature from triage was "Would really want this piped through to the 
engine. That might be breaking."  So when writing the WIP, I did a cursory 
check if burn was already zeroing out hidden variables, added that in with the 
SecureStringVariables, and submitted the new feature about encryption 
separately because it "might be breaking".
 
After starting to tackle the SecureZeroMemory stuff, it looks like that's 
actually going to be more work than encryption.  If you don't take "piped 
through to the engine" literally and allow the BA to send it unencrypted, then 
encryption will be really easy and self contained in variant.cpp.  Otherwise, 
we would need to add methods for the BA to send/receive encrypted values.  
Either way, looks like it shouldn't be breaking and I'll lump it in with 4299.  
This is a lot more work than I thought when I submitted the feature...
 
Date: Mon, 3 Feb 2014 00:07:44 -0500
From: b...@joyofsetup.com
To: wix-devs@lists.sourceforge.net
Subject: Re: [WiX-devs] WIP:4299


  
    
  
  
    On 02-Feb-14 23:35, Sean wrote:

    
      
      My problem with trying to make sure that variable
        values are encrypted during runtime and zeroed out when freed is
        that I'm not sure the encryption can be done in 3.x.  
    
    My assumption was that it would be transparent, decrypted when
    requested from the BA or referenced in manifest authoring. Do you
    see a problem where it wouldn't be?

    

    
      So I guess what it comes down to is whether to have
        SecureStringVariables even if the engine won't be encrypting
        what it receives.  The alternative would be creating yet another
        *Variables (StringPointerVariables?) so that the managed BA
        doesn't have to use a System.String.

      
    
    My concern is that the presence of the property implies something
    that won't be true until/unless it's backed by the engine.

    -- 
sig://boB
http://joyofsetup.com/
  


------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs                           
          
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs

Reply via email to