Hi, On 04/05, Stotland, Inga wrote: > > Imagine an existing network provisioned by someone else, (...) > > We would like to add a Linux-based device to that network. (...) > > To achieve that, we need some kind of API that allows provisioning > > meshd locally, ideally via D-Bus. > > To me, this scenario seems to me more like "import the node" rather > than "provision the device". Yes, indeed. Having an API to import a complete node into the daemon would be enough. But note that such an import would need to contain, and *all* the keys, device key included. > We could do that with either a new Import(dict cofiguration) method, > where configuration is a dictionary that contains all the preset > values (netkeys, uuid, unicast, etc). This method is different from > Create() since the netkeys are coming from the "outside". Yes, that would do, but there seem to be some objections to passing keys over DBus. > The current approach is to keep all the netkeys and appkeys within the > daemon without ever exposing them to an application. Yeah, I know. I just don't think it's practical to assume this, because of the use cases mentioned earlier in this thread. I strongly feel there is a need for a centralized database, handled outside of the daemon, ideally on a some kind of internet server. > Alternatively, If a node has been created and configured by a third > party then adding it to the existing meshd management could be > achieved by transcribing its configuration into a meshd internal > storage format (which is in json readable form and could be > potentially exposed as a schema). That's true, but this would also mean that the storage format becomes an API. I don't think this is a good idea, I'd rather allow the daemon to modify storage format freely (with a proper migration from older versions, of course). Especially considering that while JSON works for now, I think in a long run node data should be stored in some kind of transactional database. > > Moreover, since the Attach() token already travels through the bus (...) > Just having the token is not enough: there are some checking > mechanisms (and I believe they need to be extended) to check the > validity of the attaching application. As far as I can see, these checks mostly concern composition data (elements/models in particular), and this can be easily queried. Mesh daemon doesn't seem to use any additional secrets besides the token. So from what I gather, the daemon already depends on the bus being secure, and I don't see any practical difference between exchange of tokens and exchange of keys. > > > Most of your recommendation directly affect the security of the Keys, > > > and whether they get passed via D-Bus... And this is something that I > > > would *not* do without the OK from Marcel Holtmann (...) > > Could you please point me to the relevant thread? I know I'm late to > > he party and would very much like to catch up, as much as I can. > This was a verbal discussion I believe. Oh... Could someone (Brian? Marcel?) please summarize the main points then? It's hard to argue about arguments I cannot possibly know :( regards -- Michał Lowas-Rzechonek <michal.lowas-rzechonek@xxxxxxxxxxx> Silvair http://silvair.com Jasnogórska 44, 31-358 Krakow, POLAND
