[opensource-dev] Review Request: STORM-1112 Support SOCKS 5 proxy in the viewer (take 2)

Monty Brandenberg monty at lindenlab.com
Tue Jul 12 23:50:51 PDT 2011


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/374/#review869
-----------------------------------------------------------


This finishes the first-pass review.  Not ready to ship yet.


indra/llmessage/llproxy.h
<http://codereview.secondlife.com/r/374/#comment894>

    Extra semicolon.



indra/llmessage/llproxy.cpp
<http://codereview.secondlife.com/r/374/#comment898>

    Prefer sizeof(password_reply), it avoids
    an unverifiable duplicated name/type
    binding.
    



indra/llmessage/llproxy.cpp
<http://codereview.secondlife.com/r/374/#comment901>

    The security minded would do several things
    at this point:
    
    1.  Scribble over password_auth before deleting it.
    
    2.  Scribble over mSocksPassword now that
    we've used it once.
    
    3.  Narrow the window from retrieving the
    password to this point as much as is
    practical.
    



indra/llmessage/llproxy.cpp
<http://codereview.secondlife.com/r/374/#comment899>

    See above.



indra/llmessage/llproxy.cpp
<http://codereview.secondlife.com/r/374/#comment897>

    Whitespace.



indra/llmessage/llproxy.cpp
<http://codereview.secondlife.com/r/374/#comment900>

    Is anyone doing validation of the strings?
    What happens if they're over 255 bytes?
    Invalid utf-8 encodings?  Do we care?  Are
    these in the test plan?



indra/llmessage/llproxy.cpp
<http://codereview.secondlife.com/r/374/#comment896>

    This block isn't reachable due to 
    preceding 'if' clause.  Also leaves
    'rv' set to success if it failed to 
    write all data for some reason.



indra/llmessage/llproxy.cpp
<http://codereview.secondlife.com/r/374/#comment895>

    Possible to have legal short reads here.



indra/llmessage/net.cpp
<http://codereview.secondlife.com/r/374/#comment902>

    Does net.cpp really need llproxy.h?  I
    don't think it should.



indra/newview/app_settings/settings.xml
<http://codereview.secondlife.com/r/374/#comment914>

    Is this still storing username and
    password in the settings file?
    
    Add this to the test plan.
    



indra/newview/llfloaterpreference.cpp
<http://codereview.secondlife.com/r/374/#comment903>

    Whitespace (indentation & if)
    
    Also, this thing is now 'prefs_proxy',
    yes?
    



indra/newview/llfloaterpreference.cpp
<http://codereview.secondlife.com/r/374/#comment904>

    whitespace



indra/newview/llfloaterpreference.cpp
<http://codereview.secondlife.com/r/374/#comment905>

    Defensive programming on socksAuth being NULL?



indra/newview/llstartup.cpp
<http://codereview.secondlife.com/r/374/#comment906>

    This may be too late.  GPU/features table
    has already been loaded by HTTP, I believe.
    
    Then there's webkit and our browser.
    
    Need to check on this.  (And test plan it.)
    



indra/newview/llstartup.cpp
<http://codereview.secondlife.com/r/374/#comment907>

    There are a bunch of common strings shared
    between this and the UI code ("Web",
    "BrowserProxyEnabled", etc.) that feel
    like they should be #defines somewhere.
    Somewhere not llproxy.h but application/
    ui/interface oriented.
    
    



indra/newview/llstartup.cpp
<http://codereview.secondlife.com/r/374/#comment908>

    Left over from the previous review, I
    think, here's a place where the logic
    can be unsynchronized.  'use_socks_proxy'
    is actually identical to the 'else if'
    test above, isn't it?  These should be
    consistent if I'm reading it correctly.



indra/newview/llstartup.cpp
<http://codereview.secondlife.com/r/374/#comment909>

    All the credential code wants its own
    home, doesn't it?



indra/newview/llstartup.cpp
<http://codereview.secondlife.com/r/374/#comment911>

    What does 'payload' do?



indra/newview/llstartup.cpp
<http://codereview.secondlife.com/r/374/#comment910>

    I'd put this early return after startProxy().
    We're in notification code here, long after
    we know we're okay.
    
    And what happens with an unrecognized status
    code?



indra/newview/llxmlrpctransaction.cpp
<http://codereview.secondlife.com/r/374/#comment912>

    These combined with 328 feel like they
    should be a utility method on mCurlRequest.
    
    Or the whole block a method or
    free function in LLProxy...
    



indra/newview/llxmlrpctransaction.cpp
<http://codereview.secondlife.com/r/374/#comment913>

    Whitespace.



indra/newview/skins/default/xui/en/panel_preferences_setup.xml
<http://codereview.secondlife.com/r/374/#comment915>

    Bad name?
    



indra/newview/skins/default/xui/en/panel_preferences_setup.xml
<http://codereview.secondlife.com/r/374/#comment916>

    Bad 'label_selected' value?


- Monty


On July 12, 2011, 11:20 a.m., Log Linden wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/374/
> -----------------------------------------------------------
> 
> (Updated July 12, 2011, 11:20 a.m.)
> 
> 
> Review request for Viewer, Oz Linden, Monty Brandenberg, and Stone Linden.
> 
> 
> Summary
> -------
> 
> This is a continuation of Robin Cornelius's SOCKS 5 contribution, shown in https://codereview.secondlife.com/r/232/ .  I have tried to address all of the comments on that code review and do as much cleanup as possible. The diff includes everything that was submitted by Robin, as well as my work.
> Major changes since I started working:
> * Changed SOCKS 5 proxy control channel to use the existing LLSocket class, which is a thin wrapper around APR sockets.
> * Worked with the Linden Lab UX team to revamp the proxy controls.
> * Proxy credentials are now stored in the LLSecAPI password storage, which is the same that is used for users' Second Life Credentials instead of as being stored in the clear as a preference.
> 
> 
> This addresses bug STORM-1112.
>     http://jira.secondlife.com/browse/STORM-1112
> 
> 
> Diffs
> -----
> 
>   indra/llmessage/CMakeLists.txt c7a4b7a24e05 
>   indra/llmessage/llcurl.cpp c7a4b7a24e05 
>   indra/llmessage/lliosocket.h c7a4b7a24e05 
>   indra/llmessage/lliosocket.cpp c7a4b7a24e05 
>   indra/llmessage/llpacketring.h c7a4b7a24e05 
>   indra/llmessage/llpacketring.cpp c7a4b7a24e05 
>   indra/llmessage/llproxy.h PRE-CREATION 
>   indra/llmessage/llproxy.cpp PRE-CREATION 
>   indra/llmessage/net.h c7a4b7a24e05 
>   indra/llmessage/net.cpp c7a4b7a24e05 
>   indra/llui/llfunctorregistry.h c7a4b7a24e05 
>   indra/newview/app_settings/settings.xml c7a4b7a24e05 
>   indra/newview/llappviewer.cpp c7a4b7a24e05 
>   indra/newview/llfloaterpreference.h c7a4b7a24e05 
>   indra/newview/llfloaterpreference.cpp c7a4b7a24e05 
>   indra/newview/llloginhandler.cpp c7a4b7a24e05 
>   indra/newview/llpanellogin.h c7a4b7a24e05 
>   indra/newview/llsecapi.h c7a4b7a24e05 
>   indra/newview/llstartup.h c7a4b7a24e05 
>   indra/newview/llstartup.cpp c7a4b7a24e05 
>   indra/newview/llviewerfloaterreg.cpp c7a4b7a24e05 
>   indra/newview/llxmlrpctransaction.cpp c7a4b7a24e05 
>   indra/newview/skins/default/xui/en/floater_preferences_proxy.xml PRE-CREATION 
>   indra/newview/skins/default/xui/en/notifications.xml c7a4b7a24e05 
>   indra/newview/skins/default/xui/en/panel_cof_wearables.xml c7a4b7a24e05 
>   indra/newview/skins/default/xui/en/panel_preferences_privacy.xml c7a4b7a24e05 
>   indra/newview/skins/default/xui/en/panel_preferences_setup.xml c7a4b7a24e05 
> 
> Diff: http://codereview.secondlife.com/r/374/diff
> 
> 
> Testing
> -------
> 
> I've tested exclusively on Linux so far.  I'm working on a more extensive test plan that includes setting up a gateway with a restrictive firewall to verify that all traffic is going through the proxy. 
> 
> Test builds and screenshots of the changed UI elements are available from the project page, located here:
> https://wiki.secondlife.com/wiki/User:Log_Linden/Socks5Viewer
> 
> 
> Thanks,
> 
> Log
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110713/567592e5/attachment-0001.htm 


More information about the opensource-dev mailing list