Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[Snyk] Fix for 9 vulnerabilities #2

Merged
merged 2 commits into from
Aug 22, 2023
Merged

[Snyk] Fix for 9 vulnerabilities #2

merged 2 commits into from
Aug 22, 2023

Conversation

snyk-bot
Copy link

Snyk has created this PR to fix one or more vulnerable packages in the `npm` dependencies of this project.

Changes included in this PR

  • Changes to the following files to upgrade the vulnerable dependencies to a fixed version:
    • css/css-writing-modes/tools/generators/package.json
    • css/css-writing-modes/tools/generators/.snyk

Vulnerabilities that will be fixed

With an upgrade:
Severity Priority Score (*) Issue Breaking Change Exploit Maturity
high severity 696/1000
Why? Proof of Concept exploit, Has a fix available, CVSS 7.5		 Regular Expression Denial of Service (ReDoS)
SNYK-JS-ANSIREGEX-1583908		 Yes Proof of Concept
medium severity 526/1000
Why? Proof of Concept exploit, Has a fix available, CVSS 4.1		 Arbitrary Code Injection
SNYK-JS-EJS-1049328		 Yes Proof of Concept
high severity 726/1000
Why? Proof of Concept exploit, Has a fix available, CVSS 8.1		 Remote Code Execution (RCE)
SNYK-JS-EJS-2803307		 Yes Proof of Concept
high severity 589/1000
Why? Has a fix available, CVSS 7.5		 Regular Expression Denial of Service (ReDoS)
SNYK-JS-MINIMATCH-1019388		 Yes No Known Exploit
medium severity 479/1000
Why? Has a fix available, CVSS 5.3		 Regular Expression Denial of Service (ReDoS)
SNYK-JS-MINIMATCH-3050818		 Yes No Known Exploit
high severity 619/1000
Why? Has a fix available, CVSS 8.1		 Arbitrary Code Execution
npm:ejs:20161128		 Yes No Known Exploit
medium severity 509/1000
Why? Has a fix available, CVSS 5.9		 Cross-site Scripting (XSS)
npm:ejs:20161130		 Yes No Known Exploit
medium severity 509/1000
Why? Has a fix available, CVSS 5.9		 Denial of Service (DoS)
npm:ejs:20161130-1		 Yes No Known Exploit
high severity 589/1000
Why? Has a fix available, CVSS 7.5		 Regular Expression Denial of Service (ReDoS)
npm:minimatch:20160620		 Yes No Known Exploit

(*) Note that the real score may have changed since the PR was raised.

Commit messages
Package name: gulp The new version differs by 134 commits.

See the full diff

Package name: gulp-ejs The new version differs by 233 commits.

See the full diff

With a Snyk patch:
Severity Priority Score (*) Issue Exploit Maturity
high severity 589/1000
Why? Has a fix available, CVSS 7.5		 Regular Expression Denial of Service (ReDoS)
npm:minimatch:20160620		 No Known Exploit

(*) Note that the real score may have changed since the PR was raised.

Check the changes in this PR to ensure they won't cause issues with your project.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.

For more information:
🧐 View latest project report

🛠 Adjust project settings

📚 Read more about Snyk's upgrade and patch logic

Learn how to fix vulnerabilities with free interactive lessons:

🦉 Regular Expression Denial of Service (ReDoS)
🦉 Arbitrary Code Injection
🦉 Cross-site Scripting (XSS)

snyk-bot and others added 2 commits April 27, 2023 04:01
@changeset-bot
Copy link

changeset-bot bot commented Aug 22, 2023

⚠️ No Changeset found

Latest commit: 9c0a0b0

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@Woodpile37 Woodpile37 merged commit e6f5c5f into master Aug 22, 2023
Woodpile37 pushed a commit that referenced this pull request Aug 29, 2023
@masayuki-nakano @moz-wptsync-bot
Make HTMLEditor::HandleHTMLIndentAroundRanges validate DOM tree in …
6381b6c 
…each time of the loop

There are 2 possible scenarios which are not handled by the method.

1. Moving content node to new `<blockquote>` has already been moved to outside
of the editing host.
2. There is no container to insert new `<blockquote>`, e.g., in an inline
editing host.

In the case #1, we should ignore the ex-child node.  In the case #2, we should
abort it.  Note that Chrome inserts `<blockquote>` even if there is no proper
container.  However, such behavior is disagreed in interop-2023.  Therefore,
it's okay just to abort it for now.

Depends on D180781

Differential Revision: https://phabricator.services.mozilla.com/D180782

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1756237
gecko-commit: 42f3f3ab11b47f1d56d8bcd6a128398539dd1f23
gecko-reviewers: m_kato
Woodpile37 pushed a commit that referenced this pull request Aug 29, 2023
[wdspec] browsingContext.print: fix rounding error in page.py test (w…
fb57353 
…eb-platform-tests#40504)

* [wdspec] browsingContext.print: fix rounding error in page.py test

[pytest](https://github.com/web-platform-tests/wpt/blob/7a087d54be8b6c0ca0181a86dc1ff0b28461c383/webdriver/tests/support/image.py)
uses:

    def cm_to_px(cm): return round(cm * 96 / 2.54)

[js](https://github.com/web-platform-tests/wpt/blob/7a087d54be8b6c0ca0181a86dc1ff0b28461c383/tools/wptrunner/wptrunner/print_pdf_runner.html)
uses:

    const viewport = page.getViewport({ scale: 96. / 72. });
    ...
    canvas.height = viewport.height;
    canvas.width = viewport.width;

This produces a rounding error, even though the dimension is correct:

    >       assert cm_to_px(expected_dimensions["height"]) == height
    E       assert 454 == 453
    E         +454
    E         -453

The inconsistency of rounding in both ends becomes clear when we
eliminate "round" in the pytest side:

    >       assert cm_to_px(expected_dimensions["height"]) == height
    E       assert 453.54330708661416 == 453
    E         +453.54330708661416
    E         -453

There are multiple ways to fix this issue.

Option #1: Use "floor" instead of "round" in pytest.

Option #2: Use a range in the assertion comparison, allowing a
difference of up to +-1.0. This is what this PR does.

The comparison is performed in
[`assert_pdf_dimensions`](https://github.com/web-platform-tests/wpt/blob/b6107cc1ac8b9c2800b4c8e58af719b8e4d9b8db/webdriver/tests/support/fixtures_bidi.py#L210).

The problematic part is .96 / .72 which evaluates to 4/3 = 1.333333....

* use floor in cm_to_px instead of round

* compare to floor and to round instead of a range

* Revert "compare to floor and to round instead of a range"

This reverts commit 63f894e.

* Revert "use floor in cm_to_px instead of round"

This reverts commit 7e65d91.
Woodpile37 pushed a commit that referenced this pull request Oct 6, 2023
@byung-woo @chromium-wpt-export-bot
Fix :has() invalidation bug when removing anchor element's siblings
2f5741f 
This CL fixes a :has() invalidation bug when the following conditions
are met:

1. A style rule uses a :has() pseudo class. The :has() test result is
   affected by the anchor element's relationship to its sibling
   element at fixed distance. (e.g. '.a:has(+ .b) {}')
2. The :has() pseudo class was tested on an anchor element and it
   didn't matched.
3. If a sibling of the anchor element is removed, the :has() will
   match the anchor element.
   (e.g. '<div class=a></div><div id=target></div><div class=b></div>')
4. Remove a sibling of the anchor element so that the :has() matches
   the anchor element. (e.g. 'target.remove();')

For the removal, StyleEngine have to schedule :has() invalidation
even if the removed element doesn't have any identifier stored in
RuleFeatureSet. But it is not efficient to schedule :has()
invalidation for every element removal.

To avoid unnecessary :has() invalidation, StyleEngine checks whether
its parent has the 'ChildrenAffectedByDirectAdjacentRules' flag set
or not.

Currently, the SelectorChecker sets the flag only when it consumes
a direct adjacent combinator(+). This works most cases but it doesn't
work in this case (condition #2) because the SelectorChecker stops
the :has() argument selector matching before consuming the direct
adjacent combinator. Due to this, the parent of the anchor element
doesn't have the 'ChildrenAffectedByDirectAdjacentRules' flag set
and the StyleEngine doesn't schedule the :has() invalidation for the
removal.

To fix the error, when the SelectorChecker tests a :has() pseudo
class on an anchor element and the :has() is affected by the anchor
element's relationship to a sibling at fixed distance, the
SelectorChecker sets the flag of the parent to indicate that
StyleEngine need to schedule :has() invalidation whenever any child
of the element is removed.

Bug: 1480643
Change-Id: I5ec2e3c1db2773020368415f68bca1503367e669
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4864627
Commit-Queue: Byungwoo Lee <[email protected]>
Reviewed-by: Rune Lillesveen <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1198137}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@snyk-bot @Woodpile37