Because each component is hosted in different repository, for N components there are O(N) points of failure, and fallbacking is impossible. I think we should design bowered so it has at least two sources for each component: packaged version and source repository.
The other issue is source tampering. The packaged component (original or mirror) and source can be changed by hackers (or even authors), and vulnerable code is deployed without application author noticing anything.
Poor solutions
Because all logic and information needed for building components is available on client side (bowered gem and Bowered.lock), it is possible to build component from source repository when requested component is not available online in packaged form. We could use Rails assets to host packaged components as we do now.
The solution for source tampering could be including the SHAs of packaged components in Bowerfile.lock and verifying on installation. There also could be online repository of (similar to json api of bower.io) showing serving all metadata of components (including sha sum).
Problems
If we served packaged components directly on Rails Assets. There would be times when packaging algorithm will change, and we need to re-generate each component on server side. This is very error prone, and behaves the same way as someone tampered packages on server side. It also makes mirroring rather impossible.
The problem with SHAs is following: we allow for developers to specify their own "requires" in Bowerfile, from which manifest file is generated (it's equivalent of "main" file in bower). This means that packaged repository will have different contents and different sha than package sha received from API.
In similar way each time we change build process (ignore some files etc.) the sha of packaged component will change.
Better solutions
The .tar.gz packages available on servers should contain immutable original (not processed) source, and serve SHAs of them. This has few advantages:
SHAs will change only if someone tamper with source
It makes mirroring dead simple (rsync or simple packaging of sources)
Packaging servers don't need to care about building stuff
Because bowered gem is locked in Gemfile.lock and downloaded sources are verified to have specific SHA, the build process is deterministic and safe on any deployment.
If original packaging repository is not available, one of mirror repositories can be used (mirror urls can be set in DNS record, signed). If mirror repositories are not available, bowered can build component from source repository.
The last security issue is index file containing list of components, their source locations, SHAs of them, and cached dependencies (for quick dependency resolution). They can be signed using PGP by original packaging repository.
Because each component is hosted in different repository, for N components there are O(N) points of failure, and fallbacking is impossible. I think we should design bowered so it has at least two sources for each component: packaged version and source repository.
The other issue is source tampering. The packaged component (original or mirror) and source can be changed by hackers (or even authors), and vulnerable code is deployed without application author noticing anything.
Poor solutions
Because all logic and information needed for building components is available on client side (bowered gem and Bowered.lock), it is possible to build component from source repository when requested component is not available online in packaged form. We could use Rails assets to host packaged components as we do now.
The solution for source tampering could be including the SHAs of packaged components in
Bowerfile.lockand verifying on installation. There also could be online repository of (similar to json api of bower.io) showing serving all metadata of components (including sha sum).Problems
If we served packaged components directly on Rails Assets. There would be times when packaging algorithm will change, and we need to re-generate each component on server side. This is very error prone, and behaves the same way as someone tampered packages on server side. It also makes mirroring rather impossible.
The problem with SHAs is following: we allow for developers to specify their own "requires" in Bowerfile, from which manifest file is generated (it's equivalent of "main" file in bower). This means that packaged repository will have different contents and different sha than package sha received from API.
In similar way each time we change build process (ignore some files etc.) the sha of packaged component will change.
Better solutions
The .tar.gz packages available on servers should contain immutable original (not processed) source, and serve SHAs of them. This has few advantages:
Because bowered gem is locked in Gemfile.lock and downloaded sources are verified to have specific SHA, the build process is deterministic and safe on any deployment.
If original packaging repository is not available, one of mirror repositories can be used (mirror urls can be set in DNS record, signed). If mirror repositories are not available, bowered can build component from source repository.
The last security issue is index file containing list of components, their source locations, SHAs of them, and cached dependencies (for quick dependency resolution). They can be signed using PGP by original packaging repository.