pd0x I'm still fighting with the fdroid client to get it to install apps from a Kerplapp repo. Almost there, the metadata all parses letting you browse the repo/apps doesn't want to install an app fresh or as an update (even when sigs match)

_hc so the thing I haven't figured out yet with IntentPinningTofu is what's the token/key that the process starts with

n8fr8 pd0x: maybe you can setp back from the f-droid debugging

n8fr8 and just have it spit out an HTML page with all the apps

n8fr8 and links to download?

n8fr8 by "it" i mean your nano server

pd0x n8fr8: at that point already :-)

n8fr8 just to debug that aspect

n8fr8 ah ok

pd0x nano hosts the index in a way that you can HTTP get the APKs

n8fr8 so is that working? the issues i somewhere in f-droid client?

pd0x I think the issue is with the metadata for each APK in the index.xml file Kerplapp builds

pd0x F-droid parses it OK but it gets into an inconsistent state in the fdroid client app

pd0x so in there when you click to install an app that isn't present on-device it tries to uninstall it first

pd0x and that fails because it isn't there

pd0x I'm trying to sort out where/why it gets confused into thinking apps not present on-device need to be uninstalled before the APK can install

pd0x If you directly navigate to the kerplapp repo with a browser and download the APK it will install

pd0x _hc: the idea with the trusted intent interaction - what's is the pin? Is it the subject public key identifier from the cert that signed the APK?

pd0x _hc: or a hash of the APK (both? neither?)

_hc I'm thinking perhaps the package ID is the token, and the signing key and APK hash are the things that get looked up.

_hc so packageID is the key, and the signing key or hash is the value, depending on the prefereence

pd0x _hc: I don't think that's a bad thing, just want to make it explicit because it will be potentially confusing to a user to TOFU the same pkg when it updates

_hc yes, using the hash would be the more extreme case, like to work around the master key bug

pd0x Gotcha

_hc TOFU is probably more useful with the hash rather than pinning

pd0x agreed

_hc but maybe not...

_hc well, yeah, guess so

_hc since the master key exploit can be done by malware

pd0x signature pinning is basically what Google did for the Authenticator -> Authenticator2 export

_hc some time after the install

_hc signing key or apk hash?

pd0x signing key

_hc hash pnning could be the key to upgrading our signing key on existing apps

_hc new package-id/signing key

_hc both installed at the same time

pd0x it's probably the safest way to do data migration to a new pkg/key

_hc old one grants the new one perms to read all data based on hash pin

pd0x I like the idea of building it as a library ala moxie's pinning lib

_hc yeah, that's the idea

devrandom how is Bazaar going to use this?

_hc for communicating with ChatSecure for OTRDATA

_hc maybe also for talking to GPG

pd0x to sign the index.jar with the OTR DSA key

pd0x as another potential idea

devrandom interesting

devrandom oh, maybe ChatSecure should be able to bootstrap Bazaar through OTRDATA

_hc pd0x: I forget if we covered this: if there are multiple sigs in the index.jar, do they all need to be present to validate? or is that just Android?

_hc devrandom: definitely

_hc but more likely, bazaar is going to bootstrap chatsecure

_hc i.e. starting from a blank, new phone, first install Bazaar, then the rest follows

_hc but there are lots of chatsecure users that can go the other way

devrandom yes

pd0x _hc: Not sure I understand the question. Are you talking about multiple signatures on the Fdroid repo index.jar or multiple signatures on an APK (one listed in the repo or otherwise?)?

_hc multiple sigs in the repo index.jar

devrandom in or on? ;)

_hc I believe its in

_hc doesn't the jar format include the sig?

pd0x the fdroid client (presently) only checks one signature on the index.jar. When you first configure the repo if it finds a pubkey attribute on the index.xml's repo XML then it will subsequently compare that cached attribute value making sure it's the Signature on the index.jar

pd0x It's a hash of the PKCS7 bytes IIRC

pd0x it doesn't care how many signatures there are as long as the one specified in the index.xml from repo install is there

pd0x there isn't any support for more than one pubkey attribute in the XML (as best I can tell)