On Fri, 11.11.16 11:12, Stephen Gallagher (sgallagh@xxxxxxxxxx) wrote: > The hostname may always be set manually and the result will (for the vast > majority of people) be unique within their environment. This means that if we > are concerned with hostname leakage being a privacy issue, we need to address > that at the leakage point, not at the hostname point. > > Also, there are cases where hostname leakage may be used specifically *because* > it may be unique, such as one of several cues to the DHCP server. Unfortunately, > we cannot know in advance whether a DHCP server is going to be on a trusted or > untrusted network (we might be able to guess from the SSID of a WiFI connection, > but those are remarkably easy to fake). > > In short, I really don't think that the hostname is the right place to solve > this problem. If transmission of individually-identifying information is a > concern, then we really have to solve it at the transmission points and not at > the source. > > Yes, an argument could be made that a user who sets her own hostname is > "opting-in" to that uniqueness, but I think that's setting an unrealistic > expectation on all of our users that they fully understand the consequences of > that action. I still believe we should stick to a generic hostname by default, (though I'd rather use "localhost" than "localhost.localdomain" in order to drop the redhatism that "localdomain" is), and make the IPA client-side enrollment code automatically update to a more "unique" hostname if the hostname is found to be unset or be "localhost". I am also pretty sure that DHCP clients should suppress sending local hostname information if the local hostname is unset or "localhost". > * I like Zbigniew and Lennart's thoughts on how to generate the "random" suffix. > the implementation I'd likely use is to take the first eight characters of an > md5 (or SHA) hash of /etc/machine-id and use those. That should make it both > repeatable and unique. Please do not use MD5 anymore. And please calculate your ID as SHA(x || k) x refers to the machine id, "||" refers to concatenation and "k" refers to some app-specific key (which is OK to be publically known). It's important to concatenate the app-specific key, so that it is not possible to map the machine IDs used by one app to the machine IDs used by another.. Lennart -- Lennart Poettering, Red Hat _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx