Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    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:
    1. Loving your work :)
    2. 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:
    1. Http Handling and Ethereum-oriented functions
    2. 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?
    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
    2020-05-31 17:53:19.655+02:00 | main | INFO | SignerSubCommand | Version = ethsigner/v0.6.1-dev-82352575/linux-x86_64/oracle-java-13
    2020-05-31 17:53:19.669+02:00 | main | ERROR | FileBasedSignerFactory | File not found: /config/password
    Failed to construct a signer from supplied arguments.
    Cause: File not found: /config/passwor
    d
    Oussama Chaabouni
    @oussamachaabouni
    now he gace me this error
    020-05-31 18:48:22.623+02:00 | main | INFO | SignerSubCommand | Version = ethsigner/v0.6.1-dev-82352575/linux-x86_64/oracle-java-13
    2020-05-31 18:48:23.515+02:00 | vert.x-eventloop-thread-2 | ERROR | HttpServerService | HTTP server service failed to listen
    java.net.BindException: Adresse déjà utilisée
    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).