Code Monkey home page Code Monkey logo

ncprop279's Introduction

Tor Prop279 Provider for Namecoin

ncprop279 acts as a bridge between Tor Prop279 clients and Namecoin; it can be used for Namecoin naming in Tor. Unlike dns-prop279, it does not use the DNS wire protocol. This reduces attack surface and binary size, but prevents delegation from Namecoin to DNS via NS/DS records.

Usage

You need StemNS or TorNS in order to use ncprop279. You also need a Namecoin lookup client such as Namecoin Core, ConsensusJ-Namecoin, or Electrum-NMC. Your StemNS/TorNS services configuration might look like this:

_service_to_command = {
    "bit.onion": ['/path/to/ncprop279'],
    "bit": ['/path/to/ncprop279'],
}

ncprop279 can be configured by arguments on the command line (see ncprop279 -help) or by the same arguments listed in a configuration file. An example configuration file is provided in ncprop279.conf in this repository, uncomment and edit any desired lines. Note that the [ncprop279] section header is required. This configuration file will not be used automatically. To specify command line arguments directly or give a path to the configuration file, append to the list in the map mentioned above:

"bit.onion": ['/path/to/ncprop279', '-conf=/path/to/ncprop279.conf']

Security Notes

  • ncprop279 hasn't been carefully checked for proxy leaks.
  • Using ncprop279 will make you stand out from other Tor users.
  • Stream isolation for streams opened by applications (e.g. Tor Browser) should work fine.
  • Stream isolation metadata is passed through to the Namecoin lookup client, so any network traffic produced as a result of your lookups (e.g. traffic between Electrum-NMC and ElectrumX) will be stream-isolated.
  • Lookups are cached; the cache is stream-isolated.
  • This whole thing is highly experimental! Please test it and give feedback, but don't rely on it behaving correctly.

License

ncprop279 is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

ncprop279 is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with ncprop279. If not, see https://www.gnu.org/licenses/.

ncprop279 is produced independently from the Tor® anonymity software and carries no guarantee from The Tor Project about quality, suitability or anything else.

ncprop279's People

Stargazers

 avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

ncprop279's Issues

RESOLVE commands are blocking

Currently, ncprop279's implementation of the Prop279 RESOLVE command blocks the main thread, which prevents multiple RESOLVE commands from being done in parallel. We should fix this by making RESOLVE commands execute in parallel.

./nv0.0.4: ncprop279.go: cannot use connCfg: type mismatch btcsuite/btcd/rpcclient vs namecoin/btcd/rpcclient

go build fails with linking errors:

# github.com/namecoin/btcd/rpcclient
../_gopath/pkg/mod/github.com/namecoin/[email protected]/rpcclient/wallet.go:964:36: undefined: btcjson.CreateWalletCmd
../_gopath/pkg/mod/github.com/namecoin/[email protected]/rpcclient/chain.go:227:60: undefined: 
...
../_gopath/pkg/mod/github.com/namecoin/[email protected]/rpcclient/chain.go:545:79: too many errors
# github.com/namecoin/ncrpcclient
../_gopath/pkg/mod/github.com/namecoin/[email protected]/names.go:24:43: undefined: rpcclient.Response
../_gopath/pkg/mod/github.com/namecoin/[email protected]/names.go:29:24: undefined: rpcclient.ReceiveFuture
../_gopath/pkg/mod/github.com/namecoin/[email protected]/names.go:79:11: c.SendCmd undefined (type *Client has no field or method SendCmd)
...

or, if I provide namecoin/btcd in two local directories, path-replaced from github.com/namecoin/btcd and from gitbub.com/btcsuite/btcd then I get this type mismatch error:

 # github.com/namecoin/ncprop279
./ncprop279.go:57:30: cannot use connCfg (variable of
 type *"github.com/namecoin/btcd/rpcclient".ConnConfig)
   as *"github.com/btcsuite/btcd/rpcclient".ConnConfig value
in argument to namecoin.New  

There seems to be a type mismatch, indeed:

  • ncdns/namecoin/namecoin.go imports and declares the arg to the namecoin.New() function argument as "github.com/btcsuite/btcd/rpcclient".
  • ncprop279.go imports and instantiates "github.com/namecoin/btcd/rpcclient"but then passes it in the call to namecoin.New()

ncprop279.go seems to be the one at fault. The usage of btcsuite/btcd/rpcclient and namecoin/ncrpcclient seem consistent throughout; only ncprop279.go is trying to use namecoin/btcd/rpcclient. Changing this import fixed the build (though I did not test functionality, just that ncprop279 -h executes) :

sed -i 's|"github.com/namecoin/btcd/rpcclient"|"github.com/btcsuite/btcd/rpcclient"|' ncprop279.go

Full working build script for Arch package (but relevant to any build) is here (there are a couple separate issues that may go into separate tickets):
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=ncprop279

Debian packaging

We need ncdns in Debian to get it shipped in Whonix. It might be a very quick job with scripts such as dh-golang, but if we're unlucky it might get really hairy. There's less dependencies and stuff here than in namecoin/ncdns#154 though.

Find a way to clear ncdns cache state on new NYM_EPOCH

Currently, ncdns's cache doesn't delete old stream isolation ID's, which means the cache will grow without bound as Tor Browser creates more circuits. We should look into something along these lines:

  1. StemNS detects that NYM_EPOCH has changed (it does this anyway to clear the StemNS stream isolation cache).
  2. StemNS sends a NEWNYM command over Prop279 to ncprop279.
  3. ncprop279 instructs the ncdns backend to delete all cache entries.

Look into whether ncdns can return non-FQDN CNAMEs

Currently, ncprop279 rejects any CNAME records that aren't FQDN's. I think ncdns will always return a FQDN, even if the Namecoin "alias" record isn't a FQDN, but we should verify this. If I'm correct, we should add a comment to ncprop279 explaining this; if I'm wrong, then we should make ncprop279 handle non-FQDN CNAME records.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.