[guardian-dev] NetCipher Book Chapter, and HTTP Stack Integration

Mon Mar 21 11:09:47 EDT 2016

Mark Murphy:
> On Mon, Mar 21, 2016, at 10:27, Hans-Christoph Steiner wrote:
>> Can you explain the rationale behind using the StrongBuilderBase?
> 
> It represents the common builder code for all four concrete builders.
> 
> Two of the builders (StrongConnectionBuilder for HttpURLConnection and
> StrongVolleyQueueBuilder for Volley) just extend StrongBuilderBase.
> 
> One of the builders (StrongHttpClientBuilder for HttpClient) uses
> delegation, because HttpClient already has HttpClientBuilder. Rather
> than require two separate builders, StrongHttpClientBuilder extends
> HttpClientBuilder (to inherit stock HttpClientBuilder behavior).
> However, StrongHttpClientBuilder also implements the StrongBuilder
> interface and forwards all those methods to a StrongBuilderBase
> instance. This allows StrongHttpClientBuilder to offer both APIs
> (HttpClientBuilder and StrongBuilder) in one class with minimal code
> duplication.
> 
> One of the builders (StrongOkHttpClientBuilder for OkHttp3) should take
> the approach used for StrongHttpClientBuilder. It doesn't -- once again,
> it was a deadline thing for the book release.

The Builder pattern makes perfect sense with HttpClient, where that
pattern is already used.  It feels heavy for HttpURLConnection.

Also, about the interface, I think that's a very Java-ish approach, and
I could see some devs preferring that.  I guess that's needed for things
like OkHTTP which also work in plain Java, and not only in Android.
I've been thinking mostly that devs will implement their own
BroadcastReceiver and pass that it, but I guess that doesn't work on
OkHTTP.  If we're sticking all this stuff in NetCipher anyway, then
going the full Android approach is more appealing to me. I'd be fine
with a generic Java style for getting stuff fully integrated into OkHTTP.

>> 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
> 
> OK. Note that pulling the chboye stuff out will resulting a breaking
> change for all existing NetCipher users (unless netcipher depends on
> netcipher-chboye, which I would not recommend). Otherwise, this seems
> reasonable.

I think we have to break chboye in the way in order to have a common
netcipher library.  Perhaps we call this NetCipher 2.0 to make it clear
that there is breakage.

> From a GitHub repo standpoint, I presume that this means that my
> netcipher-hurl code moves into libnetcipher.

Yeah, we'd move all that stuff into the netcipher github repo.

>> 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.
> 
> That shouldn't be too bad now, at least if you're willing to stick with
> instrumentation testing (i.e., running in Android) and not unit testing
> (i.e., running on the JVM).

The HURL tests are already android.test.InstrumentationTestCase.  The
TLSPretenseClientActivity test class is unmaintained.  We can just
remove it if it is in the way.

> There aren't too many resources in this code. If we move them all
> elsewhere (e.g., assets, simple Java constants), we can make JARs
> available for download for those who are not using artifact-based build
> systems, such as legacy Android Eclipse development. We would need to
> document what beyond the JARs would be needed.

This approach is quite important, in my opinion.  Keeping everything as
only jars whenever possible, even avoiding AARs, saves lots of people
headaches and keeps deployment flexible.

>> 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... But I worry about the lack of tests and the maintenance.
> 
> That's your call. Note that in the N Developer Preview, it appears that
> apps can supply their own CA keystore declaratively (manifest entry
> pointing to XML metadata resource pointing to the keystore). I haven't
> played with that yet, but it's on my to work on in the next month.

Interesting.  Perhaps NetCipher could imitate that API then.  I think
that this custom keystore approach could be simple and maintainable if
we provide a class or script that will automatically generate the custom
keystore for users.  Even better, it would happen automatically from
gradle.  I see it like this:

* download keystore from Debian or Mozilla
* download the certificate app's provided hostname
* read the CA from that certificate
* prepare a custom keystore by grabbing only that CA from the
Debian/Mozilla keystore
* include that keystore in the app

.hc

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556