On 11/12/2016 01:14 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Sat, Nov 12, 2016 at 11:17:39AM -0500, Stephen John Smoogen wrote: >> On 11 November 2016 at 22:20, Zbigniew Jędrzejewski-Szmek >> <zbys...@in.waw.pl> wrote: >>> On Fri, Nov 11, 2016 at 01:20:26PM -0500, Stephen Gallagher wrote: >> >>>> I can't think of a reason why we'd need a cryptographically secure >>>> transformation just to generate a random hostname. >>> >>> We want it cryptographically secure to preserve the machine-id. It's >>> probably not too important in itself, but it's a good idea to keep >>> it hidden because other hashes might be generated from it. >> >> Which lies in the problem. If people are going to derive hashes from >> it they will do so any way the want and most likely it will be leaked >> out by someone doing a sum or just copying it etc. If there is >> something 'unique' on a system, it will leak out eventually. All you >> can do is try to design to drip out slowly or pour out all at once. >> Trying to find some happy middle ground ends up usually with it >> pouring out all at once when no one expected it. > > True. But one, it's not *that* important, it's not the root password > or anything. But two, it'd say that we're designing it to drip out very > very slowly.
One way to address this might be for systemd to provide an API for what Lennart
is suggesting and market that as "the correct way to generate a
machine-id-derived string".
Basically, I see the function looking something like:
```
const char *
generate-machine-id(uint64_t app-specific-key,
char *acceptable_chars,
size_t num_characters)
```
(C example given, but probably we'd actually want this in D-BUS to be
language-agnostic.)
Then systemd can control the cryptographic hash. If this function exists and is
public, then people will generally be inclined to use it and we will minimize
the number of people who opt to try to write their own or use the machine-id
directly.
I will file an RFE.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
