Hexadecimal representation of SigningType.RAW is incorrect.

[Gau-thier]

Describe the bug (current behavior)

The hexadecimal representation of a RAW payload is missing the first character.
For example, if I submit:

const response = await dAppClient.requestSignPayload({
  signingType: SigningType.RAW,
  payload: "any string that will be signed",
});

The hexadecimal displayed in the Temple popup is:
16e7920737472696e6720746861742077696c6c206265207369676e6564
If I decode this hexadecimal to a string, I obtain:
�ç��7G&�ær�F��B�v�ÆÂ�&R�6�væV� which is not at all the one I provided.

The correct hexadecimal representation of any string that will be signed is:
616e7920737472696e6720746861742077696c6c206265207369676e6564
yours is:
16e7920737472696e6720746861742077696c6c206265207369676e6564
We can see the first 6 is missing in your hexadecimal representation.

To Reproduce

You can reproduce this behavior within beacon SDK documentation about signing

Expected (correct) behavior

Do not truncate the first character on the hexadecimal representation of the given payload.

We need this fix, in order to be able to sign layer 2 operations, such as Deku

[unixvb]

Hi, thanks for the report.
Will fix this in next release

[letier3110]

code/env to reproduce

https://docs.walletbeacon.io/guides/request-permissions/

import { DAppClient, PermissionScope, SigningType } from "@airgap/beacon-sdk";

const dAppClient = new DAppClient({ name: "Beacon Docs" });

// You can request specific permissions if you want
const scopes: PermissionScope[] = [
  PermissionScope.OPERATION_REQUEST,
  PermissionScope.SIGN,
];

try {
  console.log("Requesting permissions...");
  const permissions = await dAppClient.requestPermissions({ scopes });
  console.log("Got permissions:", permissions.address);
} catch (error) {
  console.log("Got error:", error);
}


const response = await dAppClient.requestSignPayload({
  signingType: SigningType.RAW,
  payload: "any string that will be signed",
});

console.log(`Signature: ${response.signature}`);

possible fix in #742

but it violates validation of custom RAW messages from beacon and does breaking changes to Ledger's sign messages

[letier3110]

@gsebil08 , we can't fix this issue due to braking compatibility support of ledger transactions and multisig functionality, that is using RAW payloads. But you can contact Beacon to implement SigningType.DEKU messages or contact Ledger to fix issue with RAW payloads on their side.

As a temporary solution for continue developing L2 Deku sidechains, you can use Templewallet Mobile - there are no support for ledger and multisig messages and thus there are no bug with RAW payloads

[Gau-thier]

Hi @letier3110
Thanks for the answer and the explanation.

I tried to sign a raw payload using Temple Mobile and faced the following error:

[letier3110]

@gsebil08 can you provide payload or code sample on beacon sandbox? Because I've tested the one in first message and it works well (pic)

[Gau-thier]

Here is how I do the call to requestSignPayload:

const seed = await latestState.current.wallet.client.requestSignPayload({
    signingType: SigningType.RAW, payload: nickName
}).then(val => val.signature);

I did some more tests on my side, signing any string that will be signed works well. But I don't understand why it fails on some other input like:

• gauthier ❌
• gauthier will be signed ✅
• gauthiergauthier ❌
• nickname ❌
• gsebil08 ✅
• letier3110 ✅
• github ❌
• any string that will be signed ✅
• PPPPPPPP ❌ (8x P)
• aaaaaaaa ✅ (8x a)
• FFFFFFFF ✅ (8x F)
• GGGGGGGG ❌ (8x G)
• any string of 1 char ❌ (I tried a, b, c, 1, 9)

I don't understand the pattern which makes it fail, but I guess you have enough examples to try on your side 😄

[letier3110]

mobile app just passing payload to taquito.InMemorySigner.sign() (from @taquit/signer) for RAW, and looks like it wont work with payloads that different from hex/b58

[Gau-thier]

mobile app just passing payload to taquito.InMemorySigner.sign() (from @taquit/signer) for RAW, and looks like it wont work with payloads that different from hex/b58

Seems to be ok with hexadecimal representation of any string.
Since we can sign payload.RAW using Temple mobile, as close this issue.

Thanks for your time.