I've added the debconf shim information to the wiki https://wiki.mozilla.org/Apps/Security#debconf_shim_for_B2G_native_apps
It also does seem that there is some misunderstanding in the terminology being used so I added a section trying to define a "webapp", "native app". However, I believe there are use cases / requirements for an app to be able to retrieve remote resources. This obviously causes problems if we want to use code signing. My question to the B2G team is. Is there a compelling use case / business requirement to allow a native app to retrieve remote content? If not, I strongly agree with lkcl and others on the thread that we restrict APIs such dialer / contacts to signed + reviewed static apps. David Chan ----- Original Message ----- > From: "lkcl luke" <luke.leigh...@gmail.com> > To: "Fabrice Desré" <fabr...@mozilla.com> > Cc: dev-weba...@lists.mozilla.org, "David Barrera" > <dbarr...@ccsl.carleton.ca>, dev-security@lists.mozilla.org, "Jim > Straus" <jstr...@mozilla.com>, "Lucas Adamski" <ladam...@mozilla.com>, > "Mozilla B2G mailing list" > <dev-...@lists.mozilla.org>, "ptheriault" <ptheria...@mozilla.com>, > cjo...@mozilla.com, "Jonas Sicking" > <jo...@sicking.cc> > Sent: Wednesday, March 14, 2012 4:04:41 PM > Subject: Re: [b2g] OpenWebApps/B2G Security model > > @whoever is maintaining the wiki page: information is contained about > 1/2 way down which is critical to put onto the wiki page. thanks. > > > On Wed, Mar 14, 2012 at 9:50 PM, Fabrice Desré <fabr...@mozilla.com> > wrote: > > Lucas, > > > > Are you considering signing the html/js/css/other-content from > > apps? > > yeeees. nooow you're getting it. that's what debian packages are. > you package them up (.deb) and then you get the maintainer to > digitally-sign them. then, prior to release, the "ftp master" *also* > signs them. > > > btw, fabrice, is there any particular reason why you chose to > respond > to lucas, who described *exactly* the same architecture as that which > i proposed over 4 days ago, in some detail, with comprehensive > information that helps aid in evaluating the architecture and > validating that it is in fact solving the problem, yet have chosen to > completely ignore what i wrote? > > that is somewhat disrespectful, and if you do not have a good reason > please could you kindly and publicly apologise. > > if however there is a genuine reason then i apologise for "ringing > the alarm bells" and please disregard it completely. > > > > I can understand the nice properties that would give us, but that > > looks > > extremely impractical in real life. > > tough. it's not "impractical" at all for the debian maintainers, is > it? they've been operating for over 20 years, why therefore are you > considering it "impractical"? debian's entirely free software and > _they_ don't consider it "impractical", do they? > > likewise, redhat and fedora and suse - all of whom use digital > signatures on packages - do not consider it to be "impractical", do > they? > > read what jonas originally wrote, fabrice. [this is why it's so > damn > important to have an online document, folks]. > > jonas said [paraphrasing]: "we do not want to become another apple" > which you would have to be if you became "the authority" - the > zeig-heil dictator - which told people what apps they can and cannot > have on their own purchased hardware. > > the alternatives are just... too nasty, fabrice. > > > > Web sites change all the time, which is > > not the case of native apps distributed from a store. > > it would appear that you are giving a case *for* digital-signatures > of native apps distributed from a "store"! > > :) > > either that or you are thoroughly confusing "web sites" with "native > apps distributed from a store", believing that just because B2G is a > "web engine" that somehow the two must be the same. > > > web sites and the code on them which is downloaded via HTTP or HTTPS > by going to a web site (think "B2G's browser application") has > *NOTHING TO DO WITH* the "distribution of native apps from a store". > > under the system that i am proposing which i know will solve the > problem of securing the apps that are distributed through stores, the > following actions would occur: > > [and could someone please document this on the wiki page]: > > * a user goes to a store (GUI front-end TBD) > * this "store" triggers the command "sudo apt-get update" in the > background (or this occurs on a regular basis) > * they go "i wanna app wiv a cherry on top" > * the selection fires off a LOCAL COMMAND "sudo apt-get install > cherry-on-top". > * the GUI uses the dpkg / debconf communication system to inform > them > of progress > * the GUI then walks them through the security questions (which is > all part of debconf) > > in other words, the GUI is actually nothing more than yet another > debconf front-end! it just so happens that the GUI is also a B2G app > that has a communications-path (unix pipe, whatever) through (oh god > please no :) yet another WebAPI over to apt/debconf. > > where in that did you see *any* "web site HTTP visitation"? > > there *was* none, was there? > > now it so happens that apt, at the back-end, depending on what > packages are installed (apt-p2p or the defaults which do http and > ftp), *happens* to perform HTTP requests, FTP requests or blah blah > requests, but this is *NOTHING TO DO WITH* the B2G executable. > > it's *entirely* handled by dpkg, aptitude, debconf etc. etc. > > the really nice thing about this is that the entire software-base > already exists, is proven, works, well-established and so on. all > you > have to do is go find a debian person (steve if he's not madly busy, > wookey likewise) and say "hey folks how do we do this?" > > also, if you _were_ to utilise the debian packaging system i'm sure > that: > > a) they would probably go "cool!" and would simply start allowing B2G > apps directly into the debian repositories. they'd probably even > create a "task" for you which installed B2G on any system. (*1) > > b) some of the debian mirrors would, if asked, quite likely allow > some > space for the B2G infrastructure and apps. many of them do ubuntu as > well so it's no big deal. > > l. > > (*1) as long as, of course, you sort out the stupid licensing on > mozilla forcing the advertising clause which just pisses them off, or > just let them come up with another stupid name for B2G such as > icefart > or something wonderfully ridiculous. hurrah :) > _______________________________________________ > dev-security mailing list > dev-security@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security > _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
