Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)
Simon McVittie writes ("Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)"):
> Somehow describing which containers and chroots should have a machine ID,
> which ones should share the host's machine ID and which ones don't need
> either is a gap in my proposal.
Do we have a list of all the things this is (or might be) used for ?
I think that would help us think about these kind of questions, and
also decide how important it was to improve this area. (Please
forgive me if someone already mentioned such a list which I overlooked
in this thread.)
We need to think about the privacy implications. Certainly the
machine id should not normally go into network protocols.
Can we think of other uses of the machine id that might seem like a
good idea to some upstreams, but of which we would disapprove (whether
for technical or ethical reasons) ?
I wonder if we should in Debian have a "sticky door" policy on the use
of machine-id, like we do for virtual packages: "please come to -devel
for a peer review". We could spot these issues with a lintian check
maybe.
Sorry that these considerationsn probably seem rather negative. It's
in my nature to try to spot the downsides and problems with things;
please take this as an attempt at constructive foresight.
If we decide this machine-id is a good thing that should be in X and Y
and Z (containers, chroots, "pets" running sysvinit, or whatever
combination, etc.) then we could implement that in our own
arrangements even if upstream haven't taken those patches yet.
Regards,
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Reply to: