Missing MinimumOSVersion value in Info.plist causing iOS app bundle validation to fail (Testflight upload):

Invalid MinimumOSVersion. Apps that only support 64-bit devices must specify a deployment target of 8.0 or later. MinimumOSVersion
in 'AppName.app/Frameworks/aries_askar.framework' is ".

Can be fixed locally by manually setting value in Info.plist file.

This problem is also relevant for indy-vdr and anoncreds RN packages.

See this issue in the ACA-Py repository for details on the problem and suspected cause. It appears what is needed is a tweak to how the Askar storage creation process is executed.

Using Askar on Postgres 15 seems to be fine.

Once completed, please add a comment to the ACA-Py issue so we can upgrade the Askar dependency as needed.

As part of the integration of Askar with Aries Framework JavaScript, I'm running a test where I set up two Aries JavaScript Agents based on either Indy SDK or Askar and make them connect and exchange a few simple messages.

In that scenario I noticed a very big performance gap: when using two Indy-based agents, the test takes around 300 ms while it takes almost 40 seconds for two Askar agents. When running with a profiler (v8-profiler-next) in both situations I got the following results:

As you can see, in Askar case the CPU spends 80% of its time in Garbage Collector and almost 15% of the time dereferencing pointers and other wrapper-related-stuff.

An interesting issue in ref-napi came after an initial research on this topic. And after applying the patch proposed in a PR and running the tests again, this problem completely disappeared and actually the Askar Agent performed better than the Indy one (as expected).

The problem is that this fix is not working in Node 14.x and 16.x, as it seems that some fixes in v8 engine related to a "Check failed: result.second." (not sure which ones exactly) were not backported and, as a result, this only works in Node 18.

I had a question come up as I've been working with the Askar Python wrapper.

Consider these lines from the demo script:

    async with store.transaction() as txn:
        # ^ should be faster within a transaction
        for idx in range(PERF_ROWS):
            await txn.insert(
                "txn",
                f"name-{idx}",
                b"value",
                {"~plaintag": "a", "enctag": "b"},
            )
        await txn.commit()

My question pertains to the await txn.commit() on the final line. As I understand it, after commit has been called, the handle is closed. In other words, it is impossible to do something like:

    async with store.transaction() as txn:
        # ^ should be faster within a transaction
        for idx in range(PERF_ROWS):
            await txn.insert(
                "txn",
                f"name-{idx}",
                b"value",
                {"~plaintag": "a", "enctag": "b"},
            )
        await txn.commit()
        await txn.insert(
            "txn",
            f"name-one-more",
            b"value",
            {"~plaintag": "a", "enctag": "b"},
        )
        await txn.commit()

Therefore, calling commit should essentially terminate every async with store.transaction() block and can occur only once within the block. My question: why not call commit on exit of the with block (within the context manager itself)? This seems like an ideal case for using this pattern, in fact, from my perspective at least.

Curious to hear your rationale. Thanks!

This means it can't download it when you install this package for Node.JS on windows.

This is also the case for indy-vdr and anoncreds-rs.

Options are to:

• rename the file that is uploaded to release
• modify the script already used by node-gyp to determine the name

Suggest providing the following sections:

• an overview of what Askar is
• a list of features/capabilities
• how to use it in ACA-Py and other libraries
• Upgrading to Askar from the Indy SDK
• Nice to have: Architecture
• Credit
• Contributing
• License

I would be curious to store the data in the wallet as plain text.

Reading the documentation I came across:

none indicates that no store key is used. This key type should
be used only for testing and inspecting profile contents without encryption.

By modifying the AcaPy code I was able to choose none as the store key type. Looking into the table config I can also see that key is none. Unfortunately, the data in items and items_tags still seems to be encrypted or at least are not shown in plain text.

Am I missing something? Does it only affect the encryption of the profile keys but not the encryption of the profile content?

I get the following errors when trying to install aries-askar.

PI - Linux raspberrypi 6.1.19-v8+ #1637 SMP PREEMPT aarch64 GNU/Linux
Indexes - https://pypi.org/simple, https://www.piwheels.org/simple
Python Version - 3.10.7
pip3 - 21.2.4

Normal Install - pip3 install aries-askar==0.2.7

ERROR: Could not find a version that satisfies the requirement aries-askar==0.2.7 (from versions: 0.1.0, 0.1.2)
ERROR: No matching distribution found for aries-askar==0.2.7

Wheel Install - pip3 install aries_askar-0.2.7-py3-none-manylinux2014_x86_64.wh

ERROR: aries_askar-0.2.7-py3-none-manylinux2014_x86_64.whl is not a supported wheel on this platform.

Askar Feature - pip3 install aries-cloudagent[askar]==0.7.5|

ERROR: Could not find a version that satisfies the requirement indy-credx~=0.3; extra == "askar" (from aries-cloudagent[askar]) (from versions: 0.2.1, 0.2.3)
ERROR: No matching distribution found for indy-credx~=0.3; extra == "askar"

P-384 is one of the core key types supported in DIDComm.

The RustCrypto p384 crate only supports the key representation currently, not signing or ECDH: RustCrypto/elliptic-curves#240

There is the ring-compat crate, but it only seems to support P-384 signatures, not ECDH.

Currently waiting to see if the weierstrass crate gets added with generic arithmetic support for these curves.

For reference: https://actually.fyi/posts/zig-makes-rust-cross-compilation-just-work/

With luck, Zig can be used to limit the glibc bindings to an older version, replacing the current 'manylinux' build process. It should also help with preparing packages for other architectures, like arm64 linux and the universal MacOS package.

While working with @reflectivedevelopment, we have determined a need to gather performance metrics from Askar. Being able to toggle metrics on/off would help instill confidence to the codebase as well as help us to find where the actual performance issues lie (such as a slow postgres server rather than putting the blame on Askar). I am currently investigating different metric libraries, though I am new to the Rust landscape.

P256KeyPair allows use SignatureType::ES256K for signature and disallows SignatureType::ES256 that looks wrong. See

Because we can not have tests right now for the React Native wrapper, we can add an example app with some buttons to execute the code and make sure it works.

It MUST be an Expo app to keep the repo a lot smaller and should work with the latest version of RN and Expo.

Current implementations of FromJwk look like this

impl FromJwk for Ed25519KeyPair {
    fn from_jwk_parts(jwk: JwkParts<'_>) -> Result<Self, Error> {
        ArrayKey::<U32>::temp(|pk_arr| {
            if jwk.x.decode_base64(pk_arr)? != pk_arr.len() {
                Err(err_msg!(InvalidKeyData))
            } else {
                if jwk.d.is_some() {
                    ArrayKey::<U32>::temp(|sk_arr| {
                        if jwk.d.decode_base64(sk_arr)? != sk_arr.len() {
                            Err(err_msg!(InvalidKeyData))
                        } else {
                            let kp = Ed25519KeyPair::from_secret_bytes(sk_arr)?;
                            kp.check_public_bytes(pk_arr)?;
                            Ok(kp)
                        }
                    })
                } else {
                    Ed25519KeyPair::from_public_bytes(pk_arr)
                }
            }
        })
    }
}

It allows successfully instantiate Ed25519KeyPair from jwk like this

{"crv":"P-256","kty":"EC","x":"_NTdY46oS3Fm4_mIlmWeF2OGSSlu55u2CIYV2wsthCg","y":"FpBqyiSsDt5ncoyZMaoOr-aLMrcMamtifSaK-EAk_sk"}

Example: https://github.com/hyperledger-labs/solang/blob/main/MAINTAINERS.md Example of a pointer: https://github.com/hyperledger-labs/homebrew-solang/blob/main/MAINTAINERS.md

There is basic support for this in #4 but Big Sur runners for GitHub actions are currently restricted. This can be revisited in order to add Python wheels compatible with M1 Macs once the pool becomes generally available: actions/runner-images#2486

When querying for wallet items we found out that some queries that are generated by WQL are not optimized. Are there any initiatives planned to tackle that issue? Having a large number of profiles with multiple items and tags, this could become an issue for the performance.

Wheels are published for macos universal and linux x86-64, but not for linux arm64. Could the build be updated to publish releases for this architecture?

This should include the abstract database schema (details vary between backends) and the encryption and decryption processes.

When the default profile is created, the profile key is encrypted using the store key, but when creating a new profile in the same store, the profile key is stored in the database in a plaintext format

As a consequence, loading of all profiles fails (except for the default one), since in the resolve_profile_key function, plaintext key is being decrypted

A connected issue is in the SQL query SELECT id, profile_key FROM profiles WHERE name=?1 ?1 should be replaced with $1, otherwise the value is not bound correctly

This issue is connected to ACA-py improved multitenancy implementation and represents a security vulnerability.

After a number of database errors, connections no longer can be formed to the database, and Askar no longer functions. The error message we are seeing is

Caused by: pool timed out while waiting for an open connection

When a database error occurs, it appears that the connection is not returned to the pool properly. This can be verified by examining the open connections to the database are in an idle state, but appears no new connections an be made.

Since the database errors may be timing related, it was difficult to reproduce the issue. I found that by injecting random errors into Askar where we may see database errors triggered the same problem. By injecting the error here, we are simulating an error that the database may encounter. We would expect after handling the error, that the connection would be returned to the connection pool, but it is not.

diff --git a/src/backend/postgres/mod.rs b/src/backend/postgres/mod.rs
index 8a8019f..82e279a 100644
--- a/src/backend/postgres/mod.rs
+++ b/src/backend/postgres/mod.rs
@@ -1,3 +1,6 @@
+use rand::Rng;
+
+
 use std::collections::BTreeMap;
 use std::fmt::{self, Debug, Formatter};
 use std::sync::Arc;
@@ -585,6 +588,12 @@ async fn perform_insert<'q>(
     expiry_ms: Option<i64>,
     new_row: bool,
 ) -> Result<(), Error> {
+
+    let num = rand::thread_rng().gen_range(0..10);
+    if num == 0 {
+        return Err(err_msg!(Unsupported, "asdf!"));
+    }
+
     let row_id = if new_row {
         trace!("Insert entry");
         sqlx::query_scalar(INSERT_QUERY)

After modifying Askar with the above random error, I ran the following queries against aca-py. After about 4000 iterations Askar would no longer function, as Askar could no longer connect to the database.

#!/bin/sh

i=0
while [ $i -ne 5000 ]
do
        i=$(($i+1))

curl -X 'POST' \
  'http://localhost:3001/multitenancy/wallet' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -d "{
  \"key_management_mode\": \"managed\",
  \"label\": \"Alice\",
  \"wallet_dispatch_type\": \"default\",
  \"wallet_key\": \"MySecretKey123\",
  \"wallet_name\": \"MyNewWallet$i\",
  \"wallet_type\": \"askar\"

}"

done

The error is:

error: package `hashbrown v0.14.0` cannot be built because it requires rustc 1.64.0 or newer, while the currently active rustc version is 1.61.0
Error: Process completed with exit code 1.

The nightly builds failed on the Python wrapper.

Askar does not currently have a setup equivalent to the MultiWalletSingleTable wallet management mode in Indy-SDK, in which all wallets are stored in a single table in a single database and each wallet has its own master key.

Each profile must have its own store key in order for Askar to have a MultiWalletSingleTable-like setup. The problem is that Askar does not support storing multiple salts. Per @dbluhm’s observation, the salt associated with the store key is saved in the config table as the value of key, which prevents the use of different passphrases for different profiles keys without sharing salt.

A potential solution proposed by @dbluhm is to change the structure of the profiles table to include another column in which to store the salt for the passphrase to unlock its associated profile.

cc @burdettadam

There are certain use cases where Askar JS is throwing a custom error (code 100) when I think it would be more appropriate to throw a specific error. These are the cases I've found during an initial integration with aries-framework-javascript:

• Session.fetch and no entry has been found (should be NotFound or simply return undefined, as current API suggests)
• Session.fetchKey and no entry has been found (should be NotFound as current API suggests)
• Scan.fetchAll/Session.fetchAllKeys and no entries matching the query have been found (should be NotFound or simply return an empty array)

Dod: Add AskarModule from AFJ to example react native app and make sure we can do a full credential exchange and create a wallet and a connection where Askar provides the crypto, wallet & storage implementation

• App shouldn't crash.
• To test: Need to be able to create a connection using siera-cli or Animo Demo

Already a lot of fixes applied in #111

          It looks like EntryLists are freed in the Scan implementation which is good as well. It seems fairly easy for a user to accidentally leak sessions and run out of active connections though, it might be better to use a callback interface for working with open sessions and transactions, and close automatically after it runs.

Originally posted by @andrewwhitehead in #107 (comment)

Feature Request: Add support for SSL/TLS

Why: So that applications can secure the communication between askar and the storage backend by encrypting the communication with tls certificates

It is entirely possible that I have missed the security model of askar and askar already encrypts this communication in a way that make TLS encryption redundant. If this is the case please advise and I will propose a pull request to include the information in the aries cloudagent python documentation.

Also from a security audit perspective it will also help future auditors to access the strength of askar's security.

Hey! I'm trying to realise how the scan works. I thought that the scan is functionality which allows to retrieve data by page from the backend with special offset and limits.

How I understand of the scan behaviour:
We have some data in the backend. For instance, we have 5 records. I want to extract all data by 2 records 3 times.

// Algorithm

1. Create a new scan with the offset 0 and the limit 2
2. Call scan's next method and get first bunch of data with size 2
3. Call scan's next method and get second bunch of data with size 2
4. Call scan's next method and get third bunch of data with size 1
5. Close scan

Right know, the scan returns only the first bunch of data on calling the next. When you try to call the next again, you will get an invalid handler pointer. Is it okay behaviour or not? I'm asking because I couldn't find answer for my question in tests and documentation too.

Thx.

Versions above 0.5.5 currently fail unit tests due to the Connection::close() method returning prior to the database connection being closed. Related issue: launchbadge/sqlx#1452

No Project Lifecycle Badge found in your readme!

Hello! I scanned your readme and could not find a project lifecycle badge. A project lifecycle badge will provide contributors to your project as well as other stakeholders (platform services, executive) insight into the lifecycle of your repository.

What is a Project Lifecycle Badge?

It is a simple image that neatly describes your project's stage in its lifecycle. More information can be found in the project lifecycle badges documentation.

What do I need to do?

I suggest you make a PR into your README.md and add a project lifecycle badge near the top where it is easy for your users to pick it up :). Once it is merged feel free to close this issue. I will not open up a new one :)

Using Aries Askar with Aries cloud agent, we would like to support the export of the wallet for possible backup/restore flows.

Is there any work planned to support:

• export of the whole database
• export of a single profile

Under load we've been encountering the following error

aries_askar.error.AskarError: Resource handle in use
Traceback (most recent call last):
  File "/cloudagent/aries_cloudagent/protocols/issue_credential/v2_0/routes.py", line 457, in credential_exchange_list
    cred_ex_records = await V20CredExRecord.query(
  File "/cloudagent/aries_cloudagent/messaging/models/base_record.py", line 313, in query
    rows = await storage.find_all_records(
  File "/cloudagent/aries_cloudagent/storage/askar.py", line 189, in find_all_records
    for row in await self._session.handle.fetch_all(
  File "/usr/local/lib/python3.10/site-packages/aries_askar/store.py", line 436, in fetch_all
    await bindings.session_fetch_all(
  File "/usr/local/lib/python3.10/site-packages/aries_askar/bindings/__init__.py", line 237, in session_fetch_all
    return await invoke_async(
  File "/usr/local/lib/python3.10/site-packages/aries_askar/bindings/lib.py", line 354, in invoke_async
    return await self.loaded.invoke_async(
  File "/usr/local/lib/python3.10/asyncio/futures.py", line 284, in __await__
    yield self  # This tells Task to wait for completion.
  File "/usr/local/lib/python3.10/asyncio/tasks.py", line 304, in __wakeup
    future.result()
  File "/usr/local/lib/python3.10/asyncio/futures.py", line 196, in result
    raise exc
asyncio.exceptions.CancelledError

I believe it is related to the following code in ffi/store.rs

    pub async fn borrow(&self, handle: K) -> Result<TryMutexGuard<V>, Error> {
        self.map
            .read()
            .await
            .get(&handle)
            .ok_or_else(|| err_msg!("Invalid resource handle"))?
            .1
            .try_lock_arc()
            .ok_or_else(|| err_msg!(Busy, "Resource handle in use"))
    }

Is there a reason to use try_lock_arc instead of lock_arc? It would seem to make more sense to wait to acquire the lock instead of failing the request? Or was this design decision because of a deadlocking scenario?

My understanding of store provision method is that it works as a constructor, meaning that if the store does already exist the method should throw a "Duplicate" error (unless recreate flag is set).

However, my initial testing through JS wrapper shows that, if called with recreate flag unset, it will:

• Throw an Encryption error in case the store already exists and the provided passkey is not correct
• Open the store in case the passkey provided is the same as the existing store

Is this behaviour correct?

While testing Askar in mobile environments for integration with AFJ, I had a problem in Android that resulted to be related to max_connections default value: Askar chooses this value depending on the number of CPUs, and as I was using an emulator with only 1 CPU available, there it was allowing at most a single connection to be opened.

In AFJ, we open a session when we open the wallet and close it when agent shuts down. We use this session for all fetches and updates, including those about keys. This works fine for us until we do a query using Scan, because it is opening a new connection and of course will not be allowed under these circumstances, resulting in a pool timeout. That makes me think that probably we are not using Askar as it should: I mean, is it OK to do what we do (open a session and use it for all transactions except of scans), or should we always open and close connections on-demand (that's it, per single fetch/update)?

Another doubt I have is about configuration of WAL mode in SQLite, which is enabled by default. I think there is not any limitation on mobile environments on using this mode, but something I noticed during this early testing is that some transactions are lost when app is not closed gracefully (so the connection is not explicitly closed). This happened in cases where app crashed, but I'm a bit worried about what will happen when app goes to background and OS kills it (it's not always easy to get a callback to an app destructor when using environments like React Native). So the question is... would it be safer to simply disable WAL mode if we use Askar on mobile apps?

Maybe this is a neon.tech issue, but the open method in the postgresql provision.rs, checks whether the error code is 3D000 (invalid catalog name) and then assumes the database does not exist. However neon.tech will throw an error XX000 (internal error), with the message database "my-wallet4" does not exist. This means the normal flow will fail.

Is there something we can do to still treat this as "NotFound"?

Hello,

ECDH-EC, ECDH-1PU specifications require EPK to be presented as embedded object. For example, ECDH-1PU protected header will be

{
      "alg":"ECDH-1PU",
      "enc":"A256GCM",
      "apu":"QWxpY2U",
      "apv":"Qm9i",
      "epk":  {
        "kty":"EC",
        "crv":"P-256",
        "x":"gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0",
        "y":"SLW_xSffzlPWrHEVI30DHM_4egVwt3NQqeUD7nMFpps"
       }
   }

With current approach for JWKParts serialisation it will be quite hard to serialize/de-serialize such structure without intermediate conversion to Value. I understand nostd targeting, but it significantly affects std option.

See hyperledger/indy-vdr#113 for steps and context

Define and implement a way to export data from an Indy-SDK and import the data into Askar. This should be a general feature, that supports all wallets, but Postgres support is crucial. Less critical are conversions between storage backends -- e.g. from SQLite to Postgres and vice-versa. But of course, such support would be nice.

cbindgen does not generate some types such as StoreHandle, SessionHandle, ScanHandle, which are types created using a macro.
It also omits askar_string_free() function.

While working with the toolbox plugin for ACA-Py (specifically moving it to using Askar by default instead of Indy), we've started encountering errors like these in our integration tests when using a sqlite Askar store:

agent_1  | Traceback (most recent call last):
agent_1  |   File "/usr/src/app/.venv/lib/python3.7/site-packages/aries_cloudagent/storage/askar.py", line 90, in get_record
agent_1  |     record_type, record_id, for_update=for_update
agent_1  |   File "/usr/src/app/.venv/lib/python3.7/site-packages/aries_askar/store.py", line 421, in fetch
agent_1  |     self._handle, category, name, for_update
agent_1  |   File "/usr/src/app/.venv/lib/python3.7/site-packages/aries_askar/bindings/__init__.py", line 225, in session_fetch
agent_1  |     return_type=EntryListHandle,
agent_1  |   File "/usr/src/app/.venv/lib/python3.7/site-packages/aries_askar/bindings/lib.py", line 355, in invoke_async
agent_1  |     name, argtypes, *args, return_type=return_type
agent_1  |   File "/usr/local/lib/python3.7/asyncio/futures.py", line 263, in __await__
agent_1  |     yield self  # This tells Task to wait for completion.
agent_1  |   File "/usr/local/lib/python3.7/asyncio/tasks.py", line 318, in __wakeup
agent_1  |     future.result()
agent_1  |   File "/usr/local/lib/python3.7/asyncio/futures.py", line 181, in result
agent_1  |     raise self._exception
agent_1  | aries_askar.error.AskarError: Backend error
agent_1  | Caused by: pool timed out while waiting for an open connection
agent_1  |
agent_1  | The above exception was the direct cause of the following exception:
agent_1  |
agent_1  | Traceback (most recent call last):
agent_1  |   File "/usr/src/app/.venv/lib/python3.7/site-packages/aries_cloudagent/protocols/connections/v1_0/routes.py", line 537, in connections_create_invitation
agent_1  |     mediation_id=mediation_id,
agent_1  |   File "/usr/src/app/.venv/lib/python3.7/site-packages/aries_cloudagent/protocols/connections/v1_0/manager.py", line 132, in create_invitation
agent_1  |     or_default=True,
agent_1  |   File "/usr/src/app/.venv/lib/python3.7/site-packages/aries_cloudagent/connections/util.py", line 28, in mediation_record_if_id
agent_1  |     mediation_record = await MediationManager(profile).get_default_mediator()
agent_1  |   File "/usr/src/app/.venv/lib/python3.7/site-packages/aries_cloudagent/protocols/coordinate_mediation/v1_0/manager.py", line 356, in get_default_mediator
agent_1  |     mediation_id = await self._get_default_mediator_id(session)
agent_1  |   File "/usr/src/app/.venv/lib/python3.7/site-packages/aries_cloudagent/protocols/coordinate_mediation/v1_0/manager.py", line 342, in _get_default_mediator_id
agent_1  |     default_record = await self._get_default_record(session)
agent_1  |   File "/usr/src/app/.venv/lib/python3.7/site-packages/aries_cloudagent/protocols/coordinate_mediation/v1_0/manager.py", line 326, in _get_default_record
agent_1  |     record_id=self.DEFAULT_MEDIATOR_RECORD_TYPE,
agent_1  |   File "/usr/src/app/.venv/lib/python3.7/site-packages/aries_cloudagent/storage/askar.py", line 93, in get_record
agent_1  |     raise StorageError("Error when fetching storage record") from err
agent_1  | aries_cloudagent.storage.error.StorageError: Error when fetching storage record

This is using Askar 0.2.7 and ACA-Py 0.7.4. Integration test run can be found here with logs printed from ACA-Py visible in the Print logs on failure task.

I'm mostly just lost on where to start digging into this issue. When I run our integration tests, it seems to work locally initially. In github actions, it seems to immediately fail. Also willing to accept that this likely isn't an issue with Askar or even ACA-Py. Any direction or advice would be appreciated.

After updating an app to use [email protected], I'm getting a build time error in Android regarding duplicate functions:

node_modules/@hyperledger/aries-askar-react-native/cpp/turboModuleUtility.cpp.o' -c ' /[project_dir]node_modules/@hyperledger/aries-askar-react-native/cpp/turboModuleUtility.cpp'
   /[project_dir]/node_modules/@hyperledger/aries-askar-react-native/cpp/turboModuleUtility.cpp:171:12: error: redefinition of 'createReturnValue'
  jsi::Value createReturnValue(jsi::Runtime &rt, ErrorCode code,
             ^
  /[project_dir]/node_modules/@hyperledger/aries-askar-react-native/cpp/turboModuleUtility.cpp:124:12: note: previous definition is here
  jsi::Value createReturnValue(jsi::Runtime &rt, ErrorCode code, int64_t *value) {
             ^
  1 error generated.

When building in an x86_64 PC, after removing one of these functions it also gave a similar error but with the template for int32_t.

Once that is removed, the app runs. However it could lead to issues when building for iOS (for that platform I have another problem, but that's another story 😆 ).

Continuation of #64, but focuses on the React Native implementation

The iOS & Android build is currently broken and needs some extra work.

TODO

• add iOS & Android build (CI pipeline)
• Fix react native setup

This doesn't include the NPM release setup, it just means making the react native package ready for release, and making sure the ios and android binaries can be built

Currently it just gives you the code. I think we could add this enum (or make it an object mapping)

export enum AskarError {
  Success = 0,

  /// An unexpected error from the store backend
  Backend = 1,

  /// The store backend was too busy to handle the request
  Busy = 2,

  /// An insert operation failed due to a unique key conflict
  Duplicate = 3,

  /// An encryption or decryption operation failed
  Encryption = 4,

  /// The input parameters to the method were incorrect
  Input = 5,

  /// The requested record was not found
  NotFound = 6,

  /// An unexpected error occurred
  Unexpected = 7,

  /// An unsupported operation was requested
  Unsupported = 8,

  /// A custom error type for external integrations
  Custom = 100,
}

As i can see the only rng provided by askar-crypto is OsRng that is unacceptable slow (and potentially blocking) for a lot of use cases.

In my experience OsRng is often used only to seed pseudo-random rng (like ChaCha) with state cache in thread local storage. Sure it can't be a good solution for no std, but what if we expose thread_rng or something similar as a dedicated feature?

There is an error on validation of iOS app bundle archived for Testflight upload:

This bundle is invalid. The bundle at path Payload/AppName.app/Frameworks/aries_askar.framework has an invalid
CFBundleldentifier 'org.hyperledger.aries_askar' There are invalid characters (characters that are not dots, hyphen and alphanumerics)
that have been replaced with their code point 'org.hyperledger.aries\u005faskar' CFBundleldentifier must be present, must contain
only alphanumerics, dots, hyphens and must not end with a dot.

The reason is _ character in org.hyperledger.aries_askar identifier.

It's possible to work around this by updating local Info.plist file at node_modules/@hyperledger/aries-askar-react-native/native/mobile/ios/aries_askar.xcframework/ios-arm64/aries_askar.framework:

<key>CFBundleIdentifier</key>
<string>org.hyperledger.ariesaskar</string>
// "_" character was removed

Just to clarify, local build and runtime functionality are not affected by this - it's related to Apple validation rules for app distribution.

Such problem is also relevant for indy-vdr RN package.

The Askar export and import capabilities have not yet been created. Add the functionally equivalent support to what is in the Indy SDK.

AFAIK there is already a way to export from the Indy SDK and import into Askar, so there is not a need for the export format to be the same as the Indy SDK format. It must be possible for data to be exported from Askar and then imported back into Askar.

Hi.
We applied aca-py and askar on our service.
I found performance issues when the issuer issues credential.

Environment

• aca-py 0.7.5 (multitenant, wallet_type: askar-profile, wallet_storage_type: postgres_storage)
• askar 0.2.8
• postgres 13.3

Problem

• When issuer searches revocation registries with cred_def_id and state to issue credential, it takes 15 seconds.
• the number of revocation registry that matches cred_def_id was 7000.
• the number of revocation registry that matches cred_def_id and state was 3.

Problem replay

• I launched a docker postgres 13.3 and aca-py 0.7.5 (askar 0.2.8).
• I excuted a script that issues credentials for making many revocation registries.
• I called /revocation/registries/created with cred_def_id and state (active).
• 1 out of 10 times I experienced slow latency.
• I've tested several versions of postgres, but it doesn't seem to be a problem specific to postgres 13.3.

Slow query log

2023-04-12 01:50:00.221 UTC [37] LOG:  execute sqlx_s_4: SELECT id, name, value,
	    (SELECT ARRAY_TO_STRING(ARRAY_AGG(it.plaintext || ':'
	        || ENCODE(it.name, 'hex') || ':' || ENCODE(it.value, 'hex')), ',')
	        FROM items_tags it WHERE it.item_id = i.id) tags
	    FROM items i WHERE profile_id = $1 AND kind = $2 AND category = $3
	    AND (expiry IS NULL OR expiry > CURRENT_TIMESTAMP) AND (i.id IN (SELECT item_id FROM items_tags WHERE name = $4 AND value = $5 AND SUBSTR(value, 1, 12) = $6 AND plaintext = 0) AND i.id IN (SELECT item_id FROM items_tags WHERE name = $7 AND value = $8 AND SUBSTR(value, 1, 12) = $9 AND plaintext = 0))
2023-04-12 01:50:00.221 UTC [37] DETAIL:  parameters: $1 = '16', $2 = '2', $3 = '\x9a2c206353248a4f0f6a958bc658d021a6d607ac3d6125fb146dc1c2294ebbf3b3a38b79fbc120bc7bd8', $4 = '\xb4d378247975703df0ea38b8cc88d1b7a6f8bf1e0b1ce74767fbacbb1a6e7f321e52674c88b5fd', $5 = '\xf1f55020413f9aafc54ffd1ae62c149ab44bf3d9a8db301fe6f2ff0ae40978ba4aeb0cbaa5d7c06fc33ae292f4b381d8c5de875cd87e1735b355ce449eea81e68741ef2326a09f13353a71edeb9ca0a409bbbbc85aedfdc3fa51c45175eb17b81a813f449a414c', $6 = '\xf1f55020413f9aafc54ffd1a', $7 = '\xd97e6af09b332939e31df0cecd3c60b27cdb031fbd6e49e6fc0292d9f3fd74732f', $8 = '\x0fb954f2366b4fe199fbe5e049a8ca8e11d0535cef41b42310dc50653967e5c043a2', $9 = '\x0fb954f2366b4fe199fbe5e0'
2023-04-12 01:50:06.968 UTC [37] LOG:  duration: 6746.526 ms

When working on the integration of Askar with Aries Framework JavaScript, I noticed that Askar behaves slightly different from Indy when managing WQL queries.

In the test I'm writing, we are inserting 3 records with the following tags:

• { myTag: 'foo' }
• { anotherTag: 'bar' }
• { myTag: 'notfoobar' }

The query is for $not: { myTag: 'notfoobar' }, which expects to return the first two records. However, it only returns the first one. Experimenting a little bit more, I found that it only considers those records that do have a myTag: those who do not include any myTag are ignored in the query. In other words, my test interprets the query as "Give me all the records that are not tagged as myTag = 'notfoobar'", while Askar interprets it as "Give me all the records tagged with myTag that are not equal to 'foobar'".

Not sure if it's something related at Rust or JS-wrapper level, but before investigating further I would like to know if this behaviour is incorrect or my test (based on Indy behaviour) should be rewritten.

I got error related to iOS versions support when trying to validate app bundle for Testflight upload with minimum iOS version set to 12.0:

Invalid Bundle. The bundle AppName.app/Frameworks/aries_askar.framework does not support the minimum OS Version specified
in the Info.plist.

After some investigation I found that minos value in binary is set to 16.2:

aries_askar.framework % vtool -show aries_askar 
aries_askar:
Load command 10
      cmd LC_BUILD_VERSION
  cmdsize 32
 platform IOS
    minos 16.2 <---------------
      sdk 16.2
   ntools 1
     tool LD
  version 820.1
Load command 11
      cmd LC_SOURCE_VERSION
  cmdsize 16
  version 0.0

iOS version specified in aries-askar.podspec:

s.platforms    = { :ios => "12.0" }

After I switched app minimum iOS version to 16.2, app bundle validation completes successfully.

This problem is also relevant for indy-vdr and anoncreds RN packages.