Design and implement a logins delivery mechanism for Lockbox

[mhammond]

We need to work out what delivery vehicle we use for lockbox. It seems ideal if we could do the same thing other android components do (ie, have the api in the android-components repo and built using the same approach as the fxa sandvich), but whatever we come up with it, needs to be documented (including documentation for updating it), agreed to by the lockbox team and a first version released.

[ncalexan]

I agree that we should do more or less as the existing Android components do, but I'd like us to explore figuring out what the shared functionality is before pushing the actual work into https://github.com/mozilla-mobile/android-components. The a-c, a-s, and mentat repositories all want to produce Android ARchives, so let's try to work out shared patterns.

Concretely, Mentat isn't testing its Android API (or iOS API, for that matter) in automation, let alone packaging it. I'll try to extract some of the a-c patterns for use in Mentat, which I think will also further this goal.

[ncalexan]

There are a few pieces of this that might look like dependency injection:

• making it easy for consumers (like Lockbox) to wire the log crate output to their own logging solution (Android's log, or Timber, or ...).
• allowing the Rust components to expose telemetry to consuming applications.

[ncalexan]

There are a few pieces of this that might look like dependency injection:

making it easy for consumers (like Lockbox) to wire the log crate output to their own logging solution (Android's log, or Timber, or ...).

If we're not interested in the Android ecosystem specifically, then this looks good.

[thomcc]

There are some unfortunate issues here like the fact that both fxa and sync can't bundle our own openssl so files (they collide). At the moment this isn't a huge deal, since we can assume that anybody using our sync stuff is probably also using fxa, but it's an annoying gotcha, especially since IIUC fxa doesn't need openssl on non-android platforms.

I'm just writing this as much for future reference as for anything else. (Really I don't think there's a situation where we get out of this without some tooling around rust code).

[ncalexan]

I just landed non-trivial work on packaging and publishing Andorid AARs for Mentat (https://github.com/mozilla/mentat/tree/fba378ee394cad7f373b1623f1a74dadc3999110), most of which should apply nicely to the logins API. I'll try to put that work on top of Thom's WIP now.

[ncalexan]

Hi folks, a little update on this. I started trying to build Thom's WIP with my Gradle plugin, and ran into lots of frustration because we depend on OpenSSL (for the Rust network stack, I'm told), which just isn't conveniently packaged for Android and JVM consumption. (By comparison, sqlcipher is conveniently packaged, and I'm confident that I can make the Rust builds use the provided AAR and JAR packages.)

I might be able to arrange for automation to package OpenSSL for consumption; or I might be able to get it in a convenient manner from the existing FxA client package, but that's where I'm at. More as I learn more.

[ncalexan]

Oh, this gets more and more fun. The FxA client needs OpenSSL libraries. So does sqlcipher. The easiest way to use SQL cipher on Android is to depend on the prepackaged AAR... which statically compiles the OpenSSL libraries into libsqlcipher.so. So we have an LTO/Megazord problem at the Rust level (two copies of the Rust stdlib!) and at the C level (two copies of OpenSSL!). Fun fun fun.

[rfk]

Closing this in favour of individual issues in "Logins API - v1" milestone