PegaSysEng/EthSigner

juharahmed

@juharahmed

@rain-on Thank you . Yes i think you are right. I was also thinking the same. But i asked this question to Hyperledger Besu guys first. They said yes and they referred me to here for more details. May be they thought i was asking multisignature address transaction. Anyways, do you know any other Blockchain platform that supports what i looking for?

Trent Mohay

@rain-on

@juharahmed I suspect the Besu response meant - "Ethsigner can manage multiple keys (but only use one per transaction, based on the "from" field) - unfortunately I don't know of a multi-sig blockchain platform - but suspect you could implement something like this in a smart-contract (unfortunately, that is where my expertise comes to an end).

Zain

@sprect8

Hi everyone, I added an article for integration Ethsigner, Infura and Hashicorp Vault for those interested and having troubles with it. https://medium.com/@corgi.desu/a-study-on-blockchain-key-management-systems-part-2-hashicorp-vault-ec11013cd765

Trent Mohay

@rain-on

Hey @sprect8, 2 things:

Loving your work :)
Sorry for not getting onto your PR - its on the radar, but we're a bit swamped :(

Zain

@sprect8

@rain-on just glad I can contribute to the great work you're doing and to help the community a bit; sometimes starting out can be daunting

no worries on the PR, take your time. better to do things right than to rush it

Diego López León

@diega

Hello there, is there any plan to support EIP-712 eth_signTypedData? Do you think there is room for collaboration there? (or maybe the plain to begin eth_sign)

Arash

@arash009

Hi @diega . Yes we are currently in the process of defining some additional functionality around ethsigner and signing in general. Whats the specific context you re looking to support? Just the eth_sign and eth_signTypedData?

Diego López León

@diega

@arash009 it's just eth_signTypedData indeed. We're defining a process for EIP-1812 (Verifiable Claims) that heavily relies on an EIP-172 implementation, for a private network (LACChain). Last night a gave it a try at diega/ethsigner@7986cbe. I didn't want to make any refactor like renaming the TransactionSignerProvider to something more general, but most of the functionality I think it's there. It's just for eth_sign but it's a beginning. It needs a lot of testing though

Diego López León

@diega

@arash009 do you think my changes are well oriented? does it worth I continue that work so I can make a pull request?

Arash

@arash009

Let us have a look and we'll let you know shortly.

Trent Mohay

@rain-on

@diega Just had a flick through your branch, and am impressed at how little you had to touch to make it work. I think you're right, there's some testing required to back it up, but otherwise the change looks simple enough to be put up as a PR (if you're happy to have this in the core code base).
Only comment from my initial read is that we use "final" everywhere, variables, function parameters - so I'd recommend adding where possible (otherwise I suspect it'll be the one of the first comments!). Lovely work :thumbsup:

Diego López León

@diega

Excellent! I'll add testing and such and send a PR then. Thanks for your feedback!

Trent Mohay

@rain-on

@diega @sprect8 We'll wait for your PRs to come in, but it's worth saying/warning that Ethsigner is probably going to be split into two more explicit halves:

Http Handling and Ethereum-oriented functions
Keyloading and management
The goal of this, is to allow the signing engine to be reused more effectively in other applications (and TransactionSigner will probably be changed to Signer, or something similarly generic)
These changes won't be ready until after your PRs have gone through, so should not affect what you're currently doing.

Diego López León

@diega

@rain-on no worries, thanks for the advice. I just sent PegaSysEng/ethsigner#263 but there is a failure running the acceptance tests that seems unrelated to what I made

GPG error: https://cli-assets.heroku.com/apt ./ InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 5DC22404A6F9F1CA

let me know if I miss something for this or you'll like some changes to the code

Diego López León

@diega

I tried rebuilding the pipeline many times with push force but it fails everytime the acceptance tests at the "Install Packages - Java 11" step. Aren't you experiencing the same in some other CI environment?

here is the output of the failure if you want to take a look https://app.circleci.com/pipelines/github/PegaSysEng/ethsigner/598/workflows/0b2c82c0-dda6-45a7-a64b-c70c4d779324/jobs/1972/parallel-runs/0/steps/0-104

Lucas Saldanha

@lucassaldanha

Hi @diega This doesn’t seem to be related to your changes. I’ll follow up with the team and get back to you!

Diego López León

@diega

Thanks @lucassaldanha! maybe a quick check can be running the pipeline for master directly in CircleCI, it should fail the same way. I'll rebase the PR if anything new goes into master

Lucas Saldanha

@lucassaldanha

We have experienced this similar issue in other projects. So I believe we need the same fix here :)

Diego López León

@diega

oh, cool, I'll keep tuned :)

Lucas Saldanha

@lucassaldanha

I have put up a fix on PegaSysEng/ethsigner#265

Once we merge it, all you need to do is rebase your PR and it should be good to go :+1:

(assuming my fix works…) :)

Diego López León

@diega

Excellent, I just rebased and everything passes :) I also fixed some missing finals from a review

Diego López León

@diega

Thank you for merging my PR! I'll move forward to implement eth_signTypedData

Oussama Chaabouni

@oussamachaabouni

hello . i am trying to start ethsigner after creating the password file and the key file ... but he sait that file password is not found althought i am sure that the path is true , it s in the same path of the key file

that s my error

Oussama Chaabouni

@oussamachaabouni

now he gace me this error

Oussama Chaabouni

@oussamachaabouni

can someone please explain to me how to use ethsigner ... i juste want to interact with my contract via a script node js .. trying to execute a function of my contract vi eth.send ... but he said to me that i must use sendRawTransaction .... i am using Besu on localhost:8545

Trent Mohay

@rain-on

Hi @oussamachaabouni, from the initial log, it looks like the /config/password file is indeed missing - can I ask you to rerun ethsigner, but with "-l trace" in the command line? That will provide much more information regarding the issue.
With regard your second issue - I'm suspecting that the port you've requested (defaults to 8545) is already in use, and the HTTP server is unavailable. Have you set the --http-listen-port on the EthSigner commandline?

Oussama Chaabouni

@oussamachaabouni

thank you , your answer help me to understand my problem . actualy i am just trying to interact with my contract , i want to call a set function to add some infomation in my contract ; i am using web3.js library

Trent Mohay

@rain-on

If you ensure that the ethsigner port is free - does it now work? If need be - you can set "--http-listen-port=0", then a file called ethsigner.ports will be created, and will show which free ports were selected by EthSigner for listening on.

Manuel Montenegro

@manumonti

Hi! I have a problem that I'm unable to resolve... I'm trying to connect Remix (Web3 provider) to EthSigner, because I'm working with a permissioned Besu network. In order to get that, I'm running EthSigner on a Docker container. I know that EthSigner - Besu node connection is working properly, because if I run this command, I can get this result:

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":51}' http://192.168.43.125:9101

{
"jsonrpc" : "2.0",
"id" : 51,
"result" : "0xfe89"
}

But if I try to connect with Remix (Web3 provider), I get this error from Remix pop-up: Cannot get account list: Error: Invalid JSON RPC response: ""

And if I open the firefox console, i get this: Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://192.168.43.125:9101/. (Reason: CORS header 'Access-Control-Allow-Origin' missing)

I'm using http version of Remix, so I don't know what is the problem. What can I do? Maybe EthSigner isn't compatible with Remix Web3 Provider? Any ideas?

Manuel Montenegro

@manumonti

Update: I installed firefox add-on: "Allow CORS: Access-Control-Allow-Origin" and it's working now. But I think EthSigner should have any option for setting up this

3 replies

Lucas Saldanha

@lucassaldanha

This message was deleted

2 replies

Trent Mohay

@rain-on

@/all Ethsigner 0.7.0 has just been released:
Binaries = https://bintray.com/consensys/pegasys-repo/ethsigner/0.7.0#files
Source = https://github.com/PegaSysEng/ethsigner/releases/tag/0.7.0
Changes =
Features Added

Added "eth_sign" JSON RPC
Added "--http-cors-origins" commandline option to allow browser based apps (remix/metamask) to connect to EthSigner
Added "--downstream-http-path" commandline option to allow Ethsigner to connect to a downstream web3 provider not on root path (eg web3 provider running in infura)
If inbound request contains the "Host" header, it is renamed to "X-Forwarded-Host" and added to downstream request
Code base split, crypto operations moved to "Signers" repository
First line of Password file (stripping EOL) is treated as the password (rather than whole file content)
Bugs Fixed
Create invalid signature when Signature field was treated as negative BigInteger #247
Thanks to @sprect8 and @diega for the submissions :) This release is mostly your work.

Diego López León

@diega

awesome! I'll try to work on eth_signTypedData for the next release!

Trent Mohay

@rain-on

@diega - we were going to wait, but figured releases are cheap so can do them as necessary - let us know if we can help out

PavithraCP

@PavithraCP

Is it needed to unlock an Account in ethsigner (like using personal_unlockAccount of web3) , after creating one using the instructions at https://docs.ethsigner.pegasys.tech/en/stable/Tutorials/Multifile/ at Create Passwords and Key Files section ?

Trent Mohay

@rain-on

@PavithraCP there's no need to explicitly unlock an account, any account configured in Ethsigner (either via TOML or the commandline) will automatically be used to sign a transaction (as based on the "From" field).

PavithraCP

@PavithraCP

@rain-on Thanks!

Vinod Damle

@vdamle

Hi @rain-on hope you are doing well! I wanted to let you know that the io.vertx:* deps in ethsigner need to be updated to at least 3.9.0 to address a critical vulnerability. vertx-core pulls in netty*:4.1.39.Final which is vulnerable to https://nvd.nist.gov/vuln/detail/CVE-2020-11612 . netty needs to be at 4.1.46 or higher (ref: https://mvnrepository.com/artifact/io.vertx/vertx-core)

Trent Mohay

@rain-on

Hey @vdamle, thanks for brining this up - will see if we can get this shortly :thumbsup:

3 replies

MadelineMurray

@MadelineMurray

To improve the experience of users across our product suite, we're moving over to Discord. Here's the invite for the EthSigner channel - https://discord.gg/5U9Jwp7 - would love to see everyone over there. We'll be monitoring and active in this channel for the next 4 weeks and post a few reminders about the move.

David Ammouial

@davux

Hi all! Is is possible to set up Azure KeyVault once and share the configuration across multiple keys? My backend service needs to be able to create keys dynamically so it feels a little bit wrong to create many physical files with the same Azure secret replicated in each one.

especially since Azure KeyVault gives the ability to a client to manage multiple keys

Trent Mohay

@rain-on

Hey @davux, at the moment, every key gets its own config file - so yes, unfortunately, you have to put the secret in multiple places. It's basically due to how EthSigner evolved, in that it treats every key as an independent entity, and thus gets its own config file.
I really like the idea of a single "vault config", with multiple keys, but given our current workload, it's unlikely to be considered for development in the near future.
Otherwise - I should mention, this gitter is deprecated, and we're moving all of our communications across to the Consensys Discord - specifically the invite for the ethsigner channel is https://discord.gg/5U9Jwp7 (as above).

Where communities thrive

People

Repo info

Activity