Mark Murphy: > On Mon, Mar 21, 2016, at 09:39, Hans-Christoph Steiner wrote: >> As for a plan for integrating this into NetCipher, I'd like to start >> with the HttpURLConnection first, especially the SNI stuff. > > Does "the HttpURLConnection" mean you want the StrongConnectionBuilder? > Or are you referring to something else? > >> As for OrbotInitializier, ideally that would be merged into OrbotHelper >> somehow. > > I am not aware of any conflicts there. IIRC, OrbotHelper is a basket of > static methods. > >> I see you made a StatusCallback interface. Is there any need >> to have separate Orbot status handling for each HTTP API? > > There isn't separate handling for each API. > > In my book sample code, the netcipher-hurl module serves double-duty as > the home for HttpURLConnection support and as a "common" module for > things like OrbotInitializer that are needed for all APIs. I didn't > anticipate a need for a "common" module when I started out, then ran > into deadline issues and elected to not try to separate that out. I > apologize for any confusion there. > > For formal integration into NetCipher, the following classes from > netcipher-hurl ideally should go into libnetcipher: > > - OrbotInitializer > - StatusCallback > - StrongBuilder > - StrongBuilderBase
Can you explain the rationale behind using the StrongBuilderBase? > as those are common to all four of the HTTP API integrations. The > remaining classes are specific to HttpURLConnection and could go in > libnetcipher or a separate artifact/module. The other three integrations > really need to go into separate artifact/modules, simply because they > depend upon third-party libraries (e.g., Volley), and you don't want to > force all NetCipher users to pull in all those dependencies. Yeah, we'll need to also do this for the existing ch.boye code there as well. I'm thinking that the maven artifacts should be called: netcipher (the common one with the HttpsURLConnection stuff too) netcipher-chboye netcipher-httpclient netcipher-okhttp3 netcipher-volley I imagine will want to entirely ditch the ant/eclipse stuff in netcipher.git at this point, and switch it all to gradle and Android Studio. I stuck with eclipse so far because it seemed really painful to get the JUnit test suite working with gradle+Android Studio. Also, I think we want to de-emphasis the custom keystore stuff. Maybe we should not even include it in the new APIs, just leave it as is in the ch.boye stuff. Perhaps it could end up being an easy approach to doing a form of pinning: only include the CAs that your app actually uses. But I worry about the lack of tests and the maintenance. > BTW, and FWIW, the sample code is now in my book's GitHub repo: > > https://github.com/commonsguy/cw-omnibus/tree/master/Internet/HTTPStacks Excellent :) .hc -- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556 _______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
