Mobile app binary details

[odra]

The app binary screen in openshift (where the user can download the binary) could should some extra details about the application binary, such as certificate info, alias, etc (some data are platform specific).

Android

Command:

unzip -p myapp.apk META-INF/CERT.RSA | keytool -printcert

The command's output should be something like this:

Owner: CN=asdf, OU=asdf, O=asdf, L=asdf, ST=asdf, C=asdf
Issuer: CN=asdf, OU=asdf, O=asdf, L=asdf, ST=asdf, C=asdf
Serial number: ...
Valid from: Mon Sep 11 17:46:20 BRT 2017 until: Sun Dec 10 18:46:20 BRST 2017
Certificate fingerprints:
     MD5:  ...
     SHA1: ...
     SHA256: ...
     Signature algorithm name: SHA256withRSA
     Version: 3

Extensions: 

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
...
]
]

The most relevant fields in my opinion are: Owner, Issuer, Signature algorithm name, Valid from and Valid until.

iOS

Unfortunately this command has to be run in a mac machine:

codesign -vvvv -d somefile.app

The command's output should be something like this:

Executable=build_path/saml-ios-swift.app/saml-ios-swift
Identifier=com.feedhenry.saml-ios-swift
Format=app bundle with Mach-O universal (armv7 arm64)
CodeDirectory v=20200 size=1692 flags=0x0(none) hashes=45+5 location=embedded
OSPlatform=37
OSSDKVersion=656128
OSVersionMin=524288
Hash type=sha256 size=32
CandidateCDHash sha1=...
CandidateCDHash sha256=...
Hash choices=sha1,sha256
Page size=4096
CDHash=...
Signature size=4680
Authority=iPhone Distribution: Red Hat
Authority=Apple Worldwide Developer Relations Certification Authority
Authority=Apple Root CA
Signed Time=Sep 25, 2017, 11:45:26 AM
Info.plist entries=30
TeamIdentifier=...
Sealed Resources version=2 rules=13 files=49
Internal requirements count=1 size=180

I personally think the most important items are: Identifier (all of them), Authority, TeamIdentifier and Signed Time

[maleck13]

@odra This information seems useful. However it seems like something that should be done as a step in pipeline on Jenkins? Once done this information could then be exposed in some manner to the MCP server. I think there is quite a bit to consider with this, but a good starting place would be how to get this info after a build as part of the normal build pipeline and then expose it from Jenkins (perhaps as a build artefact)?

[odra]

I think we could add a step in the pipeline where it runs those commands saving the output to a file then this could could be archived as well once the build finishes to be later retrieved from jenkins by mcp.

There is also the possibility to create a jenkins plugin for that (there is a way to expose some jenkins plugin functionality in the jenkins rest api).