fhel,jeffmur

Error Handling

Dart cannot natively handle errors, rather 'fails unexpectedly' when C throws any error.

Importance: Flutter must capture errors to alert the user to make changes, so C errors must be converted into Dart

Approach 1: ErrorTranslator 🏆
C++ object that is always passed by reference for every function.
It should capture + handle various (if not all) error types.
From Dart, we would try to access data stored in C Memory to retrieve the current "status" of our function call / stack.

Pros:

Follows same pattern as Afhe, passed by reference with attributes

Cons:

Modifies every existing function

Approach 2: Specialized return types
For objects, create sub-routine .status() returns error message if any
For int or string return types, use -1

Cons:

Non-objects are ambiguous, less control for error messages
Prone to issues, hard coded values

Division

Division is not directly supported, however CKKS does provide a way to divide/multiply via scalars.

This may be a bit complex, will need to do more research

https://eprint.iacr.org/2016/510

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

Update dependency org.jetbrains.kotlin:kotlin-gradle-plugin to v1.9.24
Update dependency gradle to v8.7
Update instrumentisto/flutter Docker tag to v3.22.0
Update dependency flutter_lints to v4
Click on this checkbox to rebase all open PRs at once

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

Update dependency com.android.tools.build:gradle to v8

Detected dependencies

dockerfile

Builder.Dockerfile

instrumentisto/flutter 3.19.3

mcr.microsoft.com/devcontainers/cpp 1-debian-11

github-actions

.github/actions/build-and-push-image/action.yml

actions/checkout v4

docker/setup-buildx-action v3

docker/login-action v3

docker/build-push-action v5

.github/workflows/builder.yml

actions/checkout v4

actions/checkout v4

.github/workflows/feature.yml

actions/checkout v4

dart-lang/setup-dart v1

actions/checkout v4

dorny/paths-filter v3

actions/checkout v4

actions/checkout v4

actions/checkout v4

actions/checkout v4

.github/workflows/publish.yml

actions/checkout v4

dart-lang/setup-dart v1

gradle

dart/android/settings.gradle

dart/android/build.gradle

com.android.tools.build:gradle 7.4.2

example/android/gradle.properties

example/android/build.gradle

com.android.tools.build:gradle 7.4.2

org.jetbrains.kotlin:kotlin-gradle-plugin 1.9.23

example/android/app/build.gradle

gradle-wrapper

example/android/gradle/wrapper/gradle-wrapper.properties

gradle 8.6

pub

dart/pubspec.yaml

ffi ^2.1.0

flutter

path ^1.8.3

flutter_lints ^3.0.0

test ^1.24.3

dart >=3.1.5 <4.0.0

flutter >=1.20.0

example/pubspec.yaml

flutter

cupertino_icons ^1.0.2

flutter_lints ^3.0.0

dart >=3.1.5 <4.0.0

Check this box to trigger a request for Renovate to run again on this repository

Concurrency > 1 Errors

Continued #39 - TLDR: Solution is not scalable. Should only affect dart test --concurrency 16.

Simple Approach: The ErrorTranslator singleton C class stores an error_message that is set in C and read from Dart.

However, when running dart test, the default concurrency is 16. Meaning that at once, we can have up-to 16 instances of Dart Seal objects.

As a result, we may receive intermittent failures when concurrency > 1. This should not affect users as all C FFI calls are synchronous. If there are multiple instances, they would be invoked sequentially.

Potential Solutions:

For each C function, pass Pointer as parameter.
This race condition can be solved by creating / managing ErrorTranslator instances for ffi invocation. However this may be overkill.
For each C function, pass string (char*) as parameter:
Simple, and a bit more transparent. Would require some additional logic to capture errors + return string. May introduce ambiguous complexity

Linux Distribution

Planned: SUMMER 2024

Expected Behavior:

When importing fhel: 0.0.4 from another plugin / flutter app, I would expect all binaries to be packaged on publish.

How does ffi distribution work for linux platforms?

00:01 +0 -1: test/fhe_video_similarity_test.dart: test encrypt [E]                                                                                                                                                                          
  Invalid argument(s): Failed to load dynamic library '/home/jeffmur/build/libfhel.so': /home/jeffmur/build/libfhel.so: cannot open shared object file: No such file or directory
  dart:ffi                                   new DynamicLibrary.open
  package:fhel/ffi.dart 18:27                dylib.<fn>
  package:fhel/ffi.dart 24:2                 dylib
  package:fhel/ffi.dart                      dylib
  package:fhel/afhe/backend.dart 9:56        _c_string_to_backend_type
  package:fhel/afhe/backend.dart             _c_string_to_backend_type
  package:fhel/afhe/backend.dart 32:13       new Backend.set
  package:fhel/afhe.dart 47:23               new Afhe
  package:fhel/seal.dart 13:25               new Seal
  test/fhe_video_similarity_test.dart 24:18  main.<fn>

Current logic escapes 2 nested directories. For Release, this should be configurable somehow.

Issue Filed: flutter/flutter#122499

Approach 1: A little hacky