> IMO, I would drop the bundle, and make the interface take the zip and reconstruct it.
Having the ConfigUpdateInstallReceiver.java take a zip isn't a big overhaul. Can easily be done. Again, the extraction and verification code isn't too bad as I've labored through that already. > My only concern is how do we deal with super big zips. Does Bundle do anything smart and send it piecemeal and store it on disk? I'm a bit confused and might be missing something from the conversation. But, once the zip exists in /cache, which is delivered by some other service on the phone, then what exactly is being shipped across binder that is so large. The current ConfigUpdateInstallReceiver simple receives the signature, version, hash in the intent and verifies it all. Once successful, then the zip (bundle) from /cache is opened and the files are copied in to their correct places as needed. On Fri, Aug 23, 2013 at 4:45 PM, William Roberts <[email protected]>wrote: > > > > On Fri, Aug 23, 2013 at 1:40 PM, Robert Craig <[email protected]>wrote: > >> > If I recall, its just running jarsigner on the apk, correct? >> >> The OTA update zip uses the signapk jar with the -w option (whole file >> option). Apks are signed with signapk but without that option. The current >> update bundle format used by 4.3 ( ConfigUpdateInstallReceiver.java) should >> still be usable as it hashes (sha512) and then signs the entire bundle. I >> would think we can leverage that existing mechanism for this if needed. >> Upon delivery of the bundle along with the metadata, the code can just open >> the otacerts.zip file on the phone looking for a matching public cert. >> > > Ahh yes signapk... I was doing work with the OTA's unpacking them and > resigning them by hand, that should have been at the top of my mind. > >> >> Although, if your looking to push just a zip file containing all this >> stuff then we can just use signapk with the -w option which appends the >> signature to the zip in the comment field. Extraction code isn't too bad, >> I've written it before. >> > > IMO, I would drop the bundle, and make the interface take the zip and > reconstruct it. My only concern is how do we deal with super big zips. Does > Bundle do anything smart and send it piecemeal and store it on disk? > > >> >> >> On Fri, Aug 23, 2013 at 4:24 PM, William Roberts < >> [email protected]> wrote: >> >>> >>> >>> >>> On Fri, Aug 23, 2013 at 1:19 PM, Stephen Smalley <[email protected]>wrote: >>> >>>> On 08/23/2013 03:16 PM, William Roberts wrote: >>>> > Thoughts on versioning: >>>> > >>>> > So a problem exists where an ota, or userdata update can partially >>>> update >>>> > the files. Also, an OTA can come in that contains a newer policy then >>>> > userdata. So assuming that userdata is the newest, is not always >>>> feasible. >>>> > Time stamping on release servers, drift, etc, make using a time stamp >>>> not >>>> > feasible. >>>> > >>>> > Initially, I thought the client setting policy in data could just >>>> wake up >>>> > on boot, check against a list of hashes and versions internally, and >>>> remove >>>> > the stale ones from userdata, reboot, and viola, your on the OTA >>>> files (or >>>> > invoke it via the setprop). >>>> > >>>> > This would require the update agent to know which is older and newer, >>>> > perhaps time stamp on the device, or something, but those could be >>>> wrong >>>> > too. Essentially, it needs a cohesive way to know what version it is, >>>> so >>>> > the system can apply the proper policy. >>>> > >>>> > Their is essentially two issues here: >>>> > 1. How do we keep files from being partially updated incorrectly >>>> > 2. How do we know which version is the correct one to apply >>>> > >>>> > For issue one, Josh suggested a db and then a zip. He initially just >>>> though >>>> > of data, however the larger takeaway is perhaps a container of some >>>> sort is >>>> > a good way to keep the policies as a cohesive unit (solving number 1) >>>> for >>>> > both ramdisk and data.Not sure what the best container format would >>>> be, >>>> > offhand. >>>> > >>>> > Issue 2, we just need a way to know that this policy version is >>>> higher, >>>> > please use it instead. Updating agents, places policy is reloaded, >>>> whatever >>>> > may want to make use of this. So having it as a part of the core >>>> container >>>> > (bundle) of policy files would be nice as well as an interface for >>>> > extracting them, etc. Then the larger issue is just properly creating >>>> the >>>> > version number. >>>> > >>>> > Just my 2 cents, and is not meant to be the direction we have to go, >>>> but >>>> > rather get a good discussion on how we can solve these issues >>>> together. >>>> >>>> If we go the signed zip route, let's use a whole-file signature (as used >>>> by OTA updates) please. Less prone to the recent APK signature >>>> nonsense. >>>> >>>> If I recall, its just running jarsigner on the apk, correct? >>> >>> >>>> Do we need to preserve the existing policy bundle format introduced in >>>> 4.3 or is that something we can eliminate in favor of just a signed zip >>>> file? >>>> >>> >>> We might not have to rework that interface, but rather the backend >>> extraction and wherever the bundle is created. >>> The bundle must just be a single object, the zip file. >>> >>> >>>> >>>> If I understand correctly, you want to avoid having to take the policy >>>> bundle / zip and expanding it out on the filesystem as is presently done >>>> by the SELinuxPolicyInstallReceiver. Instead, you want all code that >>>> loads policy files to directly open the bundle/zip, validate it, and >>>> extract whatever files it needs from within into memory. Is that right? >>>> >>> >>> Yeah something like that. >>> >>> >>>> And if there is one under /data/security, you want to open both, >>>> compare their version numbers (stored within the bundle/zip), and then >>>> decide which one to use? >>>> >>> Yes >>> >>> >>> >>> -- >>> Respectfully, >>> >>> William C Roberts >>> >>> >> > > > -- > Respectfully, > > William C Roberts > >
