Hello, Seva, I'll try to explain my arguments below. > you're saying strange things. First of all, Cfengine will only > authorize remote files copying if a client is known and matches its > host key, so that a client can't grab somebody else's IP and get their > files (because keys won't match). Well, actually this is no longer true as of cfengine 3.1 where you can have root-SHA=.....pub keys. With this cfengine server would not check that the connecting machine's ppkey matches the IP address.
This is a feature. Thanks to it you can have a client machine which would be trusted by the server and it could connect with IP address acquired e.g. from DHCP. Without this feature we would not be able to use cfengine transport for our workstations at all! > Next, you can add encrypt => "true" to your copy_from body when it > comes to transferring sensitive data like password hashes, you don't > neet to invent the wheel. Yes, this is true. Also you can enforce file encryption from the server side, so even if the client is not requesting encryption, the file would be encrypted. But what I meant is not the risk of a man-in-the-middle eavesdropping, but another trusted machine which would 'just' download the file with cfengine transport method. Everything is trusted, everything is ok. The thing is: on some setups (particularly ours) you just *have* to trust the client's ppkey. The number of added hosts is just too large to manually add the trusts on the server. Thus, you might have a machine that 'just' connected to the server and acquired the .cf file along with a hash. > Last, but not least, in the server access rules bundle you can > strictly define which client has access to any given resource. Yes, this is also true. IP-based or DNS-based. If this is unreliable, you are pretty much stuck with nothing. Best regards, Boleslaw Tokarski _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
