Oct 23rd IRC Scrum log

n8fr8 okay so devrandom _hc pd0x we are now having an irc scrum

n8fr8 about the Bazaar project

n8fr8 for anyone else listening in

n8fr8 you can learn more about this project at: https://dev.guardianproject.info/projects/bazaar/wiki/

n8fr8 in short though, we are trying to support p2p or decentralized app sharing, syncing, etc

n8fr8 building on some of what f-droid has done, and also using chatsecure's new otrdata share feature

n8fr8 so....

n8fr8 i haven't had a chance to build pd0x's kerplapp repo code yet

n8fr8 but i am hoping to soon

devrandom OK

_hc my notable output of the week is this wiki page: https://dev.guardianproject.info/projects/bazaar/wiki/Trusted_Intent_Interaction

_hc thinking about ways to verify the sender or receiver of an explicit Intent

_hc to be bundled up into an easy to use library

_hc this is contingent to the core idea of chaining validation methods not being invalidated ;)

devrandom "domain name"? is that the package name?

_hc I should reword that

_hc it could be APK hash, signing key, or package id

_hc i'm feeling a bit sick, so I was mixed this up with the idea for chaining validation of HTTPS and TLS

devrandom sorry to hear you're sick

n8fr8 well, i am sick AND tired! :)

devrandom uh oh

n8fr8 not really

n8fr8 i just wanted to complain

n8fr8 feeling quite healthy

devrandom :)

devrandom kvetch away, we'll suspend disbelief

devrandom so this is not really like chaining certs

_hc hmm, so I guess I haven't thought that much about how to chain this here

_hc right

devrandom in chaining certs, A signs B and B signs C

devrandom in this case, these are fallbacks

_hc no

_hc ok

n8fr8 let's not get into certs right now

_hc I was thinking of chaining methods of validation, but if that's confusing, it can be worded differently

n8fr8 in this context, we are tlaking about how to build trust between apps, beyond just the Intent permission model

_hc yeah

n8fr8 so right now in ChatSecure

_hc skip certs for now, that's a separate discussion

n8fr8 we prompt the user when an app is asking to creaet an account, or create a group chat

n8fr8 etc

devrandom I like the idea of trusting at different levels (at the APK and signing key levels for example)

devrandom but ok

_hc yeah, same idea but for Intents

_hc not HTTPS/TLS certs

_hc what would be the token? that's where I 'm spacing

devrandom I do mean for intents... so if an intent comes in, and the APK was not ToFU'ed but the signing key was, then it's all good

devrandom token?

_hc with HTTPS, the token that you're matching is the domain name

_hc in pinning and tofu

devrandom the token would be the APK hash or the signing key hash (aka fingerprint)

_hc is there a pin for this domain name?

pd0x hi, sorry here now.

pd0x looking over the Trusted Intent page

pd0x don't judge me too harshly if you dig into the Kerplapp repo. It's pretty unpolished <cringe>

_hc you gotta start somewhere :)

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.

pd0x _hc: Ok. Involving the APK hash means you're pinning to a specific release/version

_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)

_hc https://dev.guardianproject.info/projects/bazaar/wiki/Signing_the_Local_APK_Index :-D

pd0x and yes, jar format includes the signature in META-INF/ as a *.DSA, *.RSA, *.EC file next to the .SF

pd0x that file is a PKCS7 structure with the signature & a self signed certificate with the pubkey info for the signature

pd0x _hc: thanks for transcribing :-)

devrandom are we thinking yet of multiple signing keys with thresholds? (like Gitian)

pd0x devrandom: you could probably do that for the index.jar, you can't for APKs

pd0x at least not without OS support

pd0x I was futzing around with libgfshare + openssl for splitting an Android app signing key using shamir's secret sharing to do thresholded releases

_hc I added more to that page too, feel free to edit, I'm out of it

devrandom well, Bazaar could do the extra checking before handing over to the OS for install

pd0x but it's not as ideal as true threshold signatures because you have to recombine the n shares on the same machine revealing the private key for signing ops :-(

devrandom (I didn't mean real threshold sigs - just a quorum of signers)

pd0x devrandom: If Bazaar did the checks and handed things over you'd still have to get all updates signed by the same threshold unique signatures for the OS to install it

pd0x exact same

devrandom sorry, I think I was unclear

devrandom I mean the following flow:

pd0x listens.

devrandom * multiple builders build the package

devrandom * each builder signs the package

devrandom * Bazaar checks that m out of n known good builders signed the package

devrandom * Bazaar then hands off to the OS for install

devrandom .

pd0x and the m out of n signatures, are they applied to the APK via standard Android code signing?

pd0x using jarsigner that is

devrandom the extra sigs can be attach using a similar (but not identical) mechanism

_hc that could be useful, but it seems a later step

_hc right now, its just about getting a trusted index from one phone to another

pd0x if they're applied with jarsigner then Bazaar can do the m out of n check but if m ever changes it breaks updates

devrandom no reason to confuse the OS with multiple sigs that only Bazaar wants to look at

pd0x bazaar could strip m down to 1 once it was happy

pd0x but then it's a question of which 1 of m

devrandom oh I see

pd0x otherwise the scenario is Bob goes from NoApp -> Bazaar Vetted APK signed by A & B (of ABC)

pd0x Then trusted builders change, APK arrives signed BC

devrandom just declare one builder as the "main" one for keeping the OS happy

pd0x Bazaar is happy, OS isn't

devrandom and that one is mandatory

pd0x because the OS mandates that all updates to AB app are signed by exactly AB and only AB

pd0x devrandom: could do that

devrandom alternatively, Bazaar could fake-sign the APK for installation purposes

_hc then we have APKs that can only be installed by Bazaar

devrandom so that only Bazaar can upgrade the APKs

pd0x _hc: indeed. not idea

pd0x l

_hc since it would have to strip out the extra sigs

devrandom using a randomly generated cert

pd0x devrandom: hmmm. yeah.

_hc so might as well use detached sigs for gitian sigs

_hc since they would be stripped out anyhow

n8fr8 okayback now

pd0x devrandom: you can 'unsign' an APK by deleting the META-INF sig entries

devrandom right

devrandom it's just files in META-INF

pd0x devrandom: so you're imagining after Bazaar verified the quorum on APK it'd create APK' by striping the sigs and applying one with its own priv key

devrandom right

devrandom or leave them in the META-INF, since they would use filenames that are not seen by the OS

n8fr8 woah that is an interesting idea

n8fr8 resigning the apk after we have verified it

pd0x it's a little bit divergent from what bazaar is now

devrandom SteeleNivenson: see ^^ re ostel.me broken links

pd0x because it means you have to get updates to the bazaar installed apps throguh bazaar forever

pd0x or go back to a clean slate

n8fr8 right...

devrandom yes, that's a tradeoff

pd0x I guess I imagined sharing an app through bazaar and the other side being able to update it via Google Play/etc later

n8fr8 well if you don't ever have access to googl eplay

n8fr8 then bazaar could just intercept downloaded APKs

n8fr8 liek lookout does

devrandom but I'm pushing the gitian project these days (Debian seems to be into it ... ;) )

n8fr8 well, we should consider the "no google play" option as one type of important user

pd0x devrandom: don't get me wrong. I <3 <3 gitian

pd0x devrandom: android code signing is poor :-(

devrandom thanks :)

pd0x spent a lot of time thinking about alternatives and ended up at needing OS support for much

devrandom in any case, we could keep the external upgrade path alive by keeping the "main builder's signature" on the APK

pd0x n8fr8: agreed. I think we'd need to spend more time thinking about it. Without the Gitian type setup to produce the quorum builds we don't have the need yet either

n8fr8 i also like _hc's detached signature as an option

n8fr8 with ChatSecure and otrdata/dataplug support

n8fr8 we can transfer a variety of data types more seamelessly

pd0x yeah, that seems an easier path to start with

n8fr8 than just limiting ourselves to only fdroid metadata

n8fr8 so perhaps that is a feature once you level up to chatsecure+bazaar

n8fr8 I.e. keeping/store multiple deatached sigs per apk

devrandom pd0x: curious if you inject stuff into META-INF, does that invalidate the APK sig at all?

pd0x devrandom: it doesn't. That's how you can add a signature to an already signed APK without invalidating the first one

pd0x running keytool on an already signed app will (assuming no key alias collisions) drop another .RSA/.DSA/etc file in the META-INF

devrandom OK... so in that case, we should keep in mind that we can just inject whatever additional metadata through that route and it can stay there

pd0x it will change the APK hash though, a detach sig wouldn't

devrandom true

pd0x not sure what that tradeoff costs us, likely nothing if we aren't pinning to it. I doubt anything else does

devrandom one option is to use the algorithm from the Android verifier to get the hash of the actual data in the APK (minus the META-INF)

_hc pd0x: n8fr8 devrandom I have to run now, can someone post the log of this meeting on https://dev.guardianproject.info/projects/bazaar/wiki/Wiki ?

devrandom does fdroid hash the APK or the internals?

_hc also it would be good to have a wiki page about it there

pd0x devrandom: the APK

devrandom I see