[bug] `assetScope` suddenly no longer working?

[frnsys]

Describe the bug

I tried upgrading my tauri versions (from 1.2.0) and suddenly can't load any assets. For example, when loading an asset now I get these errors:

asset protocol not configured to allow the path: /home/ftseng/.config/hundun/.thumbs/references.media.environments.coast.rzbu4ds397p91.jpg.jpg

and in the frontend:

[Error] Unhandled Promise Rejection: path not allowed on the configured scope: /home/ftseng/.config/hundun/.thumbs

I've tried a number of different assetScope configs, even trying the complete paths for some of the assets, to no avail:

 "assetScope": ["$APP/*", "$APPCONFIG/*", "$APPDATA/*", "*", "/home/ftseng/.config/hundun/.thumbs/references.media.environments.coast.rzbu4ds397p91.jpg.jpg"]

and

"assetScope": ["$APP/*", "$APPCONFIG/*", "$APPDATA/*", "*",
            "$APP/**", "$APPCONFIG/**", "$APPDATA/**"]

and

"assetScope": ["**"]

This is the url for the example that is being passed to the img tag: "asset://localhost/%2Fhome%2Fftseng%2F.config%2Fhundun%2F.thumbs%2Freferences.media.environments.coast.rzbu4ds397p91.jpg.jpg", produced using convertFileSrc.

I seem to be having a similar issue with the fs.scope config, where I can't iterate over files anymore.

Am I just misconfiguring something? I'm totally stumped.

Reproduction

1. Try to load the asset in HTML

Expected behavior

The assets to load without issue

Platform and versions

hundun@0.1.0 tauri
tauri "info"

Environment
› OS: Ubuntu 22.04 X64
› Node.js: 18.1.0
› npm: 8.8.0
› pnpm: Not installed!
› yarn: Not installed!
› rustup: 1.25.1
› rustc: 1.68.0-nightly
› cargo: 1.68.0-nightly
› Rust toolchain: nightly-x86_64-unknown-linux-gnu

Packages
› @tauri-apps/cli [NPM]: 1.2.3
› @tauri-apps/api [NPM]: 1.2.0
› tauri [RUST]: 1.2.4,
› tauri-build [RUST]: 1.2.1,
› tao [RUST]: 0.15.8,
› wry [RUST]: 0.23.4,

App
› build-type: bundle
› CSP: default-src 'self'; img-src 'self' asset: https://asset.localhost
› distDir: ../build
› devPath: http://localhost:8080/
› framework: React
› bundler: Webpack

App directory structure
├─ tauri
├─ assets
├─ .git
├─ public
├─ src
├─ node_modules
└─ scripts

Stack trace

No response

Additional context

My complete config:

{
  "$schema": "../node_modules/@tauri-apps/cli/schema.json",
  "build": {
    "beforeBuildCommand": "npm run build",
    "beforeDevCommand": "npm run start",
    "devPath": "http://localhost:8080",
    "distDir": "../build"
  },
  "package": {
    "productName": "hundun",
    "version": "0.1.0"
  },
  "tauri": {
    "allowlist": {
      "shell": {
        "open": true
      },
      "dialog": {
        "all": true
      },
      "protocol": {
        "asset": true,
        "assetScope": ["**", "**/*"]
      },
      "fs": {
        "all": true,
        "scope": ["**", "**/*"]
      },
      "path": {
        "all": true
      }
    },
    "bundle": {
      "active": true,
      "category": "DeveloperTool",
      "copyright": "",
      "deb": {
        "depends": []
      },
      "externalBin": [],
      "icon": [
        "icons/32x32.png",
        "icons/128x128.png",
        "icons/128x128@2x.png",
        "icons/icon.icns",
        "icons/icon.ico"
      ],
      "identifier": "hundun",
      "longDescription": "",
      "macOS": {
        "entitlements": null,
        "exceptionDomain": "",
        "frameworks": [],
        "providerShortName": null,
        "signingIdentity": null
      },
      "resources": [],
      "shortDescription": "",
      "targets": "all",
      "windows": {
        "certificateThumbprint": null,
        "digestAlgorithm": "sha256",
        "timestampUrl": ""
      }
    },
    "security": {
      "csp": "default-src 'self'; img-src 'self' asset: https://asset.localhost"
    },
    "updater": {
      "active": false
    },
    "windows": [
      {
        "fullscreen": false,
        "height": 600,
        "resizable": true,
        "title": "hundun",
        "width": 800
      }
    ]
  }
}

[frnsys]

I did a bit more investigating and it looks like the problem is because I have a hidden directory in my path (.thumbs). If I move my files to a non-hidden directory, it works fine. Same with the fs.scope config--only hidden directories show [Error] Unhandled Promise Rejection: path not allowed on the configured scope: /home/ftseng/.config/hundun/.thumbs in the JS console.

[frnsys]

I've narrowed down the problem to this line:

      let options = glob::MatchOptions {
        // this is needed so `/dir/*` doesn't match files within subdirectories such as `/dir/subdir/file.txt`
        // see: https://github.com/tauri-apps/tauri/security/advisories/GHSA-6mv3-wm7j-h4w5
        require_literal_separator: true,
        // dotfiles are not supposed to be exposed by default
        #[cfg(unix)]
        require_literal_leading_dot: true,
        ..Default::default()
      };

Because require_literal_leading_dot is set to true I have to escape any periods in my filepaths, i.e. "/home/ftseng/.config/hundun/.thumbs/foo.jpg" has to become "/home/ftseng/.config/hundun/thumbs/foo.jpg" (not sure why the period in .config doesn't matter).

Here's a minimal example:

use glob::Pattern;
use std::path::Path;

fn main() {
    let options = glob::MatchOptions {
        // this is needed so `/dir/*` doesn't match files within subdirectories such as `/dir/subdir/file.txt`
        // see: https://github.com/tauri-apps/tauri/security/advisories/GHSA-6mv3-wm7j-h4w5
        require_literal_separator: true,
        // dotfiles are not supposed to be exposed by default
        #[cfg(unix)]
        require_literal_leading_dot: true,
        ..Default::default()
    };
    let pattern = Pattern::new("**/*").expect("Pattern was bad");
    let paths = vec![
        "/tmp/.foo/bar.jpg",
        "/tmp/\\.foo/bar.jpg",
        "/tmp/foo/bar.jpg"];
    for path in paths {
        let matches = pattern.matches_path_with(&Path::new(path), options);
        println!("{:?} : {:?}", path, matches);
    }
}

Output:

"/tmp/.foo/bar.jpg" : false
"/tmp/\\.foo/bar.jpg" : true
"/tmp/foo/bar.jpg" : true

I could manually escape directory periods when I use convertFileSrc() but that is probably not an ideal long-term solution. Actually this doesn't work