Skip to content

feat(core): create internal Trusted Types module#39207

Closed
bjarkler wants to merge 2 commits into
angular:masterfrom
bjarkler:trusted-types-module
Closed

feat(core): create internal Trusted Types module#39207
bjarkler wants to merge 2 commits into
angular:masterfrom
bjarkler:trusted-types-module

Conversation

@bjarkler

@bjarkler bjarkler commented Oct 9, 2020

Copy link
Copy Markdown
Contributor

Add a module that provides a Trusted Types policy for use internally by
Angular. The policy is created lazily and stored in a module-local
variable. For now the module does not allow configuring custom policies
or policy names, and instead creates its own policy with 'angular' as a
fixed policy name. This is to more easily support tree-shakability.

Helper functions for unsafely converting strings to each of the three
Trusted Types are also introduced, with names that make it clear that
their use requires a security review. When Trusted Types are not
available, these helper functions fall back to returning strings.

The TypeScript type definitions for Trusted Types is also added as
a dependency. See the individual commits for more details.

PR Checklist

Please check if your PR fulfills the following requirements:

PR Type

What kind of change does this PR introduce?

  • Bugfix
  • Feature
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • CI related changes
  • Documentation content changes
  • angular.io application / infrastructure changes
  • Other... Please describe:

Does this PR introduce a breaking change?

  • Yes
  • No

Other information

This is part of an ongoing effort to add support for Trusted Types to Angular.

Comment thread packages/core/package.json Outdated
"author": "angular",
"license": "MIT",
"dependencies": {
"@types/trusted-types": "^1.0.6",

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this really necessary? Seems redundant 😕

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question, and I would definitely appreciate insights others might have on this. As far as my limited knowledge on npm package dependencies, this seemed to be necessary. Before adding this, the issue was that @types/trusted-types would not be available as a dependency in an Angular application (even after doing an ng update, it wouldn't appear in yarn.lock), since none of Angular's packages had a dependency on it. When I then ran ng build the application would not compile due to missing type definitions for Trusted Types. So without this (and unless there's a different way), existing Angular applications will break unless they explicitly add a dependency on @types/trusted-types themselves.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why would the app fail? Can you give an example of how to reproduce this?
An app would consume the published Angular packages, which are compiled to JS. At that point, any types would have been stripped of (they are a compile-time only thing).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I share @gkalpak's concerns.

I discussed this with @bjarkler and we decided not to expose any of the trusted types as part of Angular's public api for now.

Once microsoft/TypeScript#30024 is fixed (introduces TT into lib.dom.d.ts) then we can expose TT through our core apis, but until then we should avoid it.

One alternative for still shipping TrustedSanitizer would be to ship it as a new package that has a peer dependency on @types/trusted-types. But this is something we can consider once Angular is compatible with TT, which should be the top priority.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The issue seems to be that #39219 and potentially other changes make Trusted Types a part of Angular's public API, which is why dependent applications will also need the type definitions to compile. We're looking into ways to circumvent that, at least until microsoft/TypeScript#30024 is fixed.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem is that later PRs introduce Trusted Types into Angular's public api surface, which then causes the types to be present in our d.ts files. In order for tsc to typecheck our d.ts files when compiling the angular app (without skipLibCheck), tsc will need the definitions.

As described in the other comment, we decided to change our rollout strategy and not expose TT in Angular's public api surface for now.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ahh.. @bjarkler also explained it :) sorry about the noise.

Comment thread packages/core/src/util/security/trusted_types.ts Outdated
Comment thread packages/core/src/util/security/trusted_types.ts Outdated
To facilitate the upcoming Trusted Types support being added to Angular,
add the TypeScript type definitions for the Trusted Types browser API as
a dependency in the root package.json and types.d.ts since they're
needed for compiling the Angular packages.
@bjarkler bjarkler force-pushed the trusted-types-module branch from 455362c to 80dee55 Compare October 13, 2020 15:02
Add a module that provides a Trusted Types policy for use internally by
Angular. The policy is created lazily and stored in a module-local
variable. For now the module does not allow configuring custom policies
or policy names, and instead creates its own policy with 'angular' as a
fixed policy name. This is to more easily support tree-shakability.

Helper functions for unsafely converting strings to each of the three
Trusted Types are also introduced, with documentation that make it clear
that their use requires a security review. When Trusted Types are not
available, these helper functions fall back to returning strings.
@bjarkler bjarkler force-pushed the trusted-types-module branch from 80dee55 to c22fec5 Compare October 13, 2020 15:12

@IgorMinar IgorMinar left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

discussed offline, we'll remove the dep on @types/trusted-types. See other comments for details.

@pullapprove pullapprove Bot requested a review from alxhub October 13, 2020 17:19
@IgorMinar IgorMinar added target: major This PR is targeted for the next major release action: merge The PR is ready for merge by the caretaker labels Oct 13, 2020
* Returns the Trusted Types policy, or null if Trusted Types are not
* enabled/supported. The first call to this function will create the policy.
*/
function getPolicy(): TrustedTypePolicy|null {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that you changed all of these from methods to functions. that's great for minification with Terser! Thank you!

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks to @engelsdamien for pointing that out :)

@IgorMinar IgorMinar left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM now!

Reviewed-for: global-approvers

@IgorMinar IgorMinar removed the request for review from alxhub October 13, 2020 17:29
@IgorMinar IgorMinar added target: minor This PR is targeted for the next minor release and removed target: major This PR is targeted for the next major release labels Oct 13, 2020
@IgorMinar

Copy link
Copy Markdown
Contributor

I'm marking this as "target: minor" since we are not making any breaking change here or introducing a risky change.

@atscott atscott closed this in c4266fb Oct 13, 2020
atscott pushed a commit that referenced this pull request Oct 13, 2020
Add a module that provides a Trusted Types policy for use internally by
Angular. The policy is created lazily and stored in a module-local
variable. For now the module does not allow configuring custom policies
or policy names, and instead creates its own policy with 'angular' as a
fixed policy name. This is to more easily support tree-shakability.

Helper functions for unsafely converting strings to each of the three
Trusted Types are also introduced, with documentation that make it clear
that their use requires a security review. When Trusted Types are not
available, these helper functions fall back to returning strings.

PR Close #39207
@angular-automatic-lock-bot

Copy link
Copy Markdown

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot Bot locked and limited conversation to collaborators Nov 13, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

action: merge The PR is ready for merge by the caretaker cla: yes target: minor This PR is targeted for the next minor release

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants