Whitelist fileSystemProvider API to Secure Shell app

Whitelist fileSystemProvider API to Secure Shell app

Secure Shell is a legacy packaged app, and as such cannot declare
fileSystemProvider permission. Secure Shell will require access to
fileSystemProvider API - to enable Secure Shell to access the API,
expose fileSystemProvider permission to the app via whitelist.

BUG=673004
Review-Url: https://codereview.chromium.org/2613823002
Cr-Commit-Position: refs/heads/master@{#444498}
Committed: https://chromium.googlesource.com/chromium/src/+/635e633fc4db2ac47139a493fa36646735627464

[tbarzic, 2017-01-05 00:57:20]

The CQ bit was checked by tbarzic@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-05 00:57:44]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[tbarzic, 2017-01-05 00:58:28]

tbarzic@chromium.org changed reviewers:
+ rdevlin.cronin@chromium.org, rginda@chromium.org

[tbarzic, 2017-01-05 00:58:29]

rginda: fyi

[commit-bot: I haz the power, 2017-01-05 01:53:43]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-05 01:53:44]

Dry run: This issue passed the CQ dry run.

[rginda, 2017-01-05 19:19:12]

lgtm

Thanks!

[mcdermottm, 2017-01-05 23:33:52]

Hi tbarzic,

Does _manifest_features.json require changing as well? Or is it intelligent
enough to carry over? (i.e. if the app has permission to use the API, it has the
manifest permissions as well)

Reference:
https://chromium.googlesource.com/chromium/src/+/master/chrome/common/extensi...

[tbarzic, 2017-01-05 23:54:20]

On 2017/01/05 23:33:52, mcdermottm wrote:
> Hi tbarzic,
> 
> Does _manifest_features.json require changing as well? Or is it intelligent
> enough to carry over? (i.e. if the app has permission to use the API, it has
the
> manifest permissions as well)
> 
> Reference:
>
https://chromium.googlesource.com/chromium/src/+/master/chrome/common/extensi...

oh, I missed that one - I think I have to update both

[tbarzic, 2017-01-06 03:48:16]

The CQ bit was checked by tbarzic@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-06 03:48:32]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-06 04:40:15]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-06 04:40:16]

Dry run: This issue passed the CQ dry run.

[mcdermottm, 2017-01-07 04:27:45]

On 2017/01/05 23:54:20, tbarzic wrote:
> On 2017/01/05 23:33:52, mcdermottm wrote:
> > Hi tbarzic,
> > 
> > Does _manifest_features.json require changing as well? Or is it intelligent
> > enough to carry over? (i.e. if the app has permission to use the API, it has
> the
> > manifest permissions as well)
> > 
> > Reference:
> >
>
https://chromium.googlesource.com/chromium/src/+/master/chrome/common/extensi...
> 
> oh, I missed that one - I think I have to update both

Awesome-- thank you! (I am the intern requesting this whitelisting)

[Devlin, 2017-01-10 16:00:04]

legacy chrome apps have been deprecated for years.  It makes me a little sad to
see us adding yet-more-functionality to this rather than transitioning away...
can you outline on the bug a bit more of the reasons that are difficult to
address?

[rginda, 2017-01-17 18:11:29]

On 2017/01/10 16:00:04, Devlin (US OOO on Jan 16) wrote:
> legacy chrome apps have been deprecated for years.  It makes me a little sad
to
> see us adding yet-more-functionality to this rather than transitioning away...
> can you outline on the bug a bit more of the reasons that are difficult to
> address?

We'd love to get off of the deprecated platform, and put in some considerable
effort two years ago.  In the end we stopped because neither of the options
meets the needs.

Extensions:
1. Aren't allowed to capture Ctrl-N/T/W.
2. Will likely never have access to raw sockets.
3. Have no equivalent of "open in window".
4. Have no app icon in the ChromeOS launcher.

Of these, #1 is the deal breaker (except on Mac, where Cmd-N/T/W are distinct). 
#2 we could work around with the same whitelist we have today.  3 and 4 would
cause problems for some users.

V2 Apps:
1. Inability to load window content from the web breaks our corp OAuth to the
ssh relays.
2. Inability to send postMessage to extensions breaks our integration with
gnubby.
3. Deprecated everywhere except Chrome OS.

These are all deal breakers for corp users.  The first issue we might be able to
work around with a rewrite of portions of Secure Shell and the relay servers. 
The second is hard to imagine a fix for, other than a change to Chrome's policy
on app->extension messaging.  The third I think is a deal breaker.


I've met with the Owen from the web platform team about this in the past.  We're
hoping that the problems with extensions can be addressed by the web platform
over time and Secure Shell can move into extension or open web space at that
time.

[Devlin, 2017-01-17 20:57:49]

On 2017/01/17 18:11:29, rginda wrote:
> On 2017/01/10 16:00:04, Devlin (US OOO on Jan 16) wrote:
> > legacy chrome apps have been deprecated for years.  It makes me a little sad
> to
> > see us adding yet-more-functionality to this rather than transitioning
away...
> > can you outline on the bug a bit more of the reasons that are difficult to
> > address?
> 
> We'd love to get off of the deprecated platform, and put in some considerable
> effort two years ago.  In the end we stopped because neither of the options
> meets the needs.
> 
> Extensions:
> 1. Aren't allowed to capture Ctrl-N/T/W.
> 2. Will likely never have access to raw sockets.
> 3. Have no equivalent of "open in window".
> 4. Have no app icon in the ChromeOS launcher.
> 
> Of these, #1 is the deal breaker (except on Mac, where Cmd-N/T/W are
distinct). 
> #2 we could work around with the same whitelist we have today.  3 and 4 would
> cause problems for some users.

Extensions can capture Ctrl+N/T/W using the commands API, can't they?

[rginda, 2017-01-18 19:29:19]

On 2017/01/17 20:57:49, Devlin (possibly slow) wrote:
> On 2017/01/17 18:11:29, rginda wrote:
> > On 2017/01/10 16:00:04, Devlin (US OOO on Jan 16) wrote:
> > > legacy chrome apps have been deprecated for years.  It makes me a little
sad
> > to
> > > see us adding yet-more-functionality to this rather than transitioning
> away...
> > > can you outline on the bug a bit more of the reasons that are difficult to
> > > address?
> > 
> > We'd love to get off of the deprecated platform, and put in some
considerable
> > effort two years ago.  In the end we stopped because neither of the options
> > meets the needs.
> > 
> > Extensions:
> > 1. Aren't allowed to capture Ctrl-N/T/W.
> > 2. Will likely never have access to raw sockets.
> > 3. Have no equivalent of "open in window".
> > 4. Have no app icon in the ChromeOS launcher.
> > 
> > Of these, #1 is the deal breaker (except on Mac, where Cmd-N/T/W are
> distinct). 
> > #2 we could work around with the same whitelist we have today.  3 and 4
would
> > cause problems for some users.
> 
> Extensions can capture Ctrl+N/T/W using the commands API, can't they?

I'm not sure if that API allows an extension to override those keys.  Bue even
if it does, that API adds commands to chrome itself.  We want to capture them
only in the scope of an active Secure Shell session.  We'd essentially have to
override Ctrl-N/T/W for all of chrome, and then detect which, if any Secure
Shell window were active and route the command to it.  If not, somehow defer
processing of the command to chrome.

[rginda, 2017-01-18 19:29:22]

On 2017/01/17 20:57:49, Devlin (possibly slow) wrote:
> On 2017/01/17 18:11:29, rginda wrote:
> > On 2017/01/10 16:00:04, Devlin (US OOO on Jan 16) wrote:
> > > legacy chrome apps have been deprecated for years.  It makes me a little
sad
> > to
> > > see us adding yet-more-functionality to this rather than transitioning
> away...
> > > can you outline on the bug a bit more of the reasons that are difficult to
> > > address?
> > 
> > We'd love to get off of the deprecated platform, and put in some
considerable
> > effort two years ago.  In the end we stopped because neither of the options
> > meets the needs.
> > 
> > Extensions:
> > 1. Aren't allowed to capture Ctrl-N/T/W.
> > 2. Will likely never have access to raw sockets.
> > 3. Have no equivalent of "open in window".
> > 4. Have no app icon in the ChromeOS launcher.
> > 
> > Of these, #1 is the deal breaker (except on Mac, where Cmd-N/T/W are
> distinct). 
> > #2 we could work around with the same whitelist we have today.  3 and 4
would
> > cause problems for some users.
> 
> Extensions can capture Ctrl+N/T/W using the commands API, can't they?

I'm not sure if that API allows an extension to override those keys.  Bue even
if it does, that API adds commands to chrome itself.  We want to capture them
only in the scope of an active Secure Shell session.  We'd essentially have to
override Ctrl-N/T/W for all of chrome, and then detect which, if any Secure
Shell window were active and route the command to it.  If not, somehow defer
processing of the command to chrome.

[Devlin, 2017-01-18 19:40:27]

I think this probably warrants more discussion, because I think we can probably
solve some of these cases.  But we don't need to block this cl on that
discussion. :)

lgtm

[tbarzic, 2017-01-18 21:07:31]

The CQ bit was checked by tbarzic@chromium.org

[tbarzic, 2017-01-18 21:07:31]

The patchset sent to the CQ was uploaded after l-g-t-m from rginda@chromium.org
Link to the patchset: https://codereview.chromium.org/2613823002/#ps20001
(title: "manifest feature whitelis")

[commit-bot: I haz the power, 2017-01-18 21:08:21]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-18 21:51:24]

CQ is committing da patch.

Bot data: {"patchset_id": 20001, "attempt_start_ts": 1484773651275870,
"parent_rev": "0bc260f9e8b1531e8f02c0b88f918f17e9193bfc", "commit_rev":
"635e633fc4db2ac47139a493fa36646735627464"}

[commit-bot: I haz the power, 2017-01-18 21:51:54]

Description was changed from

==========
Whitelist fileSystemProvider API to Secure Shell app

Secure Shell is a legacy packaged app, and as such cannot declare
fileSystemProvider permission. Secure Shell will require access to
fileSystemProvider API - to enable Secure Shell to access the API,
expose fileSystemProvider permission to the app via whitelist.

BUG=673004
==========

to

==========
Whitelist fileSystemProvider API to Secure Shell app

Secure Shell is a legacy packaged app, and as such cannot declare
fileSystemProvider permission. Secure Shell will require access to
fileSystemProvider API - to enable Secure Shell to access the API,
expose fileSystemProvider permission to the app via whitelist.

BUG=673004

Review-Url: https://codereview.chromium.org/2613823002
Cr-Commit-Position: refs/heads/master@{#444498}
Committed:
https://chromium.googlesource.com/chromium/src/+/635e633fc4db2ac47139a493fa36...
==========

[commit-bot: I haz the power, 2017-01-18 21:51:56]

Committed patchset #2 (id:20001) as
https://chromium.googlesource.com/chromium/src/+/635e633fc4db2ac47139a493fa36...