Re: [guardian-dev] guardian-dev Digest, Vol 69, Issue 17

[Jay Pozo]

Sorry for the weird message everyone, I'm not sure what happened. Investigating.

> Date: Thu, 24 Mar 2016 09:26:00 -0700
> From: Jay Pozo 
> To: guardian-dev@lists.mayfirst.org
> Subject: [guardian-dev] (no subject)
> Message-ID:
>   <1458836760.2809452.558743698.6dc1a...@webmail.messagingengine.com>
> Content-Type: text/plain
> 
> I have am will to live the like wife and kids daughter at all times and dream 
> rest life rest assured
> 
> 
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

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

[Mark Murphy]

On Fri, Mar 25, 2016, at 05:36, Hans-Christoph Steiner wrote:
> * why did you use the custom WeakSet class rather than just a plain Set?

To help prevent memory leaks, in case clients fail to unregister their
callbacks.

> * keep things as a JAR as much as possible, not an AAR, i.e. by avoiding
> string resources, etc.  I find it makes the library a lot easier to
> deploy in a variety of situations (ant!).

What do you want to do about the keystore?

In my sample, I moved that to an asset, as I was having problems
referencing the raw resource across library module boundaries. However,
if you're aiming to change packaging to be a JAR instead of your current
AAR, then the keystore cannot be either a raw resource or an asset.

Options include:

- Remove the keystore references from my code entirely, with an eye
towards revamping all this (e.g., your proposed "make it look like
Android N" approach).

- Leave the keystore references more or less as-is, and tell users of
the library that they need to put the keystore in the proper spot in
assets/ (i.e., the old SQLCipher approach, before they switched to the
AAR).

- Add something (to OrbotHelper?) that exposes the keystore from raw
resources via a Java API, then have my code use that API, and leave the
raw resource where it is, requiring AAR packaging.

- Attempt to switch this to an old-style Java JAR resource (note: not
recommended, as I worry that the Android tools team will eventually
break that).

And there may be other options that I'm not thinking of, as I just woke
up.

> If you want to do it via pull requests, I'd do it one per HTTP API, and
> another for the Orbot stuff.

I'm not aware of other options for getting my stuff into your repo,
other than pull requests, and possibly butterflies.

https://xkcd.com/378/

Thanks!

-- 
Mark Murphy (a Commons Guy)
https://commonsware.com | https://github.com/commonsguy
https://commonsware.com/blog | https://twitter.com/commonsguy
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

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

[Hans-Christoph Steiner]

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.  Ideally, it
>> would all fit into the existing TlsOnlySocket* stuff, without the need
>> for a Sni-specific subclass.
> 
> I am not completely clear where the rest of that thread left us. I am
> assuming that you want to go ahead with the HttpURLConnection code per
> your statement above.
> 
> If so:
> 
> - Just to confirm, you want this code to go into libnetcipher?

yes!


> - Is the package name that I chose (info.guardianproject.netcipher.hurl)
> OK, or do you want that changed?

As far as I understand it, the HttpURLConnection-specific stuff will
just be folded into TlsOnlySocket*, so that will stay where it is.  Then
the other stuff is more general, like StrongBuilderBase.java, so it
could go into i.g.n.client, with the Orbot stuff going into i.g.n.proxy.


> - Is the API that I am using basically acceptable to you, or do you want
> a major overhaul? Minor changes we can do after getting the code in your
> repo, but if you're looking for what might involve a top-to-bottom
> rewrite, I'd prefer to tackle that separately.

I think things are ready to be merged with the existing general API.  I
might end up changing things a bit to put the LocalBroadcastManager
style on equal footing as the Interfaces and Callbacks API.  But I'll
first have to figure out how to do that well.

* why did you use the custom WeakSet class rather than just a plain Set?

* keep things as a JAR as much as possible, not an AAR, i.e. by avoiding
string resources, etc.  I find it makes the library a lot easier to
deploy in a variety of situations (ant!).


> - What sort of pull request granularity do you want? Fewer larger ones
> or many smaller ones? I'm a pull request n00b, so I apologize if the
> answer to that question should be obvious.

If you want to do it via pull requests, I'd do it one per HTTP API, and
another for the Orbot stuff.


> - Do you want me to open a tracking issue for this work anywhere (and if
> so, where)?

We've been discussing here already, so we can just stay on this list.


> - Is there anything else that I should know before working on this and
> lobbing pull requests over to you?

I think we're ready to go!

.hc

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org