New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SRI by default #20

Merged
merged 1 commit into from Jul 19, 2015

Conversation

Projects
None yet
5 participants
@jonathanKingston
Member

jonathanKingston commented Jul 10, 2015

@jonathanKingston

This comment has been minimized.

Show comment
Hide comment
Member

jonathanKingston commented Jul 10, 2015

@stefanpenner

This comment has been minimized.

Show comment
Hide comment
@stefanpenner

stefanpenner Jul 10, 2015

Contributor

It would be great for future work to integrate with ember-deploy, which I believe could automatically enable SRI for assets deployed to cdn.

It would be good if that deploy step would also valid the deploy validates.

Something worth adding to this rfc. The progress, browser support and potential for spec completion and future browser adoption.

Contributor

stefanpenner commented Jul 10, 2015

It would be great for future work to integrate with ember-deploy, which I believe could automatically enable SRI for assets deployed to cdn.

It would be good if that deploy step would also valid the deploy validates.

Something worth adding to this rfc. The progress, browser support and potential for spec completion and future browser adoption.

@stefanpenner

This comment has been minimized.

Show comment
Hide comment
@stefanpenner

stefanpenner Jul 10, 2015

Contributor

@lukemelia I would love your thoughts on the ember deploy side of things (or maybe you can pull in the appropriate people)

Contributor

stefanpenner commented Jul 10, 2015

@lukemelia I would love your thoughts on the ember deploy side of things (or maybe you can pull in the appropriate people)

@stefanpenner

This comment has been minimized.

Show comment
Hide comment
@stefanpenner

stefanpenner Jul 10, 2015

Contributor

It is also worth noting, a segment on the site will need to be added if we pull this in.

Contributor

stefanpenner commented Jul 10, 2015

It is also worth noting, a segment on the site will need to be added if we pull this in.

@lukemelia

This comment has been minimized.

Show comment
Hide comment
@lukemelia

lukemelia Jul 10, 2015

The next version of ember-cli-deploy 0.5.0 is based on a pipeline + plugins architecture. A plugin would be be an excellent fit for adding SRI attributes.

If we went that route, we would potentially lose the "SRI-by-default" benefit. But, personally, I would like to see the fingerprinting and prepending also become deploy pipeline plugins eventually. I think understanding their order of execution would be a lot easier that way.

/cc @achambers @LevelbossMike

lukemelia commented Jul 10, 2015

The next version of ember-cli-deploy 0.5.0 is based on a pipeline + plugins architecture. A plugin would be be an excellent fit for adding SRI attributes.

If we went that route, we would potentially lose the "SRI-by-default" benefit. But, personally, I would like to see the fingerprinting and prepending also become deploy pipeline plugins eventually. I think understanding their order of execution would be a lot easier that way.

/cc @achambers @LevelbossMike

@achambers

This comment has been minimized.

Show comment
Hide comment
@achambers

achambers Jul 10, 2015

Member

@lukemelia We want to prepackage the build plugin by default so that ember-cli-deploy can always at least do that. We could do the same thing with the SRI plugin too right? So, by default your deploy will build with SRI attributes.

Member

achambers commented Jul 10, 2015

@lukemelia We want to prepackage the build plugin by default so that ember-cli-deploy can always at least do that. We could do the same thing with the SRI plugin too right? So, by default your deploy will build with SRI attributes.

@jonathanKingston

This comment has been minimized.

Show comment
Hide comment
@jonathanKingston

jonathanKingston Jul 10, 2015

Member

Something worth adding to this rfc. The progress, browser support and potential for spec completion and future browser adoption.

Will add to both the plugin README and RFC tonight.

It is also worth noting, a segment on the site will need to be added if we pull this in.

100% and mostly this should be a copy and paste from the README

I would like to see the fingerprinting and prepending also become deploy pipeline plugins eventually.

Can I suggest that this will lock out people with custom build processes like ourselves, if instead an addon could also be a plugin this might make a transition simpler.
Ultimately if Ember is removing this, then I will likely be forced to either hack into our deploy step ember-build or somehow make our own with the underlying broccoli plugins.

So if an addon could know when it was being used as a build process plugin it could give a better experience there. So for example if told by ember-build the origin and the crossorigin status of the CDN domain the code in its current state would give the best experience. The addon would just need to know when it is going to be used in this manner.

Ultimately the addon is only a paper thin bit of code passing through to the broccoli however does ember really want an addon and a build plugin for everything similar to this?

Either that or the ember build command itself always uses deploy and by default builds to dist/.

Member

jonathanKingston commented Jul 10, 2015

Something worth adding to this rfc. The progress, browser support and potential for spec completion and future browser adoption.

Will add to both the plugin README and RFC tonight.

It is also worth noting, a segment on the site will need to be added if we pull this in.

100% and mostly this should be a copy and paste from the README

I would like to see the fingerprinting and prepending also become deploy pipeline plugins eventually.

Can I suggest that this will lock out people with custom build processes like ourselves, if instead an addon could also be a plugin this might make a transition simpler.
Ultimately if Ember is removing this, then I will likely be forced to either hack into our deploy step ember-build or somehow make our own with the underlying broccoli plugins.

So if an addon could know when it was being used as a build process plugin it could give a better experience there. So for example if told by ember-build the origin and the crossorigin status of the CDN domain the code in its current state would give the best experience. The addon would just need to know when it is going to be used in this manner.

Ultimately the addon is only a paper thin bit of code passing through to the broccoli however does ember really want an addon and a build plugin for everything similar to this?

Either that or the ember build command itself always uses deploy and by default builds to dist/.

@stefanpenner

This comment has been minimized.

Show comment
Hide comment
@stefanpenner

stefanpenner Jul 10, 2015

Contributor

Ultimately if Ember is removing this, then I will likely be forced to either hack into our deploy step ember-build or somehow make our own with the underlying broccoli plugins.

Is there a path where ember-deploy can live healthily in you existing flow? I can't help but feel we can do an even better job with more input.

Ultimately, I don't want to force these concepts to be entangled if doing so causes many users grief.

Contributor

stefanpenner commented Jul 10, 2015

Ultimately if Ember is removing this, then I will likely be forced to either hack into our deploy step ember-build or somehow make our own with the underlying broccoli plugins.

Is there a path where ember-deploy can live healthily in you existing flow? I can't help but feel we can do an even better job with more input.

Ultimately, I don't want to force these concepts to be entangled if doing so causes many users grief.

@jonathanKingston

This comment has been minimized.

Show comment
Hide comment
@jonathanKingston

jonathanKingston Jul 10, 2015

Member

Is there a path where ember-deploy can live healthily in you existing flow?

Pretty much the best you could do is make the default config use the build/ dir. I have thought about it at great length and there are lots of issues that I can see (some which may be resolvable but others are unlikely)

We are likely an edge case however here is a few issues I see that don't fit:

  • Config is available to all developers, this doesn't work for us
  • Build systems like docker/chef/puppet are not hooked in easily
  • QA process can't be done by a developer so giving them ability to put straight to live isn't ok
  • Ultimately in a security environment we wish to prove that what was tested on staging is the same package of files that goes onto live
  • Without a robust API version system on backend they need to roll out together (for us this risk isn't worth it)
    • Which means that redis store would need to be replaced with something that can speak to the backend build process (which seems to defeat the point of the whole system here).
  • Customising the hooks to fit how we build our app will take a whole heap of time
  • Giving another application write access to our CDN isn't good
  • Requiring a new NoSQL for index storage for the server isn't good - we would likely need to write a new storage to use symlinks instead
Member

jonathanKingston commented Jul 10, 2015

Is there a path where ember-deploy can live healthily in you existing flow?

Pretty much the best you could do is make the default config use the build/ dir. I have thought about it at great length and there are lots of issues that I can see (some which may be resolvable but others are unlikely)

We are likely an edge case however here is a few issues I see that don't fit:

  • Config is available to all developers, this doesn't work for us
  • Build systems like docker/chef/puppet are not hooked in easily
  • QA process can't be done by a developer so giving them ability to put straight to live isn't ok
  • Ultimately in a security environment we wish to prove that what was tested on staging is the same package of files that goes onto live
  • Without a robust API version system on backend they need to roll out together (for us this risk isn't worth it)
    • Which means that redis store would need to be replaced with something that can speak to the backend build process (which seems to defeat the point of the whole system here).
  • Customising the hooks to fit how we build our app will take a whole heap of time
  • Giving another application write access to our CDN isn't good
  • Requiring a new NoSQL for index storage for the server isn't good - we would likely need to write a new storage to use symlinks instead
@stefanpenner

This comment has been minimized.

Show comment
Hide comment
@stefanpenner

stefanpenner Jul 10, 2015

Contributor

We are likely an edge case however here is a few issues I see that don't fit:

we should revisit this outside of this RFC, sorry for bringing it up. But thanks for the details.

Contributor

stefanpenner commented Jul 10, 2015

We are likely an edge case however here is a few issues I see that don't fit:

we should revisit this outside of this RFC, sorry for bringing it up. But thanks for the details.

@jonathanKingston

This comment has been minimized.

Show comment
Hide comment
@jonathanKingston

jonathanKingston Jul 10, 2015

Member

@stefanpenner yeah I was going to move that to be a issue on ember-cli-deploy but I don't really know the roadmap if ember build is being ripped out of ember-cli.

However the code be it in ember-cli core or ember-cli-deploy can be moved to the new way later.

Right now ember-cli could give relative path SRI out the box with zero config safely.

The transition to deploy would not impact a developer using ember-cli as the attributes should be the same.

Member

jonathanKingston commented Jul 10, 2015

@stefanpenner yeah I was going to move that to be a issue on ember-cli-deploy but I don't really know the roadmap if ember build is being ripped out of ember-cli.

However the code be it in ember-cli core or ember-cli-deploy can be moved to the new way later.

Right now ember-cli could give relative path SRI out the box with zero config safely.

The transition to deploy would not impact a developer using ember-cli as the attributes should be the same.

@stefanpenner

This comment has been minimized.

Show comment
Hide comment
@stefanpenner

stefanpenner Jul 10, 2015

Contributor

if ember build is being ripped out of ember-cli.

I don't see that happening. But clearly some better coordiation between deploy + build is needed.

Contributor

stefanpenner commented Jul 10, 2015

if ember build is being ripped out of ember-cli.

I don't see that happening. But clearly some better coordiation between deploy + build is needed.

@jonathanKingston

This comment has been minimized.

Show comment
Hide comment
@jonathanKingston

jonathanKingston Jul 13, 2015

Member

Some further outstanding issues:

  • Non stylesheet resources need to not be given an integrity attribute (This may be added to a later spec however it isn't supported so developers shouldn't be given false hope) - I will be patching this once my test pass
  • The spec may be changing to fail-close on lack of crossorigin attribute for CORS which will lead to simpler documentation on our side 👍
Member

jonathanKingston commented Jul 13, 2015

Some further outstanding issues:

  • Non stylesheet resources need to not be given an integrity attribute (This may be added to a later spec however it isn't supported so developers shouldn't be given false hope) - I will be patching this once my test pass
  • The spec may be changing to fail-close on lack of crossorigin attribute for CORS which will lead to simpler documentation on our side 👍
@jonathanKingston

This comment has been minimized.

Show comment
Hide comment
@jonathanKingston

jonathanKingston Jul 18, 2015

Member

@stefanpenner here are the commits as mentioned:
jonathanKingston/ember-cli@0eecd25
jonathanKingston/ember-cli@2599b6e

This expects version 1.0.0 of the addon which has not been published yet, however this should be ready by the end of the day.

The change for the specification to fail-close should make no difference to us as it should not ever happen. Mailing list

ember-cli-sri uses: broccoli-sri-hash uses: sri-toolbox

Member

jonathanKingston commented Jul 18, 2015

@stefanpenner here are the commits as mentioned:
jonathanKingston/ember-cli@0eecd25
jonathanKingston/ember-cli@2599b6e

This expects version 1.0.0 of the addon which has not been published yet, however this should be ready by the end of the day.

The change for the specification to fail-close should make no difference to us as it should not ever happen. Mailing list

ember-cli-sri uses: broccoli-sri-hash uses: sri-toolbox

@lukemelia

This comment has been minimized.

Show comment
Hide comment
@lukemelia

lukemelia Jul 19, 2015

@jonathanKingston what is the relationship between SRI and gzipping? Is the provided fingerprint expected to be after decoding content or before?

In practical terms, will gzipping images, css & js as part of a deployment process invalidate the SRI fingerprints?

lukemelia commented Jul 19, 2015

@jonathanKingston what is the relationship between SRI and gzipping? Is the provided fingerprint expected to be after decoding content or before?

In practical terms, will gzipping images, css & js as part of a deployment process invalidate the SRI fingerprints?

@jonathanKingston

This comment has been minimized.

Show comment
Hide comment
@jonathanKingston

jonathanKingston Jul 19, 2015

Member

@lukemelia it is checked after gzipping (I agree the algo is not so clear - I'll raise that as an issue).

The company I work for is using a slightly older version of the addon: https://portal.cyber-ami.com/ (icons should not have the integrity) however we use gzip and the page gets checked correctly in the latest chrome.

Images are not checked in the latest version of the specification as that will be a level 2 bit of work along with nested images within CSS.

Member

jonathanKingston commented Jul 19, 2015

@lukemelia it is checked after gzipping (I agree the algo is not so clear - I'll raise that as an issue).

The company I work for is using a slightly older version of the addon: https://portal.cyber-ami.com/ (icons should not have the integrity) however we use gzip and the page gets checked correctly in the latest chrome.

Images are not checked in the latest version of the specification as that will be a level 2 bit of work along with nested images within CSS.

@mozfreddyb

This comment has been minimized.

Show comment
Hide comment
@mozfreddyb

mozfreddyb Jul 19, 2015

@lukemelia SRI is applied on the representation data, i.e., it undoes transport encoding like gzip.

mozfreddyb commented Jul 19, 2015

@lukemelia SRI is applied on the representation data, i.e., it undoes transport encoding like gzip.

@lukemelia

This comment has been minimized.

Show comment
Hide comment
@lukemelia

lukemelia Jul 19, 2015

@jonathanKingston @mozfreddyb Thanks, I've been working on the next version of ember-cli-deploy, whose plugin ecosystem will include https://github.com/lukemelia/ember-cli-deploy-gzip. It doesn't sound like that will interfere with SRI providing gzipping occurs after SRI runs. 👍

lukemelia commented Jul 19, 2015

@jonathanKingston @mozfreddyb Thanks, I've been working on the next version of ember-cli-deploy, whose plugin ecosystem will include https://github.com/lukemelia/ember-cli-deploy-gzip. It doesn't sound like that will interfere with SRI providing gzipping occurs after SRI runs. 👍

@jonathanKingston

This comment has been minimized.

Show comment
Hide comment
@jonathanKingston

jonathanKingston Jul 19, 2015

Member

@mozfreddyb thanks, I was looking purely at the fetch algo changes and wasn't seeing it. But then transport encoding doesn't seem to be mentioned in fetch either?

Member

jonathanKingston commented Jul 19, 2015

@mozfreddyb thanks, I was looking purely at the fetch algo changes and wasn't seeing it. But then transport encoding doesn't seem to be mentioned in fetch either?

stefanpenner added a commit that referenced this pull request Jul 19, 2015

@stefanpenner stefanpenner merged commit 4d59271 into ember-cli:master Jul 19, 2015

@jonathanKingston

This comment has been minimized.

Show comment
Hide comment
@jonathanKingston
Member

jonathanKingston commented Jul 19, 2015

@stefanpenner thanks 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment