On 11/11/2016 12:08 PM, Lennart Poettering wrote: > On Fri, 11.11.16 11:12, Stephen Gallagher (sgall...@redhat.com) 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 realize that some of this is coming from my old-school sensibilities, but I still remember a time when changing the hostname of a running system caused lots of things to fail, including NFS and sendmail. Changing the enrolling code to modify the machine's hostname would be very unexpected from an end-user perspective, don't you think? >> * 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) > See child reply. I was trying to spare us some entropy during early setup, but I can't think of any reason this needs to be any more complicated than something fed from /dev/random if we aren't going to try to generate it early in the install process.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
