ubuntu-appstore-developers team mailing list archive
-
ubuntu-appstore-developers team
-
Mailing list archive
-
Message #00078
Re: Letting developers install "3rd party" packages
On 13-06-12 03:32 PM, Martin Albisetti wrote:
> On Wed, Jun 12, 2013 at 3:38 PM, Marc Deslauriers
> <marc.deslauriers@xxxxxxxxxxxxx> wrote:
>> On 13-06-12 02:09 PM, John Pugh wrote:
>>> On Wed, Jun 12, 2013 at 12:58 PM, Marc Deslauriers
>>> <marc.deslauriers@xxxxxxxxxxxxx> wrote:
>>>> On 13-06-12 12:26 PM, John Pugh wrote:
>>>>> On Wed, Jun 12, 2013 at 11:30 AM, Marc Deslauriers
>>>>> <marc.deslauriers@xxxxxxxxxxxxx> wrote:
>>>>>> On 13-06-12 11:13 AM, Daniel Holbach wrote:
>>>>>>> Hello everybody,
>>>>>>>
>>>>>>> there seems to have been broad agreement that we should developers
>>>>>>> install packages from outside the app store and it seems like 3 options
>>>>>>> were discussed of which one seems to be preferred (correct me if I'm wrong).
>>>>>>>
>>>>>>> It'd be good if we could finalise the plans on this and track the work
>>>>>>> somewhere.
>>>>>>>
>>>>>>> Thanks a lot everyone for contributing to this!
>>>>>>>
>>>>>>
>>>>>> FYI, the 3 options I discussed were the following:
>>>>>>
>>>>>> 1- Default Secure Mode: By default, device only installs packages which
>>>>>> match hash provided by app store signature.
>>>>>>
>>>>>> 2- Developer Mode: Developer can add his key to device using tethered
>>>>>> developer tool. If package doesn't match app store hash, the signature
>>>>>> on the package itself is checked against local developer key. (Perhaps
>>>>>> the number of developer keys on device is limited to prevent this being
>>>>>> used by third-party app stores, etc.)
>>>>>>
>>>>>> 3- Untrusted Mode: as on Android. User/Developer checks a box which
>>>>>> disables any hash/signature verification.
>>>>>
>>>>> While many will want #3, my layman's thinking would be that #2 is
>>>>> acceptable provided there is a way for a user to put a app on their
>>>>> device in some form or fashion which in my mind is a hybrid of #2 and
>>>>> #3. Even if that means jumping through more hoops than a typical user
>>>>> or developer would.
>>>>
>>>> Putting an untrusted app on your device is #3. In what way is it a hybrid?
>>>>
>>>> Marc.
>>>
>>> Untrusted to you may not be untrusted to me. If I want to install
>>> something, I will find a way. I was suggesting that it should be a
>>> little more difficult than "click xx times on xx to enable developer
>>> mode" and a little less daunting than rendering the device
>>> "jailbroken". Developers need to test on real devices (since it's
>>> currently the only way) and some users will want full control to do
>>> what they please. A equal balance of the two is my suggestion.
>>>
>>
>> So we should make #3 harder? Perhaps require the device owner to tether
>> the device and run a tool? I'm not sure what that ultimately
>> changes...as you said, if you want to install an unsigned app, you'll do
>> it, so I don't see what the advantage is compared to simply clicking a
>> checkbox in the system settings somewhere.
>>
>> The important thing with #3 is that the device owner is properly
>> informed of the malware risks inherent in disabling the signature
>> checks, and is making a conscious decision by doing so.
>
> Why would we make #3 harder?
> It sounds to me like if users want to use apps from outside the store,
> as long as they've explicitly said so, they should be able to easily.
> Tethering whatever makes it impossible for anyone that isn't a
> developer to use it, and it's a disadvantage vs Android or iOS +
> TestFlight.
>
> I don't see what it gains us?
>
I'm pretty sure some carriers will force us to remove option #3, and
some movie providers will force us to disable DRM when #3 is used.
With package signing, we should be able to gain functionality similar to
TestFlight in the future, so developers can get user testing without
requiring that users disable package signature verification, and losing
some functionality.
We would need to enforce similar restrictions as TestFlight though, such
as having a central authorization server validate app usage daily/weekly
so this doesn't become a back door.
Marc.
Follow ups
References