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

chore: Update idna to 1.0, drop unicode-normalization #18598

Merged
merged 2 commits into from
Dec 10, 2024

Conversation

torokati44
Copy link
Member

@torokati44 torokati44 commented Nov 14, 2024

Now that all of url, cookie_store, and publicsuffix are out with releases depending on idna 1.0.x, we can switch to that.

With this, the idna_adapter crate is introduced, which lets us globally control (in a hacky, but workable way), which IDNA backend we want, and allows dropping support for it entirely.

See: https://crates.io/crates/idna_adapter

It should probably be locked to 1.0.x with some mechanism. (Adding it directly to Cargo.toml, and/or configuring cargo-deny, since we already have it...)

Cc: @adrian17, since I remember you complaining a lot about the binary size bloat caused by these encoding tables... 😅

@torokati44 torokati44 added A-deps Area: Dependencies T-chore Type: Chore (like updating a dependency, it's gotta be done) labels Nov 14, 2024
@evilpie
Copy link
Collaborator

evilpie commented Nov 14, 2024

We should definitely add something to (probably) deny, because this mechanism seems very brittle. I guess we could deny unicode-normalization as well now?

@torokati44
Copy link
Member Author

The size of the vanilla WASM module after wasm-bindgen and wasm-opt:

idna_adapter Bytes Diff Relative
(base) 12,915,705 0 100.0%
1.0 12,707,466 -208,239 98.4%
1.1 12,964,026 +48,321 100.4%
1.2 12,821,717 -93,988 99.3%

@torokati44
Copy link
Member Author

Let's not forget to do a @dependabot unignore url after this is dealt with.

deny.toml Show resolved Hide resolved
@torokati44
Copy link
Member Author

On top of adding bans in deny.toml, it would be great if somehow it could be added as a permanent exception to cargo update, so it won't try to update (and certainly not by duplicating it!) idna_adapter... Any ideas? :/

@torokati44
Copy link
Member Author

torokati44 commented Dec 1, 2024

See this for testing:

package {
    import flash.display.Loader;
    import flash.display.Sprite;
    import flash.net.URLRequest;

    public class Test extends Sprite {
        var nextY = 0;

        function loadFromDomain(domain: String) {
            var imageURL:String = domain + "/img/navi/top.gif";
            var loader:Loader = new Loader();
            var req:URLRequest = new URLRequest(imageURL);
            trace("Loading from " + req.url);

            loader.load(req);
            loader.y = this.nextY;
            this.nextY += 50;
            addChild(loader);
        }

        public function Test() {
            loadFromDomain("https://www.schoen.de");
            loadFromDomain("https://www.schön.de");
            loadFromDomain("https://www.xn--schn-7qa.de");
        }
    }
}

SWF here: test.zip

On Linux, I see all 3 instances of the same image, on Windows, the middle one is missing (with the FP debugger showing an IO exception about it).

@torokati44
Copy link
Member Author

This will also be needed to resolve this advisory:
https://rustsec.org/advisories/RUSTSEC-2024-0421

@adrian17
Copy link
Collaborator

adrian17 commented Dec 9, 2024

98.4%

To be fair, -200kB was a way bigger deal when our wasm bundle was like 2MB :(

@adrian17
Copy link
Collaborator

adrian17 commented Dec 9, 2024

Anyway, as long as evilpie's concern is resolved, I think this is safe-ish?
Worst case, if something breaks, we can just trivially revert this.

@torokati44
Copy link
Member Author

Worst case, if something breaks, we can just trivially revert this.

I don't think that would be necessary even, we can easily switch between the backends now via the idna_adapter version series.

@torokati44
Copy link
Member Author

Thanks to both of you! 😊

@torokati44 torokati44 merged commit f24fcc2 into ruffle-rs:master Dec 10, 2024
22 checks passed
@torokati44
Copy link
Member Author

@dependabot unignore url

@Lord-McSweeney Lord-McSweeney removed the waiting-on-review Waiting on review from a Ruffle team member label Dec 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-deps Area: Dependencies T-chore Type: Chore (like updating a dependency, it's gotta be done)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants