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.

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

[pull] master from gorhill:master #445

Open
wants to merge 430 commits into
base: master
Choose a base branch
from
Open

[pull] master from gorhill:master #445

wants to merge 430 commits into from

Conversation

pull[bot]
Copy link

@pull pull bot commented Jun 8, 2024

See Commits and Changes for more details.


Created by pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

@pull pull bot added the ⤵️ pull label Jun 8, 2024
gorhill and others added 29 commits September 4, 2024 11:37
* Maintenance for the Serbo-Croatian Filters section

* Implemented the request to move to contentURLs

I sure I hope I understood the request correctly, or things would get slightly awkward for me.
For the sake of convenience for filter list maintainers, this commit
add ability to quote static network option values, so as to avoid the
need to escape commas when parser ambiguity arises.

The quotes can be `"`, `'`, or backticks.

Example, the following filter requires escaping commas:

  example.com$xhr,replace=/"loremIpsum.*?([A-Z]"\}|"\}{2\,4})\}\]\,//,1p

Can be now rewritten with no need to escape when using quotes:

  example.com$xhr,replace='/"loremIpsum.*?([A-Z]"\}|"\}{2,4})\}\],//',1p
The purpose is to block according to the ip address of a network
request. In the current implementation, the filter option can only
be enforced at onHeadersReceived time.

The new filter option cannot be enforced in Chromium-based browsers
since the ip address of network requests is available only at
onResponseStarted time, which is not blocking.

The value assigned to `ipaddress` can either be a plain string which
must match exactly a given ip address, or a regex which will be
matched against the ip address.

The `ipaddress` option can only be enforced when the extension
framework does provide a valid ip address in a onHeadersReceived
listener. For instance, cached resources do not have a valid ip
address and thus can't be a match to `ipaddress` option.

Example:

  *$script,ipaddress=93.184.215.14
Properly report unsupported `header=` and `ipaddress=` option in
log file.

`header=` support may become possible soon with Chromium 128
introducing blocking according to response headers content.
If an IP address can be extracted from the hostname portion of
a URL, the IP address matching will be performed at onBeforeRequest()
time.

Regardless, IP address matching will subsequently always be performed
at onHeadersReceived() time as the request details at that point
contain a reliable IP address value on supported platforms (Firefox-
only as of now).

The `cap_ipaddress` now evaluates to `true` in Chromium-based
browsers. Even though these browsers are unable to provide reliable
IP address value at onHeadersReceived() time, they can still
perform IP address matching for IP address extracted from hostname
portion of a URL.
This commit makes the DNS resolution code better suited for both
filtering on cname and ip address. The change allows early availability
of ip address so that `ipaddress=` option can be matched at
onBeforeRequest time.

As a result, it is now possible to block root document using
`ipaddress=` option -- so long as an ip address can be extracted
before first onBeforeRequest() call.

Related issue:
uBlockOrigin/uBlock-issues#2792

Caveat
------

the ip address used is the first one among the list of ip
addresses returned by dns.resolve() method. There is no way for uBO
to know which exact ip address will be used by the browser when
sending the request, so this is at most a best guess. The exact IP
address used by the browser is available at onHeadersReceived time,
and uBO will also filter according to this value, but by then the
network request has already been sent to the remote server.

Possibly a future improvement would make available the whole list
of ip addresses to the filtering engine, but even then it's impossible
to know with certainty which ip address will ultimately be used by the
browser -- it is entirely possible that the ip address used by the
browser might not be in the list received through dns.resolve().
gorhill and others added 30 commits October 28, 2024 14:26
commit a4d3194
Author: daylight <[email protected]>
Date:   Fri Nov 1 21:01:06 2024 +0300

    Delete .gitmodules

commit 57b7d98
Author: daylight <[email protected]>
Date:   Fri Nov 1 17:47:50 2024 +0300

    Delete dist/mv3/log.txt

commit c936a72
Author: daylight <[email protected]>
Date:   Fri Nov 1 17:47:16 2024 +0300

    Update dist/README.md

commit b5aaec4
Author: daylight <[email protected]>
Date:   Fri Nov 1 17:46:53 2024 +0300

    Update release head

commit be2da15
Author: daylight <[email protected]>
Date:   Fri Nov 1 17:46:37 2024 +0300

    Update links in readme

commit 3019dfc
Author: daylight <[email protected]>
Date:   Fri Nov 1 17:46:16 2024 +0300

    Update contributing guide

commit 3b9333d
Author: daylight <[email protected]>
Date:   Fri Nov 1 17:45:53 2024 +0300

    Update CI

commit 2831a0d
Author: daylight <[email protected]>
Date:   Fri Nov 1 17:45:31 2024 +0300

    Update config
Revert "Update CI"

This reverts commit 3b9333d.
Allow negative integer as valid value.

Related issue:
#3927

Additionally, move cookie-related scriptlets/helpers into its own
source code file.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants