Skip to content

v0.4.1

Choose a tag to compare

View all tags
@jwinarske jwinarske released this 14 Aug 17:37
· 4 commits to main since this release
v0.4.1
ad8c469
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Recommended upgrade for all users, required for Flutter users. pana 160/160.

Fixes a regression that made 0.4.0 unusable from Flutter

hooks >=2.1.0 depends on meta ^1.19.0
flutter_test from sdk depends on meta 1.18.0
→ version solving failed

Every Flutter app depends on flutter_test, so no Flutter project on an SDK pinning meta 1.18.0 (3.44.x) could depend on appstream_dart 0.4.0 at all. The bundled example was one of them, which is how this surfaced. CI had missed it because its Flutter job runs 3.47.0.

Constraints are now hooks: '>=1.0.2 <3.0.0' and code_assets: '>=1.0.0 <2.0.0', which resolve to 2.1.0/1.2.1 standalone and 1.0.2/1.0.0 under an older Flutter. The build hook is source-compatible with both majors, so the pana score is unaffected.

Native symbols now resolve through the asset table

hook/build.dart published libappstream.so as a code asset, but the Dart VM consults its asset table only for @Native declarations — a plain DynamicLibrary.open(name) never sees it. The asset was therefore built and never used, and bindings.dart compensated with a seven-step runtime search.

Symbols are now @Native externals bound to @DefaultAsset, and that search is gone (~180 lines): a /proc/self/maps scan, a glob through .dart_tool/hooks_runner/ internals, and candidates derived from Platform.script, the executable, and the current directory.

Security: those CWD-relative candidates meant the process would load libappstream.so from ./lib, ./build, or ./src/build. Running an application from a directory an attacker can write to was enough to get a library of their choosing loaded.

The public API is unchanged — AppstreamBindings is not exported.

Deployment note

Resolution goes through NativeAssetsManifest.json, which maps the asset to the plain soname libappstream.so, so the final dlopen uses the system loader. The standard Flutter Linux runner sets RPATH=$ORIGIN/lib and bundles the library, so it just works. Embedders whose binary lives outside the bundle (ivi-homescreen, for example) need it on LD_LIBRARY_PATH:

LD_LIBRARY_PATH=/path/to/bundle/lib homescreen -b /path/to/bundle

Note that flutter build bundle does not perform Linux native-asset packaging — use flutter build linux. The README documents this.

Verification

Exercised on three runtimes against the real 48 MB Flathub catalog:

  • dart run / dart test — 45/45
  • Flutter example under GTK on Wayland — full import, 4677 components, 319 languages
  • Same example on ivi-homescreen on Wayland — same result

Throughput is unchanged (416/411 ms with @Native vs 414/409 ms before): the FFI boundary is crossed twice per parse and components stream over the Dart port, so the binding mechanism cannot move it.

149/149 C++ tests (including asan and ubsan), 45/45 Dart, clang-tidy clean, dart analyze --fatal-infos clean, dart pub publish --dry-run 0 warnings.

Full changelog: https://github.com/flatpak-minimal/appstream_dart/blob/v0.4.1/CHANGELOG.md

Assets 2
Loading