Accepting but for now we have to hold this diff.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
May 22 2024
May 21 2024
Fix build failure
Rebase
entry_info -> entry
entry_info -> entry
It would be convenient if you could create a function that converts EntryInfo (of RawEntryInfo) into ClientDBEntryInfo - it will help me write tests for first C++ diff.
May 20 2024
Extract constants and fix typos
- Fix typo
- Remove unused function.
Add suggested memoization.
May 17 2024
- Update to reflect changes deeper in the stack
- Address comments about copy
- Address comment about Optional
- Add additional siwe message parsing to avoid having to do it in JS (where we have no tools for that)
- Address comments about memoization.
- Modify SIWE panel to possibly take nonce, statement and issuedAt from external source and skip nonce generation in such a case. This is necessary for SIWE restore
Modify landing handler to take optional issuedAt property for SIWE. This will be needed for SIWE restore
Rebase master
May 16 2024
In D12033#344659, @ashoat wrote:So is the new plan for keyserver to parse the message that is passed in, extract nonce and issuedAt, and then insert that into the JS?
In D12033#344653, @ashoat wrote:Why can't we just generate the message in landing/siwe.react.js, like we do in the existing code?
I have refactored the entire stack locally to use decomposition of siwe message on native to learn that it is not possible on native. This is because siwe library uses Buffer object when parsing string into structured message object. There are two solutions now:
- Pass message on native to WebView and perform decomposition in landing-handler.
- Use siwe create from Rust to parse the message and expose it vie C++ to JS. - it should be entire day of work.
- Address Ashoat's sugestions.
- Rebase before landing
May 15 2024
This design seems very unsafe to me. Can we find a way forward that doesn't allow the client to pass in any message to be signed?
Two alternatives that I can think of are:
- Decompose siweMessageToSign in siwe-panel before passing to headers and then re-construct it in siwe.react.js
- Make direct HTTP request to backup service from siwe.react.js. - don't know if it will work.
Both are significant changes to entire stack so I would like to understand what exact dangers are we risking by passing full message to sign.
May 14 2024
changes from parent diff
May 13 2024
May 9 2024
Rebase before landing