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