Simplify Android release support by including a jar directly

[jrose-signal]

The crate-local Maven repository didn't work for Signal because we use rustls-platform-verifier in a library, and our main app doesn't know about Rust at all. We determined that as long as no other library is using rustls-platform-verifier, and as long as rustls-platform-verifier's Java/Kotlin side doesn't need anything but its classes, we can slurp those classes into our library directly and everything will be fine. (And indeed, it is working for us.)

This may have some downsides for general use (the main one being that files(…) dependencies can't have metadata), but given how minimal the crate-local Maven repository is, I'm not sure they'll come up in practice. So maybe this is a simpler approach for future versions of the crate?

dependencies {
    implementation files(findRustlsPlatformVerifierClasses())
}

File findRustlsPlatformVerifierClasses() {
    def dependencyText = providers.exec {
        it.workingDir = new File("../")
        commandLine("cargo", "metadata", "--format-version", "1")
    }.standardOutput.asText.get()

    def dependencyJson = new JsonSlurper().parseText(dependencyText)
    def manifestFile = file(dependencyJson.packages.find { it.name == "rustls-platform-verifier-android" }.manifest_path)
    return new File(manifestFile.parentFile, "classes.jar")
}

[djc]

Cool to see that Signal is starting to use rustls-platform-verifier!

I don't have all the context here, but you might like to read through the discussion in #32.

[Hinton]

We're also running into this issue as we distribute an android library and the consumers have understandably difficulties resolving rustls:rustls-platform-verifier:latest.release. Most likely we'll follow a similar path to above and ship the library bundled.

[complexspaces]

Dumping some thoughts here: Given #179 and how cleartext HTTP traffic requires a manifest value, this issue may come up again soon. AFAICT its not possible to include an AndroidManifest.xml in file-based JAR resource (AAR is required), which is annoying.

The lack of existing infrastructure to publish Maven packages to

Given that GitHub has no plans to allow unauthenticated fetches for Mavan packages, its use would be a dealbreaker for several reasons, among them that crates.io allows it and we should match that.

A lot of other options people have come up with require either managing additional publishing credentials (a problem I'd like to avoid since I'm not part of the rustls team and making the group + me responsible for a Mavan central account is very weird) or require hosting some kind of proxy infrastructure (another problem that is awkward for me to approach).

New publishing idea

On a more positive note: it looks like some other people in the community have been experimenting since I implemented the current solution. This GitHub action (which is simple enough we could vendor it with credit or rewrite...) proposes using raw Git repository storage/access to emulate a registry backend and then use the existing Gradle support for GitHub's Maven registry.

On the surface I really like this idea since it keeps downloads openly available and would also let us get rid of the non-ideal workarounds we have today to publish rustls-platform-verifier-android and extract libraries from it at build time. If we just used a "normal registry URL", pretty much every tradeoff we've made (including the limitations mentioned in this issue) go away.

The only issue I can think of is versioning: End users of the platform verifier on Android would need to keep their Cargo.lock and Gradle versions synced. I'm not good enough at Gradle to know if this is possible, but maybe we could keep the rustls-platform-verifier-android crate around and have a Gradle script extract its version and fill that into the Maven version resolution? @Hinton @jrose-signal do either of you know if that sounds feasible?

@djc Do you have any strong thoughts if it'd be easier to make a new rustls/rustls-platform-verifier-android repository to host these in or if we should try and modify the upstream action template to support dumping the artifacts to a branch instead? The former sounds slightly cleaner since it pollutes Git history less for clones.

[complexspaces]

If hosting infrastructure is on the table (I know the rustls project has at least a machine for benchmarking), we could self-host https://github.com/dzikoysk/reposilite and use it for this. That seems moderately overkill but it would have the "best" ecosystem package manager alignment.

[djc]

@djc Do you have any strong thoughts if it'd be easier to make a new rustls/rustls-platform-verifier-android repository to host these in or if we should try and modify the upstream action template to support dumping the artifacts to a branch instead? The former sounds slightly cleaner since it pollutes Git history less for clones.

No strong thoughts -- your preference seems okay to me.