Verification routines in nmcontrol

[domob]

Currently, nmcontrol implements a "dns getFingerprint" routine for TLS verification. The actual verification (including stripping of colons and handling of fingerprint arrays) is done in Convergence, though. Would it make sense to add a routine like

Code: Select all

$ nmcontrol dns verifyFingerprint domob.bit CDCE9B6391057DD67338E20E50C7FEA37752A2F5
true

to nmcontrol? That could help to share at least a little more code between implementations. The same could be done for GPG or OTR fingerprints (and other things). Furthermore, I could also see these in nmcontrol:

• Verification of "signer" signatures and finding a list of allowed signer addresses for a name (so that a tool can check whether one of these is in your wallet).
• Verification of NameID login signatures plus construction of challenge messages. This is trivial now (but could still be useful, after all, also getFingerprint & co are trivial), but could be more evolved if the protocol is changed in the future.
• File signatures: Both construction of signature strings + names to store them into (not the actual signature itself, of course, since nmcontrol doesn't handle private keys) and verification (given a filename, return a list of names that signed it properly).

What do you think, do such verification routines have a place inside nmcontrol? Or should it only contain "getSomething" type methods?

[phelix]

IMHO yes.

Not sure they will be used a lot at this point.

[khal]

What do you think, do such verification routines have a place inside nmcontrol?

Yes, it would help any new implementation and also concentrate efforts on a single point.

We need to create pluginNamespaceID.py at least.

For generic things which can be in several namespaces, like the "signer" field, should we create a plugin "generic" ?

[domob]

Khal: Thanks for your opinion. I'll do it, just waiting for more input on the names of plugins and methods to create (as I don't want to just invent something myself).

[khal]

Khal: Thanks for your opinion. I'll do it, just waiting for more input on the names of plugins and methods to create (as I don't want to just invent something myself).

I admit that it may be a bit complex to follow where the code should go :p

The most complex interactions are related to DNS, here are how it is articulated :

plugin :
* pluginDNS :
- can resolve rpc requests for .bit or any other plugin that register itself as a DNS handler
- reply can be formatted in json or as a classic DNS request (used by the DNS server)
- only understand domain names, not namecoin names
* pluginNamespaceDomain.py :
- register itself as a DNS handler, must implement the methods needed by the DNS handler (_handle, _resolve + config)
- can resolve rpc requests for .bit and .tor + specific rpc requests for that namespace not covered by the DNS
- does not currently provide useful public rpc method usable with "d/" names
- the only public method "lookup" uses a domain name as input instead of a name (which is wrong) and is only used by the DNS plugin
service :
* serviceDNS.py :
- DNS server, can be started on port 53 or else (conf/service-dns.conf to tweak it)
- uses pluginNamespaceDomain.py for .bit and .tor, other internal method otherwise

Here is how to define a handler for the DNS plugin :

class pluginNamespaceDomain()
handle = ['dns'] # the DNS plugin will check this
filters = {'dns': '.bit$|.tor$'} # the DNS plugin will use this plugin only for .bit and .tor domains
def pLoadconfig(self): # register itself as a handler for the DNS plugin
app['plugins']['dns'].handlers.append(self)

class serviceDNS()

Currently uses pluginNamespaceDomain for .bit and .tor (hardcoded) and a private method for others (.com, etc).
May be upgraded to use the pluginDNS instead and fallback to the private method if no handler found (I'm not sure yet it should be done like that).

I hope you have a better view with this.
Do not hesitate to ask more infos :p

[biolizard89]

Currently, nmcontrol implements a "dns getFingerprint" routine for TLS verification. The actual verification (including stripping of colons and handling of fingerprint arrays) is done in Convergence, though. Would it make sense to add a routine like

Code: Select all

$ nmcontrol dns verifyFingerprint domob.bit CDCE9B6391057DD67338E20E50C7FEA37752A2F5
true

to nmcontrol? That could help to share at least a little more code between implementations. The same could be done for GPG or OTR fingerprints (and other things). Furthermore, I could also see these in nmcontrol:

• Verification of "signer" signatures and finding a list of allowed signer addresses for a name (so that a tool can check whether one of these is in your wallet).
• Verification of NameID login signatures plus construction of challenge messages. This is trivial now (but could still be useful, after all, also getFingerprint & co are trivial), but could be more evolved if the protocol is changed in the future.
• File signatures: Both construction of signature strings + names to store them into (not the actual signature itself, of course, since nmcontrol doesn't handle private keys) and verification (given a filename, return a list of names that signed it properly).

What do you think, do such verification routines have a place inside nmcontrol? Or should it only contain "getSomething" type methods?

Sorry I'm late to the party, but yes, I support this proposal as well.