[readme] Add section Bindings #381

1. 
   fanatid commented at 7:45 pm on March 6, 2016: contributor

   I think section in readme about bindings is better than folding bindings code in this repository (like with Java).

   Related issue: #255

   Bindings authors: @toxeus @xenog @wanderer @afk11 @ludbb @DavidEGrayson @wink @dpc

2. fanatid renamed this:
   [readme] Add section Bindigs
   [readme] Add section Bindings
   on Mar 6, 2016
3. [readme] Add section Bindings bfcf87471e
4. fanatid force-pushed on Mar 6, 2016
5. 
   gmaxwell commented at 7:57 pm on March 6, 2016: contributor

   I disagree that we should be recommending bindings that we have not reviewed. Previously some bindings have compromised the security of the library. (e.g. the go bindings silently using insecure nonce generation).
6. 
   dpc commented at 7:59 pm on March 6, 2016: none

   @apoelstra : What’s the story with https://github.com/dpc/bitcoin-secp256k1-rs ? Did you supersede it with some other repository?
7. 
   fanatid commented at 8:03 pm on March 6, 2016: contributor

   @gmaxwell there no words about recommended, but maybe it make sense add note that bindings wasn’t reviewed? OOI, whom you had in mind under we?
8. 
   gmaxwell commented at 8:18 pm on March 6, 2016: contributor

   Directing people to things which may be insecure like that is just ’laundering’ when we know the note would just be ignored– it might be necessary but it’s not sufficient: Assuming one of the bindings is incorrect (or even malicious) listing it with a note would be a boobytrap and incompatible with our design principle of being hard to misuse.

   Bindings should be subject to peer review by cryptographers; same as the extern C interface of libsecp256k1, since it’s functionally the same when used in different environments. The review will be easier when we finish documenting our design assumptions and objectives; since then the bindings could be checked against satisfying those properties.

9. 
   dpc commented at 8:28 pm on March 6, 2016: none

   @gmaxwell : People will just google “bitcoin bindings in X” or use search function in the package manager of the language of their choice etc.

   IMO having a “big red warning” on the list here, and requiring projects listed in the list to have one in the README, is a win, as it has some chance of informing the potential users.

10. 
    DavidEGrayson commented at 9:11 pm on March 6, 2016: none

    Oh, I see you found my Ruby bindings. I haven’t updated them since April 2015 so I suspect that they don’t work with the latest version of the library. I was going to wait for you guys to release version 1.0.0 of the library before I work on that again. Once everything is polished up, I’d be happy to help cryptographers review it.
11. 
    gmaxwell commented at 0:03 am on March 7, 2016: contributor

    We can include a warning without recommending any bindings: “Note that bindings to other languages may undermine the security of the library and have done so in the past. Great care should be taken when using bindings found on the internet as they may not be suitable for your purposes.”
12. 
    toxeus commented at 6:07 pm on March 9, 2016: none

    (e.g. the go bindings silently using insecure nonce generation)

    Are you referring to this?

13. 
    apoelstra commented at 5:33 pm on March 14, 2016: contributor

    @dpc Sorry I missed this message. Yes, the rust libsecp bindings are now at https://github.com/apoelstra/rust-secp256k1
14. 
    laanwj commented at 8:28 am on March 16, 2016: member

    I think if you decide to add a list of ‘recommended’ bindings then there should be a clear list of review criteria the projects have to adhere to, and a list of tests that it has to pass in the bound language.

    But to take the task of ‘vetting’ projects is quite a responsibility and I can understand if @gmaxwell and al aren’t willing to include that in their scope.

    This may be better for a wiki article or such, with the appropriate warnings.

    On the other hand, good bindings are important for adoption of the library. Putting the bar too high may result in people just ignoring advice, or rolling their own without cooperation and review of others.

15. 
    fanatid commented at 8:46 am on March 16, 2016: contributor

    I’ll glad if somebody will add this list into wiki.
16. fanatid closed this on Mar 16, 2016

    ---

17. fanatid deleted the branch on Mar 16, 2016

Contributors
fanatid gmaxwell dpc DavidEGrayson toxeus apoelstra laanwj