Re: [DNG] new freedesktop "standard": /etc/machine-id
For me the short answer is that I very much dislike this and would prefer not to have it. There was an open issue in my git repo about performance issues relating to 'machine id' and pulse when dbus is not available. The person reporting it provided a hackish work around and I later asked them to file this as a bug with debian. Not sure if Debian got a bug report, and it was a while ago so I'm not sure if it can be reproduced now. I think it's generally better if we can do without it so that things work as expected when users decide not to use dbus, pulse, etc. That's my two cents on that anyway. Cheers, chillfan ‐‐‐ Original Message ‐‐‐ On Friday, March 8, 2019 12:47 PM, Jaromil wrote: > re all, > > any thoughts about this new systemd-made thing that freedesktop > immediately "standardized" (whatever is their procedure for that, > likely smoking cigars among old-boys or so) > https://www.freedesktop.org/software/systemd/man/machine-id.html > > its easy to replace by a script of course that's not the problem (the > manpage suggests to use a systemd application for that, not a joke!) > but I'm curious if anyone has some background and thoughts about this > > AFAIK chromium started checking it and its absence on Devuan Beowulf > is reported as an error, so we may have to work around this. > > but first things first: do we want /etc/machine-id? and how? > > ciao > > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng publickey - chillfan@protonmail.com - 0xB179B25B.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
* On 2019 18 Mar 06:35 -0500, Olaf Meeuwissen wrote: > I wrote "the IP address is in /etc/hosts", but I think that should have > been "the IP address what your hostname resolves to" :-/ > > In many common scenarios that is likely to be the same as what is in > your /etc/hosts file, but really depends on how name resolution is > configured on your machine. > > Hope this helps, Thanks, Olaf. I just replied as it seemed like an interesting thought exercise. :-) - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: http://www.n0nb.us GPG key: D55A8819 GitHub: N0NB signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
Hi Nate, Apologies for the belated follow-up. Nate Bargmann writes: > * On 2019 09 Mar 18:09 -0600, Olaf Meeuwissen wrote: >> All the info I have seen on this topic in the thread is consistent with >> hostid returning the "mangled" IP address belonging to the machine's >> current hostname. This is normally set from /etc/hostname. That file >> is created during installation. The IP address is in /etc/hosts. >> >> Taking 007f0100 as an example, swapping bytes in pairs gives 7f01 >> which gives 127.0.0.1. For 007f0101 you get 127.0.1.1. >> >> I just tried the following on my machine >> >> $ sudo hostname yoda # anything different from what you have now >> $ hostid # this is silent for a while and then says >> >> >> Presumably, DNS times out and then you get whatever the code used to >> initialize the return value. >> >> Trying to revert my change >> >> $ sudo hostname quark # this ponders things for a while and says >> sudo: unable to resolve host yoda >> $ hostid >> 007f0101 >> >> Please note that the hostname command does *not* modify the contents of >> /etc/hostname. To persist changes across reboots you'll need to edit >> /etc/hostname yourself. > > It looks like I have an exception: > > pi@aprxpi:~$ cat /etc/os-release > PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)" > NAME="Raspbian GNU/Linux" > VERSION_ID="8" > VERSION="8 (jessie)" > ID=raspbian > ID_LIKE=debian > HOME_URL="http://www.raspbian.org/; > SUPPORT_URL="http://www.raspbian.org/RaspbianForums; > BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs; > pi@aprxpi:~$ ip address > 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group > default qlen 1 > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo >valid_lft forever preferred_lft forever > inet6 ::1/128 scope host >valid_lft forever preferred_lft forever > 2: eth0: mtu 1500 qdisc pfifo_fast state UP > group default qlen 1000 > link/ether b8:27:eb:8b:f3:1c brd ff:ff:ff:ff:ff:ff > inet 192.168.25.61/24 brd 192.168.25.255 scope global eth0 >valid_lft forever preferred_lft forever > inet6 fd5d:beb2:2c86:0:ba27:ebff:fe8b:f31c/64 scope global mngtmpaddr > dynamic >valid_lft forever preferred_lft forever > inet6 2001:470:1f0f:9fa:ba27:ebff:fe8b:f31c/64 scope global mngtmpaddr > dynamic >valid_lft forever preferred_lft forever > inet6 fe80::ba27:ebff:fe8b:f31c/64 scope link >valid_lft forever preferred_lft forever > 4: ax0: mtu 512 qdisc pfifo_fast state UNKNOWN > group default qlen 10 > link/ax25 9c:60:9c:84:40:40:74 brd a2:a6:a8:40:40:40:00 > pi@aprxpi:~$ hostid > a8c03d19 > pi@aprxpi:~$ hostname > aprxpi.lan > pi@aprxpi:~$ cat /etc/hosts > 127.0.0.1 localhost > 127.0.1.1 aprxpi > pi@aprxpi:~$ ll /etc/host* > -rw-r--r-- 1 root root 9 Aug 7 2006 /etc/host.conf > -rw-r--r-- 1 root root 11 Mar 11 2018 /etc/hostname > -rw-r--r-- 1 root root 37 Jun 18 2018 /etc/hosts > -rw-r--r-- 1 root root 411 Mar 11 2016 /etc/hosts.allow > -rw-r--r-- 1 root root 711 Mar 11 2016 /etc/hosts.deny > > > On this particular machine the hostid is consistent with the IPv4 address of > eth0. I wrote "the IP address is in /etc/hosts", but I think that should have been "the IP address what your hostname resolves to" :-/ In many common scenarios that is likely to be the same as what is in your /etc/hosts file, but really depends on how name resolution is configured on your machine. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On 08.03.19 14:23, KatolaZ wrote: > this is currently managed by eudev in devuan and, IIRC, it is simply > regenerated as a random ID at each boot. I guess it's still there > because it is used by several things, including > session-management-related stuff. We had a discussion on IRC with Mark > (LeePen) about that several weeks ago, and IIRC we concluded that > keeping it around but re-generating it at boot was the way to avoid > breakage. > > Any thoughts on the matter are appreciated, but concrete insight on > the ins and outs are much more useful I guess (read: please let's > avoid a useless uninformed flame about that :P). I would assume that the machine-id is used for: 1. Software Licencing 2. Identifying machines in a pool/swarm/cluster/cloud of machines where static IP adresses are not necessarily a given similar to HP/HP-UX: /bin/uname -i IBM/AIX: /bin/uname -m SGI/IRIX: /sbin/sysinfo -s Sun/Solaris: /usr/ucb/hostid machine-id should theoretical be a serial number or UUID Cheers Mike ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
I used to and still do hot mount all my drives using autofs. Am 10. März 2019 20:24:20 MEZ schrieb Steve Litt : >On Sat, 09 Mar 2019 10:25:39 -0600 >goli...@dyne.org wrote: > > >> I certainly did not write that! (I'm not even sure what inotify >> is!) LOL! >> >> golinux > >inotify is a Linux specific kernel API that detects changes in the >filesystem. It can be set to discover changes in a specific directory, >or even a specific file. Remember when Poettering tearfully proclaimed >that systemd was the only way to "hot mount" stuff like thumb drives? >On hearing that, I and another guy on this list took a couple hours and >made an inotify based shellscript to auto-mount thumb drives as they're >plugged in. It wasn't popular here because most Devuaners don't like >the idea of automount: They prefer such mounting be opt-in. > >But we sure did refute Poettering. > >SteveT >___ >Dng mailing list >Dng@lists.dyne.org >https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On Sat, 09 Mar 2019 10:25:39 -0600 goli...@dyne.org wrote: > I certainly did not write that! (I'm not even sure what inotify > is!) LOL! > > golinux inotify is a Linux specific kernel API that detects changes in the filesystem. It can be set to discover changes in a specific directory, or even a specific file. Remember when Poettering tearfully proclaimed that systemd was the only way to "hot mount" stuff like thumb drives? On hearing that, I and another guy on this list took a couple hours and made an inotify based shellscript to auto-mount thumb drives as they're plugged in. It wasn't popular here because most Devuaners don't like the idea of automount: They prefer such mounting be opt-in. But we sure did refute Poettering. SteveT ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On Sat, 9 Mar 2019 10:28:50 +0100 Didier Kryn wrote: > Le 09/03/2019 à 10:03, Didier Kryn a écrit : > > Le 09/03/2019 à 09:34, goli...@dyne.org a écrit : > >> I'd recommend adding an inotify rule to record which processes > >> look at these files, and publishing this - here. > > > > Unfortunately inotify doesn't tell which process accessed the > > file )~: > > But fanotify() is perfectly suited (~: > > Didier In which case you can not only change /etc/machine-id, but also write to a log when it was accessed, what kind of access, and who accessed it. We can then "out" the accessors. SteveT ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On Sun, 10 Mar 2019 14:58:52 +0100, Martin wrote in message <1790105.p7Nha06Ba6@merkaba>: > Jaromil - 10.03.19, 14:03: > > > > but first things first: do we want /etc/machine-id? and how? > > > > > > In my view it falls in the completely unnessesary or the > > > potentially dangerous group. > > > > > > I don't want it. > > > > while I'm still catching up with reading all the thread, I think you > > make a concise and straight to the point argument with which I > > wholeheartedly agree. Thanks, to you and all others providing > > insights on this issue. > > > > I also don't want it and I think having such a machine-id is not > > just a technical, but also a political decision, as you pointed out. > > > > for the record, my /etc/machine-id follows: > > > > "d34dc0d3d34dc0d3d34dc0d3d34dc0d3" > > I felt uneasy about the machine-id several times as well. It > remembers me of the IMEI of mobile devices. > > After browsing through thread and internet references I am still not > clear what it is used for. Every privacy policy in EU needs to state > that purpose, especially for uniquely identifying data. > > It never came to my conclusion that I can just change the id. Now did. > > Probably would be good for a lot of people setting it to the same > value :). As when everyone comes up with an own machine id chances > are that it is still unique. Another way would be to randomize it on > every boot or every few hours. ...or every minute. ;o) > Thanks, -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
Jaromil - 10.03.19, 14:03: > > > but first things first: do we want /etc/machine-id? and how? > > > > In my view it falls in the completely unnessesary or the potentially > > dangerous group. > > > > I don't want it. > > while I'm still catching up with reading all the thread, I think you > make a concise and straight to the point argument with which I > wholeheartedly agree. Thanks, to you and all others providing insights > on this issue. > > I also don't want it and I think having such a machine-id is not just > a technical, but also a political decision, as you pointed out. > > for the record, my /etc/machine-id follows: > > "d34dc0d3d34dc0d3d34dc0d3d34dc0d3" I felt uneasy about the machine-id several times as well. It remembers me of the IMEI of mobile devices. After browsing through thread and internet references I am still not clear what it is used for. Every privacy policy in EU needs to state that purpose, especially for uniquely identifying data. It never came to my conclusion that I can just change the id. Now did. Probably would be good for a lot of people setting it to the same value :). As when everyone comes up with an own machine id chances are that it is still unique. Another way would be to randomize it on every boot or every few hours. Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
dear Karl, On Fri, 08 Mar 2019, k...@aspodata.se wrote: > Jaromil: > > any thoughts about this new systemd-made thing that freedesktop > > immediately "standardized" (whatever is their procedure for that, > > likely smoking cigars among old-boys or so) > > https://www.freedesktop.org/software/systemd/man/machine-id.html > ... > > . It doesn't say "why". > Why should I (we) provide a means to uniquely identify my systems ? > I don't need it. Is it for > - the nice though not useful concept, yes we reinvent things you know > - the ongoing trend for more surveillance from the authorities > - the ongoing trend for more surveillance from the advertising firms > - the ongoing trend for more surveillance for "copyright" reason > > . It says "This ID uniquely identifies the host." > - on the lan I can just as well use hostname or the primary ip-number > - on the internet I use the fqdn or the ip-number > The uniqness part will fail without someone guarantying the uniqness. > Do we have an "IEEE handling out oui's" - for machine-id's ? > Even if there were some IEEE, pci- or usb-consortium handling out vendor > parts of the id's, there is no guaranty for uniqness since that > number is just what's the local admin fancies, or is it for > "tamperproof" hardware, something oppressive regimes would like. > And I have seen pci cards with the wrong vendor part: "the programmer > left and we don't have the code so we cannot change it" as the vendor > put it. > > > AFAIK chromium started checking it and its absence on Devuan Beowulf > > is reported as an error, so we may have to work around this. > > Isn't that a bug, the above man page says: > It should be considered "confidential", and must not be exposed in > untrusted environments, in particular on the network. > Why would a network centric program need this unless it wants to > expose it ? > > > but first things first: do we want /etc/machine-id? and how? > > In my view it falls in the completely unnessesary or the potentially > dangerous group. > > I don't want it. while I'm still catching up with reading all the thread, I think you make a concise and straight to the point argument with which I wholeheartedly agree. Thanks, to you and all others providing insights on this issue. I also don't want it and I think having such a machine-id is not just a technical, but also a political decision, as you pointed out. for the record, my /etc/machine-id follows: "d34dc0d3d34dc0d3d34dc0d3d34dc0d3" ciao -- Denis "Jaromil" Roio https://Dyne.org think tank Ph.D, CTO & co-foundersoftware to empower communities ✉ Haparandadam 7-A1, 1013AK Amsterdam, The Netherlands ✩ Profile and publications: https://jaromil.dyne.org 턞 crypto κρυπτο крипто गुप्त् 加密 האנוסים المشفره ⚷ 6113D89C A825C5CE DD02C872 73B35DA5 4ACB7D10 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
* On 2019 09 Mar 18:09 -0600, Olaf Meeuwissen wrote: > All the info I have seen on this topic in the thread is consistent with > hostid returning the "mangled" IP address belonging to the machine's > current hostname. This is normally set from /etc/hostname. That file > is created during installation. The IP address is in /etc/hosts. > > Taking 007f0100 as an example, swapping bytes in pairs gives 7f01 > which gives 127.0.0.1. For 007f0101 you get 127.0.1.1. > > I just tried the following on my machine > > $ sudo hostname yoda # anything different from what you have now > $ hostid # this is silent for a while and then says > > > Presumably, DNS times out and then you get whatever the code used to > initialize the return value. > > Trying to revert my change > > $ sudo hostname quark # this ponders things for a while and says > sudo: unable to resolve host yoda > $ hostid > 007f0101 > > Please note that the hostname command does *not* modify the contents of > /etc/hostname. To persist changes across reboots you'll need to edit > /etc/hostname yourself. It looks like I have an exception: pi@aprxpi:~$ cat /etc/os-release PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)" NAME="Raspbian GNU/Linux" VERSION_ID="8" VERSION="8 (jessie)" ID=raspbian ID_LIKE=debian HOME_URL="http://www.raspbian.org/; SUPPORT_URL="http://www.raspbian.org/RaspbianForums; BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs; pi@aprxpi:~$ ip address 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether b8:27:eb:8b:f3:1c brd ff:ff:ff:ff:ff:ff inet 192.168.25.61/24 brd 192.168.25.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fd5d:beb2:2c86:0:ba27:ebff:fe8b:f31c/64 scope global mngtmpaddr dynamic valid_lft forever preferred_lft forever inet6 2001:470:1f0f:9fa:ba27:ebff:fe8b:f31c/64 scope global mngtmpaddr dynamic valid_lft forever preferred_lft forever inet6 fe80::ba27:ebff:fe8b:f31c/64 scope link valid_lft forever preferred_lft forever 4: ax0: mtu 512 qdisc pfifo_fast state UNKNOWN group default qlen 10 link/ax25 9c:60:9c:84:40:40:74 brd a2:a6:a8:40:40:40:00 pi@aprxpi:~$ hostid a8c03d19 pi@aprxpi:~$ hostname aprxpi.lan pi@aprxpi:~$ cat /etc/hosts 127.0.0.1 localhost 127.0.1.1 aprxpi pi@aprxpi:~$ ll /etc/host* -rw-r--r-- 1 root root 9 Aug 7 2006 /etc/host.conf -rw-r--r-- 1 root root 11 Mar 11 2018 /etc/hostname -rw-r--r-- 1 root root 37 Jun 18 2018 /etc/hosts -rw-r--r-- 1 root root 411 Mar 11 2016 /etc/hosts.allow -rw-r--r-- 1 root root 711 Mar 11 2016 /etc/hosts.deny On this particular machine the hostid is consistent with the IPv4 address of eth0. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: http://www.n0nb.us GPG key: D55A8819 GitHub: N0NB signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
* On 2019 09 Mar 17:01 -0600, Antoine via Dng wrote: > It looks to me as if this is indeed the computer's IP address... just the > loopback one, slightly mangled: > > - 127.0.0.1 => 0.127.1.0 i.e. 007f0100 > or > - 127.0.1.1 => 0.127.1.1 i.e. 007f0101 > > I tried changing the IPaddress on my loopback interface, but the returned > hostid didn't change. > > What do you think? pi@aprxpi:~$ cat /etc/os-release PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)" NAME="Raspbian GNU/Linux" VERSION_ID="8" VERSION="8 (jessie)" ID=raspbian ID_LIKE=debian HOME_URL="http://www.raspbian.org/; SUPPORT_URL="http://www.raspbian.org/RaspbianForums; BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs; pi@aprxpi:~$ ip address 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether b8:27:eb:8b:f3:1c brd ff:ff:ff:ff:ff:ff inet 192.168.25.61/24 brd 192.168.25.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fd5d:beb2:2c86:0:ba27:ebff:fe8b:f31c/64 scope global mngtmpaddr dynamic valid_lft forever preferred_lft forever inet6 2001:470:1f0f:9fa:ba27:ebff:fe8b:f31c/64 scope global mngtmpaddr dynamic valid_lft forever preferred_lft forever inet6 fe80::ba27:ebff:fe8b:f31c/64 scope link valid_lft forever preferred_lft forever 4: ax0: mtu 512 qdisc pfifo_fast state UNKNOWN group default qlen 10 link/ax25 9c:60:9c:84:40:40:74 brd a2:a6:a8:40:40:40:00 pi@aprxpi:~$ hostid a8c03d19 In this case it appears to be setting the hostid to the IPv4 address of eth0. Hmmm. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: http://www.n0nb.us GPG key: D55A8819 GitHub: N0NB signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
* On 2019 09 Mar 07:05 -0600, al3xu5 / dotcommon wrote: > using the `hostid` command, I have (Devuan ASCII): > > $ hostid > 007f0101 > > which is the same value!!! > > I wonder... is it a "fixed" id for all Devuan installation as it seems to be? I get the same value on Debian Jessie i686, Debian Buster amd64, Raspbian Stretch, and Debian Stretch i686, amd64, and armhf. On another Raspbian derivative machine I get: $ hostid a8c03d19 however. On a Slackware 14.2 i686 VM I get: $ hostid 007f0100 On a Slackware 14.2 x86_64 VM I get: $ hostid 007f0200 > And if it is so,is it correct that it is? It looks to me as though Debian and most derivatives mostly have the same value. Perhaps this is a value that can be set when compiling glibc? - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: http://www.n0nb.us GPG key: D55A8819 GitHub: N0NB signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On Sun, Mar 10, 2019 at 09:06:50AM +0900, Olaf Meeuwissen wrote: [cut] > > I get 007f0100 on one jessie, 007f0101 on another jessie and 007f0101 > > on ascii. (Three different computers) > > > > The ascii install is on a laptop that has several installations. When I > > reboot it into jessie, I get 007f0100. Ceres on that same box gives me > > 007f0100. > > All the info I have seen on this topic in the thread is consistent with > hostid returning the "mangled" IP address belonging to the machine's > current hostname. This is normally set from /etc/hostname. That file > is created during installation. The IP address is in /etc/hosts. > Yeah, that works like that unless there is an /etc/hostid. That file is normally created upon each call to sethostid. My2Cents KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
Hendrik Boom writes: > On Sat, Mar 09, 2019 at 02:34:28AM -0600, goli...@dyne.org wrote: >> >> Oh, my . . . how fast and how hard Debian has fallen . . I am all for >> shining light into dark, dank places. What a terrific idea to track >> down all the offending packages that are "leaking" information and then >> publish an ongoing list of them and how they "phone home". >> >> golinux > > Good idea. Just like the evil bit. https://www.ietf.org/rfc/rfc3514.txt :-) The evil bit of that RFC is in the publication date ;-) -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
fsmithred via Dng writes: > On Sat, 9 Mar 2019 16:27:10 +0100 > Arnt Karlsen wrote: > >> On Sat, 9 Mar 2019 14:04:13 +0100, al3xu5 wrote in message >> <20190309130422.386f8f60...@vm6.ganeti.dyne.org>: >> > >> > I wonder... is it a "fixed" id for all Devuan installation as it >> > seems to be? >> >> ..yes and no and no etc, I have: >> nb6:~# hostid #Devuan Jessie >> 007f0101 >> sda3:~# hostid #Devuan Ascii >> 007f0100 >> devuan:~# hostid #Devuan Ascii on rPi-1 >> 007f0100 >> rir:~# hostid #Raspian Jessie >> >> devuan@dvn:~$ hostid #Devuan Ascii Live usb >> > > I get 007f0100 on one jessie, 007f0101 on another jessie and 007f0101 > on ascii. (Three different computers) > > The ascii install is on a laptop that has several installations. When I > reboot it into jessie, I get 007f0100. Ceres on that same box gives me > 007f0100. All the info I have seen on this topic in the thread is consistent with hostid returning the "mangled" IP address belonging to the machine's current hostname. This is normally set from /etc/hostname. That file is created during installation. The IP address is in /etc/hosts. Taking 007f0100 as an example, swapping bytes in pairs gives 7f01 which gives 127.0.0.1. For 007f0101 you get 127.0.1.1. I just tried the following on my machine $ sudo hostname yoda # anything different from what you have now $ hostid # this is silent for a while and then says Presumably, DNS times out and then you get whatever the code used to initialize the return value. Trying to revert my change $ sudo hostname quark # this ponders things for a while and says sudo: unable to resolve host yoda $ hostid 007f0101 Please note that the hostname command does *not* modify the contents of /etc/hostname. To persist changes across reboots you'll need to edit /etc/hostname yourself. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
Antoine via Dng wrote on 10/3/19 10:00 am: > I tried changing the IPaddress on my loopback interface, but the > returned hostid didn't change. Try editing /etc/hosts and move your hostname entry to something else Ralph. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On Sat, Mar 09, 2019 at 10:38:57AM -0600, goli...@dyne.org wrote: On 2019-03-09 07:21, Alessandro Selli wrote: > On 09/03/19 at 14:04, al3xu5 / dotcommon wrote: > > > > > my id is 0x007f0101 > > > > > > [...] > > > > > > my id is 0x007f0101 > > > > > > [...] > > > > > > my id is 0x007f0101 > > > > > [...] > > 007f0101 007f0101 It looks to me as if this is indeed the computer's IP address... just the loopback one, slightly mangled: - 127.0.0.1 => 0.127.1.0 i.e. 007f0100 or - 127.0.1.1 => 0.127.1.1 i.e. 007f0101 I tried changing the IPaddress on my loopback interface, but the returned hostid didn't change. What do you think? - Antoine -- Having high aims in life makes it easier to shoot yourself in the knee rather than in the foot. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
Le 09/03/2019 à 21:48, Arnt Karlsen a écrit : On Sat, 9 Mar 2019 18:12:55 +0100, Didier wrote in message <42982bbd-6ccc-6ed4-2bcc-4d969319c...@in2p3.fr>: I find it comic that dbus, which is a middleware restricted to a single host, builds a unique id to identify this host. We know that the systemd team likes to catch up everything to control it from their blob, even if it looks like pure crap. This makes me think the intention is probably not surveillance, but lock-in because here is the core of their busyness model. They claim that this isn't UUID (Unix Unique ID). And they are right even if it matches the acronym, because it is best named Useless Unique ID. ..so, do we drop that Useless Unique ID scheme from our dbus, or do we drop dbus? ..and, do we help keep Useless Unique ID, Useless, e.g. with cron jobs? I'm balancing. I'm rather in favour of denoucing applications which try to use the machine-id. But, while it's easy as long as they do it by reading a file; it'll be impossible when they obtain it from libsystemd. Hence the necessity to fool them with a random number. Another method could be to always invoke the suspect applications from inside a fresh VM with a fresh random machine-ID. I disliked dbus even before people spoke of systemd and I'm afraid dbus becomes some day the way to force systemd on us. I'd like to drop it right away, but my usual DE (xfce) uses it. But I'm modestly and slowly working to escape it: I'm writing a little application to monitor hot-plug storage in a GUI, of course without dbus, but also without libudev and/or gvfs. I'm almost done - now trying to make sense out of a gtk2 tutorial. I also have a few ideas to replace udev by a script, provided devtmpfs is enabled in the kernel. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On Sat, Mar 09, 2019 at 11:01:43AM -0500, Hendrik Boom wrote: > On Sat, Mar 09, 2019 at 02:34:28AM -0600, goli...@dyne.org wrote: > > Oh, my . . . how fast and how hard Debian has fallen . . I am all for > > shining light into dark, dank places. What a terrific idea to track > > down all the offending packages that are "leaking" information and then > > publish an ongoing list of them and how they "phone home". > > Good idea. Just like the evil bit. https://www.ietf.org/rfc/rfc3514.txt The evil bit is impossible only if you don't have means of controlling the software. A distribution, and the user, can check and/or alter every bit of code that's running. The vast majority of phone home functionality in question has no malicious _intent_, even if consequences may be dire. For example: * clementine, a music player -- sends info about every song you play, even local, to 20+ servers to get lyrics, "last.fm scrobbler" (whatever that is), etc. The intent is to have a feature some users may want, enabled by default. Consequences: copyright mafia getting you for piracy, marketing mafia knowing your music preferences, possibly government mafia if instead of music you listen to dissident podcasts. * systemd-networkd falls back to 8.8.8.8 if there's no configured DNS resolver (usually due to tempfail). Intent: even with misconfiguration, "the Internet" works. Consequences: every single your network requests gets sent to world's second most nosy company, which has extensive infrastructure for cross-matching this kind of data. Extra fun if you're working in a secret government group of a country not liked by the US -- or a competitor to Google, or, ... There's very few cases where I suspect ill intent: * chromium saves the URL and referer of every file you download hidden as an user namespace xattr (so methods known to the vast majority of sysadmins and even filesystem engineers won't find that) * chromium sends /etc/machine-id as "Cloud something Enrollment Token" The latter is golden, and can fool a casual reviewer: // The client ID is derived from /etc/machine-id // (https://www.freedesktop.org/software/systemd/man/machine-id.html). As per // guidelines, this ID must not be transmitted outside of the machine, which // is why we hash it first and then encode it in base64 before transmitting // it. So how exactly a 160-bit hash of a 128-bit random value (ie, having no structured data inside beside being unique) would help? At this point, we face either stupidity or malice, but I wouldn't insult Googlers by accusing them of incompetence. And that means... Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour? ⠈⠳⣄ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On Sat, 9 Mar 2019 18:12:55 +0100, Didier wrote in message <42982bbd-6ccc-6ed4-2bcc-4d969319c...@in2p3.fr>: > I find it comic that dbus, which is a middleware restricted to a > single host, builds a unique id to identify this host. We know that > the systemd team likes to catch up everything to control it from > their blob, even if it looks like pure crap. This makes me think the > intention is probably not surveillance, but lock-in because here is > the core of their busyness model. > > They claim that this isn't UUID (Unix Unique ID). And they are > right even if it matches the acronym, because it is best named > Useless Unique ID. ..so, do we drop that Useless Unique ID scheme from our dbus, or do we drop dbus? ..and, do we help keep Useless Unique ID, Useless, e.g. with cron jobs? -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
I find it comic that dbus, which is a middleware restricted to a single host, builds a unique id to identify this host. We know that the systemd team likes to catch up everything to control it from their blob, even if it looks like pure crap. This makes me think the intention is probably not surveillance, but lock-in because here is the core of their busyness model. They claim that this isn't UUID (Unix Unique ID). And they are right even if it matches the acronym, because it is best named Useless Unique ID. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
Hello > > B) I am more concerned about the other part, where code is > > known to phone home, but the developers or packagers > > have decided that this is fine. The examples range from popcon > > to systemd's resolver (which I am told falls back on to google > > at 8.8.8.8) to chromium or firefox/iceweasel. For the time > > being these designed-in phone home packages are few, so it > > should not be a hardship to label them with a "leaking::" > > tag. > > > > I am sorry marc, but that's incorrect. popcon does not ever 'call > home' in either Debian or Devuan, unless you have *explicitly* agreed > to allow it to do that. And the reasons for popcon "calling-home" are > well stated and fully disclosed: it's a package to collect anonymous > statistics about package usage, and it sends such stats to the popcon > server once a week. popcon submissions are maintained encrypted and > stored only for the time necessary to process them. I can guarantee > this is the case in Devuan, since I am in charge of popcon. Absolutely correct. I included popcon as an example of a package which does disclose system information to others, and the developers and packagers think this is ok. It turns out I think it is ok too, given that it openly discloses what it does, and is opt in. So there should be no objection to having it include a package tag that says it discloses information to others ? Not because popcon is a problem, but because it sets an example to other maintainers to check what information their packages disclose to the outside world ? > systemd is not in Devuan. Chromium comes from Google, and I would > never trust it anyway, notwhitstanding what Google promises to do > about it (but I have not seen the code, so my position might be proven > to be wrong). AFAIK Firefox comes with "calling-home" disabled by > default anyway. I was under the impression that firefox sends a daily report to its servers, but stand corrected. And I too do not know exactly what chromium sends back to its base. Wouldn't it be nice if the .deb files included a few tags to tell us ? > Please do not put everything in the same basket ;) I didn't mean to insinuate that popcon is somehow malicious - I mean to include a range of examples of code which uploads information to remote servers, and that it would be good to have some package-level metadata which tells us what is sent, so that it is more difficult to hide such activity. regards marc ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
Le 09/03/2019 à 17:25, goli...@dyne.org a écrit : On 2019-03-09 03:03, Didier Kryn wrote: Le 09/03/2019 à 09:34, goli...@dyne.org a écrit : I'd recommend adding an inotify rule to record which processes look at these files, and publishing this - here. Unfortunately inotify doesn't tell which process accessed the file )~: ___ I certainly did not write that! (I'm not even sure what inotify is!) LOL! Yep, I know! You just replied to a message of Arnt ( I think) who proposed that, and I (with a big help from thunderbird) messed up the citation (~: But fanotify() is just crafted for this usage; it even asks the watcher if the process which wants to access the file should be given the permission to do it. It would be pretty easy to write a server with a config file mentionning which application is allowed to open the file, and log all accesses. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On 2019-03-09 07:21, Alessandro Selli wrote: On 09/03/19 at 14:04, al3xu5 / dotcommon wrote: my id is 0x007f0101 [...] my id is 0x007f0101 [...] my id is 0x007f0101 using the `hostid` command, I have (Devuan ASCII): $ hostid 007f0101 which is the same value!!! I wonder... is it a "fixed" id for all Devuan installation as it seems to be? And if it is so,is it correct that it is? How intriguing! My ascii VM also has $ hostid 007f0101 I installed using the mini.iso if that makes a difference. golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On Sat, 9 Mar 2019 16:27:10 +0100 Arnt Karlsen wrote: > On Sat, 9 Mar 2019 14:04:13 +0100, al3xu5 wrote in message > <20190309130422.386f8f60...@vm6.ganeti.dyne.org>: > > > > I wonder... is it a "fixed" id for all Devuan installation as it > > seems to be? > > ..yes and no and no etc, I have: > nb6:~# hostid #Devuan Jessie > 007f0101 > sda3:~# hostid #Devuan Ascii > 007f0100 > devuan:~# hostid #Devuan Ascii on rPi-1 > 007f0100 > rir:~# hostid #Raspian Jessie > > devuan@dvn:~$ hostid #Devuan Ascii Live usb > > I get 007f0100 on one jessie, 007f0101 on another jessie and 007f0101 on ascii. (Three different computers) The ascii install is on a laptop that has several installations. When I reboot it into jessie, I get 007f0100. Ceres on that same box gives me 007f0100. fsmithred ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On 2019-03-09 03:03, Didier Kryn wrote: Le 09/03/2019 à 09:34, goli...@dyne.org a écrit : I'd recommend adding an inotify rule to record which processes look at these files, and publishing this - here. Unfortunately inotify doesn't tell which process accessed the file )~: ___ I certainly did not write that! (I'm not even sure what inotify is!) LOL! golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On Sat, Mar 09, 2019 at 02:34:28AM -0600, goli...@dyne.org wrote: > > Oh, my . . . how fast and how hard Debian has fallen . . I am all for > shining light into dark, dank places. What a terrific idea to track > down all the offending packages that are "leaking" information and then > publish an ongoing list of them and how they "phone home". > > golinux Good idea. Just like the evil bit. https://www.ietf.org/rfc/rfc3514.txt -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On Sat, 9 Mar 2019 14:04:13 +0100, al3xu5 wrote in message
<20190309130422.386f8f60...@vm6.ganeti.dyne.org>:
> Il giorno sabato 09/03/2019 13:25:29 +0100
> Alessandro Selli ha scritto:
>
> > [cut]
>
> > > Maybe your system is different to mine, but try compiling the
> > > below and find out for yourself:
> > >
> > > #include
> > > #include
> > >
> > > int main()
> > > {
> > > int id;
> > >
> > > id = gethostid();
> > >
> > > printf("my id is 0x%08x\n", id);
> > >
> > > return 0;
> > > }
> >
> > my id is 0x007f0101
> >
> > [...]
> >
> > my id is 0x007f0101
> >
> > [...]
> >
> > my id is 0x007f0101
> >
>
> using the `hostid` command, I have (Devuan ASCII):
>
> $ hostid
> 007f0101
>
> which is the same value!!!
>
> I wonder... is it a "fixed" id for all Devuan installation as it
> seems to be?
..yes and no and no etc, I have:
nb6:~# hostid #Devuan Jessie
007f0101
sda3:~# hostid #Devuan Ascii
007f0100
devuan:~# hostid #Devuan Ascii on rPi-1
007f0100
rir:~# hostid #Raspian Jessie
devuan@dvn:~$ hostid #Devuan Ascii Live usb
> And if it is so,is it correct that it is?
>
> Regards
>
>
--
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On Sat, Mar 09, 2019 at 02:28:10PM +0100, Antony Stone wrote: [cut] > > > > > > I wonder... is it a "fixed" id for all Devuan installation as it seems to > > > be? > > > > > > And if it is so,is it correct that it is? > > > > How intriguing! > > I get the same value on a Debian Wheezy machine... > As pointed out elsewhere: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/gethostid.c hence, unless any root process has called sethostid, we should all get the same number ;) HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On Saturday 09 March 2019 at 14:21:30, Alessandro Selli wrote: > On 09/03/19 at 14:04, al3xu5 / dotcommon wrote: > >> my id is 0x007f0101 > >> > >> [...] > >> > >> my id is 0x007f0101 > >> > >> [...] > >> > >> my id is 0x007f0101 > > > > using the `hostid` command, I have (Devuan ASCII): > > > > $ hostid > > 007f0101 > > > > which is the same value!!! > > > > I wonder... is it a "fixed" id for all Devuan installation as it seems to > > be? > > > > And if it is so,is it correct that it is? > > How intriguing! I get the same value on a Debian Wheezy machine... Antony. -- I wish you the worst day of your life today. After all, then you know the rest will always be better. Please reply to the list; please *don't* CC me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On 09/03/19 at 14:04, al3xu5 / dotcommon wrote: > >> my id is 0x007f0101 >> >> [...] >> >> my id is 0x007f0101 >> >> [...] >> >> my id is 0x007f0101 >> > using the `hostid` command, I have (Devuan ASCII): > > $ hostid > 007f0101 > > which is the same value!!! > > I wonder... is it a "fixed" id for all Devuan installation as it seems to be? > > And if it is so,is it correct that it is? How intriguing! -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
Il giorno sabato 09/03/2019 13:25:29 +0100
Alessandro Selli ha scritto:
> [cut]
> > Maybe your system is different to mine, but try compiling the below
> > and find out for yourself:
> >
> > #include
> > #include
> >
> > int main()
> > {
> > int id;
> >
> > id = gethostid();
> >
> > printf("my id is 0x%08x\n", id);
> >
> > return 0;
> > }
>
> my id is 0x007f0101
>
> [...]
>
> my id is 0x007f0101
>
> [...]
>
> my id is 0x007f0101
>
using the `hostid` command, I have (Devuan ASCII):
$ hostid
007f0101
which is the same value!!!
I wonder... is it a "fixed" id for all Devuan installation as it seems to be?
And if it is so,is it correct that it is?
Regards
--
al3xu5 / dotcommon
Say NO to copyright, patents, trademarks and any industrial design restrictions.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
Il giorno sabato 09/03/2019 10:54:08 +0100 KatolaZ ha scritto: > On Sat, Mar 09, 2019 at 09:05:20AM +0100, marc wrote: > > [cut] > > > [cut] > > [cut] > > In any case, there are dozens of ways to identify a host and a user > with very good accuracy, even across reboots and even when it travels > through different locations, [...] sure > [...] so the cure is to make sure that no > unwanted usage of this information is made by the software you > run. > And the only guarantee for that is that the code is free and open > source. uhm... unfortunately I would not be so sure about this ... first, because we commonly call "free and open" even programs (and libraries) that are not, and this because "free and open" refers to the license, and the license does not guarantee anything compared to many "social" aspects such as privacy example (an example: the vanilla kernel, which is GPL2, is stuffed with binary blobs ... another example: the LGPL libraries, which can be used together with malicious code); and it does not even guarantee anything about the hardware it runs on ... second, because even if the code "free and open" is inspectable, then it must be done and, in this case for example, that it is also done with respect to privacy ... and I do not think that always happens ... regards -- al3xu5 / dotcommon Say NO to copyright, patents, trademarks and any industrial design restrictions. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On Sat, Mar 09, 2019 at 01:11:31PM +0100, marc wrote: [cut] > > B) I am more concerned about the other part, where code is > known to phone home, but the developers or packagers > have decided that this is fine. The examples range from popcon > to systemd's resolver (which I am told falls back on to google > at 8.8.8.8) to chromium or firefox/iceweasel. For the time > being these designed-in phone home packages are few, so it > should not be a hardship to label them with a "leaking::" > tag. > I am sorry marc, but that's incorrect. popcon does not ever 'call home' in either Debian or Devuan, unless you have *explicitly* agreed to allow it to do that. And the reasons for popcon "calling-home" are well stated and fully disclosed: it's a package to collect anonymous statistics about package usage, and it sends such stats to the popcon server once a week. popcon submissions are maintained encrypted and stored only for the time necessary to process them. I can guarantee this is the case in Devuan, since I am in charge of popcon. Please let us avoid to make confusion with Ubuntu here, which has always had popcon enabled by default, and is another case of a corporation which has all the interests to track their users, to the point of selling that data (and its users) to third-party vendors (see the infamous Amazon app...). systemd is not in Devuan. Chromium comes from Google, and I would never trust it anyway, notwhitstanding what Google promises to do about it (but I have not seen the code, so my position might be proven to be wrong). AFAIK Firefox comes with "calling-home" disabled by default anyway. Please do not put everything in the same basket ;) HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On 09/03/19 at 12:46, marc wrote:
>>> So you are correct that gethostid has been around for a while,
>>> but this call returns a 32bit number, typically the IP.
>> ?? No, it returns a value that's unique to the local machine even if it
>> was not configured on any network.?? Plus, the IP can change, but the
>> hostid is supposed to be static.?? The Unix hostid was developed in order
>> to uniquely identify a machine regardless of where in the Internet it
>> is.?? What you described is the gethostbyname syscall.
> Maybe your system is different to mine, but try compiling the below
> and find out for yourself:
>
> #include
> #include
>
> int main()
> {
> int id;
>
> id = gethostid();
>
> printf("my id is 0x%08x\n", id);
>
> return 0;
> }
my id is 0x007f0101
[root@wkstn05 ~]# ifdown eth0
Killed old client process
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/eth0/00:2e:d5:f6:62:4b
Sending on LPF/eth0/00:2e:d5:f6:62:4b
Sending on Socket/fallback
DHCPRELEASE of 192.168.0.6 on eth0 to 192.168.0.200 port 67
invoke-rc.d: policy-rc.d denied execution of reload.
[root@wkstn05 ~]#
my id is 0x007f0101
[root@wkstn05 ~]# ifup wlan1
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/wlan1/1a:66:81d9:fc:30
Sending on LPF/wlan1/1a:66:81d9:fc:30
Sending on Socket/fallback
Created duid "\000\001\000\001$\036kp\021\322\366\231\345M".
DHCPDISCOVER on wlan1 to 255.255.255.255 port 67 interval 4
DHCPOFFER of 192.168.48.101 from 192.168.48.158
DHCPREQUEST for 192.168.48.101 on wlan1 to 255.255.255.255 port 67
DHCPACK of 192.168.48.101 from 192.168.48.158
invoke-rc.d: policy-rc.d denied execution of reload.
bound to 192.168.48.101 -- renewal in 1626 seconds.
invoke-rc.d: policy-rc.d denied execution of alarm.
[root@wkstn05 ~]#
my id is 0x007f0101
So what? Can't you read man gethostid(3)?
--
Alessandro Selli
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE
signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
> Dear marc, > > unwanted "calls-home" are normally found and disclosed if the software > is free, so I really don't think this is a problem. Asking the > development team of a distribution with 50k+ packages to guarantee > that nothing ever uses user information for unwanted means is just > plain impossible. Not even Debian can do that. This is done, > indirectly, by all the people who look at the code, and contribute to > the packages. So I think that there are two categories to this: A) There may be free software which has been hacked/compromised to covertly to phone home. Finding these cases is hard, but if it is found, chances are excellent that this will be fixed in a hurry. I agree that Debian/Devuan can't make any absolute guarantees in this respect. B) I am more concerned about the other part, where code is known to phone home, but the developers or packagers have decided that this is fine. The examples range from popcon to systemd's resolver (which I am told falls back on to google at 8.8.8.8) to chromium or firefox/iceweasel. For the time being these designed-in phone home packages are few, so it should not be a hardship to label them with a "leaking::" tag. The reason for labelling the ones in category B) is disclosure: Those of us who are concerned about privacy matters can look for those tags to make the tradeoff. It also means that those who want to spy on people without disclosing it fall into category A) which if found out should count as deception and maybe, one day, a crime. regards marc ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
> > So you are correct that gethostid has been around for a while,
> > but this call returns a 32bit number, typically the IP.
>
> ?? No, it returns a value that's unique to the local machine even if it
> was not configured on any network.?? Plus, the IP can change, but the
> hostid is supposed to be static.?? The Unix hostid was developed in order
> to uniquely identify a machine regardless of where in the Internet it
> is.?? What you described is the gethostbyname syscall.
Maybe your system is different to mine, but try compiling the below
and find out for yourself:
#include
#include
int main()
{
int id;
id = gethostid();
printf("my id is 0x%08x\n", id);
return 0;
}
regards
marc
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On Sat, 9 Mar 2019 09:05:20 +0100, marc wrote in message <20190309080520.GA32402@localhost.localdomain>: > So instead of adding crontab rules to obfuscate the ids, ...er, say "to flood them with useless IDs," if you want my agreement. > I'd recommend adding an inotify rule to record which processes > look at these files, and publishing this - here. > > Much has been written about Debian's Social Contract, but > it seems to be ineffective against this type of spying, > whether it involves falling back to 8.8.8.8 as name-server, > or scattering machine ids all over the filesystem. > > I think Devuan has an opportunity to do better - going by > the number of messages in this thread it is an issue which > worries many people. > > A good starting point might be to update the "Tags:" > package field, to include a "leaking::" category. So packages would > not only described as being "implemented-in::c" but also as > "leaking::host-id" or "leaking::clickstream". > > Then one could aim to have a "leak-free" build, like people > try to have a "reproducible build"... -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On Sat, 9 Mar 2019 08:21:18 +0100, Alessandro wrote in message : > On 09/03/19 at 00:28, Arnt Karlsen wrote: > > > ..both valid improvements, me, I might go: " * * * * * root \ > > fortune & |md5sum |cut -d" " -f-1 >/etc/machine-id |tee \ > > >/dev/null 2>&1 " to keep this lightweight in my end and not > > in the other end. :o) > > > The use of fortune as a RNG is telling of the number of gray hair > you must have! ..heh, well, having these 3 letter dogs bark up all trees in the wrong woods, might teach them a few things worth learning. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
Il 09/03/19 11:16, marc ha scritto: >> Mark, I think you are probably shooting the wrong bird here. Host ids >> have been around for the best part of the last 40 years in the unix >> world. And I am not talking about proprietary unix. The syscalls >> gethostid/sethostid were introduced in 4.2BSD (ca. 1983), at Berkeley, >> and are supposed to support unique host ids across all the unix >> installations. The gethostid syscall was even standardised in POSIX. > So you are correct that gethostid has been around for a while, > but this call returns a 32bit number, typically the IP. No, it returns a value that's unique to the local machine even if it was not configured on any network. Plus, the IP can change, but the hostid is supposed to be static. The Unix hostid was developed in order to uniquely identify a machine regardless of where in the Internet it is. What you described is the gethostbyname syscall. -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On Sat, Mar 09, 2019 at 11:16:51AM +0100, marc wrote: [cut] > > I also agree with your sentiment that free and open source > software is necessary to track down information leakage. But it > seems it may be necessary but not sufficient - what one also > needs is a distribution which makes it clear when this information > is disclosed. Sadly it turns out there are also opensource > developers (often corporate) who want to know when and where and by > whom their code is run. The way I think about it is that such code > isn't quite free either - one pays for it in personal data. > Dear marc, unwanted "calls-home" are normally found and disclosed if the software is free, so I really don't think this is a problem. Asking the development team of a distribution with 50k+ packages to guarantee that nothing ever uses user information for unwanted means is just plain impossible. Not even Debian can do that. This is done, indirectly, by all the people who look at the code, and contribute to the packages. If you want a true "secure" system, you should use Linux From Scratch, auditing the code of all the packages you install *before* compiling them, and patch all of them as needed. And then maintain your own DNS servers, disable cookies, javascript, and browser cache, use tor, avoid any clear-text connection, and do not use "free" software developed by the companies who are spearheading the exploitation of user data (yes, I am talking of Google here, and of whatever comes form Google, including the touch keyboard on your smartphones). My2Cents KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
> Mark, I think you are probably shooting the wrong bird here. Host ids > have been around for the best part of the last 40 years in the unix > world. And I am not talking about proprietary unix. The syscalls > gethostid/sethostid were introduced in 4.2BSD (ca. 1983), at Berkeley, > and are supposed to support unique host ids across all the unix > installations. The gethostid syscall was even standardised in POSIX. So you are correct that gethostid has been around for a while, but this call returns a 32bit number, typically the IP. The IP has to be disclosed if one connects to the internet on a public IP, and if you are behind NAT, then vast numbers of systems map to 192.168.1.1 and similar - this really isn't that much of a unique identifier. The new host-id and machine-id files contain a much large number which is less likely to collide, and will be preserved even if one connects from a different networks, and leaves traces for people who want to re-image machines or spin up VMs/containers. I also agree with your sentiment that free and open source software is necessary to track down information leakage. But it seems it may be necessary but not sufficient - what one also needs is a distribution which makes it clear when this information is disclosed. Sadly it turns out there are also opensource developers (often corporate) who want to know when and where and by whom their code is run. The way I think about it is that such code isn't quite free either - one pays for it in personal data. regards marc ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
Il 09/03/19 09:53, Didier Kryn ha scritto: > Le 09/03/2019 à 00:28, Arnt Karlsen a écrit : >> I might go: " * * * * * root \ >> fortune & |md5sum |cut -d" " -f-1 >/etc/machine-id |tee \ >> >/dev/null 2>&1 " to keep this lightweight in my end and not >> in the other end. :o) > > Arnt, Could you be less cryptic please? > > I found fortune in package 9base. The executable is in package fortune-mod, then there are separate packages that install extensions to it's base sentences database. In Beowulf I can find: fortunes fortunes-bofh-excuses fortunes-fr fortunes-it fortunes-it-off fortunes-mario fortunes-min fortunes-off > The idea of hashing a random aphorism is pleasant, but fortune always > displays "Misfortune!" on every invocation, which probably means it > misses a list of aphorisms not part of the package. Yes, you must install a sentences DB: [alessandro@wkstn05 ~]$ fortune What color is a chameleon on a mirror? [alessandro@wkstn05 ~]$ fortune Things are more like they used to be than they are now. [alessandro@wkstn05 ~]$ fortune O tempo é um excelente professor, mas ,infelizmente, mata todos os seus alunos. -- Hector Berlioz [alessandro@wkstn05 ~]$ fortune Avevo un fortune l'altro giorno ma l'ho scordato... [alessandro@wkstn05 ~]$ However, fortune cookie's DB is a poor source of entropy and it shouldn't be relied upon to generate secure passwords or encryption keys. It's allright to generate daily pseudo-random machine ids, though. > Also I don't understand what you mean by " * * * * * root " Man crontab(5) explaines them: Commands are executed by cron(8) when the minute, hour, and month of year fields match the current time, and when at least one of the two day fields (day of month, or day of week) match the current time (see ``Note'' below). cron(8) examines cron entries once every minute. The time and date fields are: field allowed values - -- minute 0-59 hour 0-23 day of month 1-31 month 1-12 (or names, see below) day of week 0-7 (0 or 7 is Sun, or use names) A field may be an asterisk (*), which always stands for ``first-last''. -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On Sat, Mar 09, 2019 at 09:05:20AM +0100, marc wrote: [cut] > > But what really blows me away is that these ids exist on > Debian to begin with. I had been under the assumption that > free systems are built according to the needs and desires > of their users, and few users go "what I really need in this > day and age is less privacy". > Mark, I think you are probably shooting the wrong bird here. Host ids have been around for the best part of the last 40 years in the unix world. And I am not talking about proprietary unix. The syscalls gethostid/sethostid were introduced in 4.2BSD (ca. 1983), at Berkeley, and are supposed to support unique host ids across all the unix installations. The gethostid syscall was even standardised in POSIX. Most of the implementations (including Linux, FreeBSD, NetBSD, etc.) are keeping or have kept the hostid in /etc/hostid or in /var/adm/hostid, and all of them have to respond with something sensible to the gethostid(2) syscall. This has absolutely nothing to do with distributions, unless a distro maintains a separate set of patches to modify the behaviour of the gethostid syscall in the kernel and of the gethostid libc function. In any case, there are dozens of ways to identify a host and a user with very good accuracy, even across reboots and even when it travels through different locations, so the cure is to make sure that no unwanted usage of this information is made by the software you run. And the only guarantee for that is that the code is free and open source. My2Cents KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
> Le 09/03/2019 ?? 10:03, Didier Kryn a ??crit??: > >Le 09/03/2019 ?? 09:34, goli...@dyne.org a ??crit??: > >>I'd recommend adding an inotify rule to record which processes > >>look at these files, and publishing this - here. > > > >Unfortunately inotify doesn't tell which process accessed the file > >)~: > > But fanotify() is perfectly suited (~: Excellent. There are also tricks involving the audit subsystem, maybe fuse and certainly strace (strace -e open). I have checked some of my systems and so far I can see dnsmasq udev dbus systemd-* looking at machine ids. Dnsmasq might warrant a close look - hopefully that id does not get disclosed during dhcp negotiation... The other three in that list I disable whenever possible already, and the above provides yet further confirmation this is prudent. regards marc ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
Anno domini 2019 Sat, 9 Mar 10:03:59 +0100 Didier Kryn scripsit: > Le 09/03/2019 à 09:34, goli...@dyne.org a écrit : > > I'd recommend adding an inotify rule to record which processes > > look at these files, and publishing this - here. > > Unfortunately inotify doesn't tell which process accessed the file )~: If you have a suspect ... strace does. Or a preloaded library, that intercepts open() et al. calls. > > > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
Le 09/03/2019 à 10:03, Didier Kryn a écrit : Le 09/03/2019 à 09:34, goli...@dyne.org a écrit : I'd recommend adding an inotify rule to record which processes look at these files, and publishing this - here. Unfortunately inotify doesn't tell which process accessed the file )~: But fanotify() is perfectly suited (~: Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
Le 09/03/2019 à 09:34, goli...@dyne.org a écrit : I'd recommend adding an inotify rule to record which processes look at these files, and publishing this - here. Unfortunately inotify doesn't tell which process accessed the file )~: ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
Le 09/03/2019 à 00:28, Arnt Karlsen a écrit : I might go: " * * * * * root \ fortune & |md5sum |cut -d" " -f-1 >/etc/machine-id |tee \ >/dev/null 2>&1 " to keep this lightweight in my end and not in the other end. :o) Arnt, Could you be less cryptic please? I found fortune in package 9base. The idea of hashing a random aphorism is pleasant, but fortune always displays "Misfortune!" on every invocation, which probably means it misses a list of aphorisms not part of the package. Also I don't understand what you mean by " * * * * * root " Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On 2019-03-09 02:05, marc wrote: Quoting Arnt Karlsen (a...@iaksess.no): > ..my /etc/cron.d/machine-id: > PATH=/bin:/usr/bin:/sbin:/usr/sbin > > # ..a new /etc/machine-id every minute... ;o) > * * * * * root date |md5sum |cut -d" " -f-1 >/etc/machine-id |tee > >/dev/null 2>&1 _Very_ nice solution. I think I'll steal it whenever I finally need /etc/machine-id . For those who copied that into your crontab: Note that this will leak what timezone you are in to the bad guys (who seem to be the authors of chrome) assuming they have read this thread. And if your clock drifts by more than a few seconds, it might still identify you quite well. Arnt's improvement of adding fortune to md5sums input might be a good plan assuming fortune doesn't do a srand(time()); internally. But what really blows me away is that these ids exist on Debian to begin with. I had been under the assumption that free systems are built according to the needs and desires of their users, and few users go "what I really need in this day and age is less privacy". So instead of adding crontab rules to obfuscate the ids, I'd recommend adding an inotify rule to record which processes look at these files, and publishing this - here. Much has been written about Debian's Social Contract, but it seems to be ineffective against this type of spying, whether it involves falling back to 8.8.8.8 as name-server, or scattering machine ids all over the filesystem. I think Devuan has an opportunity to do better - going by the number of messages in this thread it is an issue which worries many people. A good starting point might be to update the "Tags:" package field, to include a "leaking::" category. So packages would not only described as being "implemented-in::c" but also as "leaking::host-id" or "leaking::clickstream". Then one could aim to have a "leak-free" build, like people try to have a "reproducible build"... regards marc ___ Oh, my . . . how fast and how hard Debian has fallen . . I am all for shining light into dark, dank places. What a terrific idea to track down all the offending packages that are "leaking" information and then publish an ongoing list of them and how they "phone home". golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
> Quoting Arnt Karlsen (a...@iaksess.no): > > > ..my /etc/cron.d/machine-id: > > PATH=/bin:/usr/bin:/sbin:/usr/sbin > > > > # ..a new /etc/machine-id every minute... ;o) > > * * * * * root date |md5sum |cut -d" " -f-1 >/etc/machine-id |tee > > >/dev/null 2>&1 > > _Very_ nice solution. I think I'll steal it whenever I finally need > /etc/machine-id . For those who copied that into your crontab: Note that this will leak what timezone you are in to the bad guys (who seem to be the authors of chrome) assuming they have read this thread. And if your clock drifts by more than a few seconds, it might still identify you quite well. Arnt's improvement of adding fortune to md5sums input might be a good plan assuming fortune doesn't do a srand(time()); internally. But what really blows me away is that these ids exist on Debian to begin with. I had been under the assumption that free systems are built according to the needs and desires of their users, and few users go "what I really need in this day and age is less privacy". So instead of adding crontab rules to obfuscate the ids, I'd recommend adding an inotify rule to record which processes look at these files, and publishing this - here. Much has been written about Debian's Social Contract, but it seems to be ineffective against this type of spying, whether it involves falling back to 8.8.8.8 as name-server, or scattering machine ids all over the filesystem. I think Devuan has an opportunity to do better - going by the number of messages in this thread it is an issue which worries many people. A good starting point might be to update the "Tags:" package field, to include a "leaking::" category. So packages would not only described as being "implemented-in::c" but also as "leaking::host-id" or "leaking::clickstream". Then one could aim to have a "leak-free" build, like people try to have a "reproducible build"... regards marc ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
Hi, On 8/3/19 18:31, . fsmithred via Dng wrote: There's no /etc/machine-id in my beowulf that was an upgrade from refracta ascii or in the beowulf live iso that I just made with live-sdk. Refractasnapshot excludes /var/lib/dbus/machine-id and blanks /etc/machine-id if it's present. Refractainstaller excludes /var/lib/dbus/machine-id and does nothing with /etc/machine-id. Isos made with live-sdk will have /var/lib/dbus/machine-id, and it's the same number every boot unless we remove the file. I just added 'rm -f /var/lib/dbus/machine-id' to blend_finalize() and now the iso has a different machine-id on every boot. If /etc/machine-id is missing, systemd-journald will fail. If the file is empty, it'll get a new number. (That doesn't concern us, but there's code for it in refractasnapshot because people use that on debian with systemd.) fsmithred I'm looking at the generated strapdir in my live-sdk (built on thursday) and i've got the same result: /etc/machine-d is missing and the other file /var/lib/dbus/machine-d is present. Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On 09/03/19 at 00:28, Arnt Karlsen wrote: > On Fri, 8 Mar 2019 22:56:36 +0100, Alessandro wrote in message > <93850f1a-3feb-adc9-1cd0-8ca8736fc...@linux.com>: > >> On 08/03/19 at 18:38, Arnt Karlsen wrote: >>> ..my /etc/cron.d/machine-id: >>> PATH=/bin:/usr/bin:/sbin:/usr/sbin >>> >>> # ..a new /etc/machine-id every minute... ;o) >>> * * * * * root date |md5sum |cut -d" " -f-1 >/etc/machine-id |tee >>> >/dev/null 2>&1 >> >> What is tee doing there? > ..allows logging the generated IDs with e.g. > " |tee >>/var/log/machine-IDs ", some people > might need to do that. I see. I would leave logging to it's specific command, though: echo $RANDOM | md5sum | cut -c 1-32 > /etc/machine-id && logger -p local1.info '/etc/machine randomly regenerated' || logger -p local1.err 'Random regeneration of /etc/machine failed' But this is just a matter of personal choice. > ..both valid improvements, me, I might go: " * * * * * root \ > fortune & |md5sum |cut -d" " -f-1 >/etc/machine-id |tee \ > >/dev/null 2>&1 " to keep this lightweight in my end and not > in the other end. :o) The use of fortune as a RNG is telling of the number of gray hair you must have! -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On Fri, 8 Mar 2019 22:56:36 +0100, Alessandro wrote in message <93850f1a-3feb-adc9-1cd0-8ca8736fc...@linux.com>: > On 08/03/19 at 18:38, Arnt Karlsen wrote: > > > > ..my /etc/cron.d/machine-id: > > PATH=/bin:/usr/bin:/sbin:/usr/sbin > > > > # ..a new /etc/machine-id every minute... ;o) > > * * * * * root date |md5sum |cut -d" " -f-1 >/etc/machine-id |tee > > >/dev/null 2>&1 > > > What is tee doing there? ..allows logging the generated IDs with e.g. " |tee >>/var/log/machine-IDs ", some people might need to do that. > It duplicates it's standard input to each of the files it sees as > parameters, and it has none. > > Plus, it emits it's standard input to it's standard output, which > gets discarded. > > What is the purpose of doing this? > > > I'd just do this instead: > > echo $RANDOM | md5sum | cut -c 1-32 > /etc/machine-id > > > or maybe: > > > dd count=1 if=/dev/urandom 2> /dev/null | md5sum | cut -c 1-32 > > /etc/machine-id ..both valid improvements, me, I might go: " * * * * * root \ fortune & |md5sum |cut -d" " -f-1 >/etc/machine-id |tee \ >/dev/null 2>&1 " to keep this lightweight in my end and not in the other end. :o) -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On 08/03/19 at 18:38, Arnt Karlsen wrote: > > ..my /etc/cron.d/machine-id: > PATH=/bin:/usr/bin:/sbin:/usr/sbin > > # ..a new /etc/machine-id every minute... ;o) > * * * * * root date |md5sum |cut -d" " -f-1 >/etc/machine-id |tee > >/dev/null 2>&1 What is tee doing there? It duplicates it's standard input to each of the files it sees as parameters, and it has none. Plus, it emits it's standard input to it's standard output, which gets discarded. What is the purpose of doing this? I'd just do this instead: echo $RANDOM | md5sum | cut -c 1-32 > /etc/machine-id or maybe: dd count=1 if=/dev/urandom 2> /dev/null | md5sum | cut -c 1-32 > /etc/machine-id -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
KatolaZ wrote on 9/3/19 1:00 am: > On Fri, Mar 08, 2019 at 01:49:20PM +, Mark Hindley wrote: >> On Fri, Mar 08, 2019 at 02:23:20PM +0100, KatolaZ wrote: >>> Jaromil, >>> >>> this is currently managed by eudev in devuan and, IIRC, it is simply >>> regenerated as a random ID at each boot. Apparently, on my beowulf VM, the file /var/lib/dbus/machine-id is created when 'dbus' is installed (r reinstalled), and it's not changed or regenerated at reboot. /etc/machine-id is not present. Ralph. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On Fri, 8 Mar 2019 19:18:10 +0100, KatolaZ wrote in message <20190308181810.7wnfugnqmqtie...@katolaz.homeunix.net>: > anyway: > > - /etc/hostid is defined in POSIX 2001 and POSIX 2008 (man gethostid) > > - /proc/sys/kernel/random/boot_id is randomly generated by the kernel > at each boot (see drivers/char/random.c and kernel/sysctl.c in the > kernel tree) > > - /var/lib/dbus/machine-id is used by dbus, and at the moment seems to > not being re-generated at each boot (my recollection was wrong: we > will fix it) ..do we need /var/lib/dbus/machine-id et al ID files at all? ..if we need them, can we recreate the(se) ID file(s) by e.g. restarting dbus e.g. every minute? ..should we allow e.g. web browsers to read these ID files? ..if we allow e.g. web browsers to read these ID files, do we offer One Devuan ID for Mankind, or do we drown them in an avalance of random machine IDs? > - /etc/machine-id should be used only by systemd components. ..totally agree, but e.g. chromium (ab)uses it: "[20478:20478:0307/101807.205617:ERROR:browser_dm_token_storage_linux.cc(101)] Error: /etc/machine-id contains 0 characters (32 were expected)" ..given their history, I wouldn't be surprised to learn they use any of the other ID files. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
Quoting Arnt Karlsen (a...@iaksess.no): > ..my /etc/cron.d/machine-id: > PATH=/bin:/usr/bin:/sbin:/usr/sbin > > # ..a new /etc/machine-id every minute... ;o) > * * * * * root date |md5sum |cut -d" " -f-1 >/etc/machine-id |tee > >/dev/null 2>&1 _Very_ nice solution. I think I'll steal it whenever I finally need /etc/machine-id . ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
Am Freitag, 8. März 2019 schrieb KatolaZ: > On the other hand, it looks like /etc/machine-id mighr come from > Debian installations "converted" to Devuan, but we should check > whether any of the installer components might have put it there. We > should collect as many reports as possible of things that won't work > if /etc/machine-id does not exist. > > Anybody willing to help with this: if your Devuan installation has a > file /etc/machine-id, could you please move/remove it and report any > application complaining about that, including the version of Devuan > you are using? On my Devuan/ascii machine which I installed May/June 2018 it looks like this: $ ll /var/lib/dbus/machine-id -rw-r--r-- 1 root root 33 2018.05.31 23:45.19 /var/lib/dbus/machine-id $ ll /etc/machine-id ls: cannot access '/etc/machine-id': No such file or directory That was a new install and /etc/machine-id apparently wasn't created, while /var/lib/dbus/machine-id was created at installation time and stayed there like that. I believe but am not 100% sure that I used devuan_ascii_2.0.0-rc_amd64_netinst.iso from May 2018, at least this file has a time stamp from that time. HTH Kind regards, Stefan ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On 2019-03-08 11:50, KatolaZ wrote: On Fri, Mar 08, 2019 at 12:31:55PM -0500, . fsmithred via Dng wrote: On 3/8/19, KatolaZ wrote: > > Then we could probably just ignore it, right? It turns out I was > making confusion between /etc/machine-id and > /car/lib/dbus/machine-id. There is no /etc/machine-id in any of my > machines, either on ascii or on beowulf, and I had forgotten you had > pushed the patch to elogind to use the dbus machine-id instead. > > We should just double-check that the dbus machine-id is regenerated at > reboot, as expected. > There's no /etc/machine-id in my beowulf that was an upgrade from refracta ascii or in the beowulf live iso that I just made with live-sdk. Refractasnapshot excludes /var/lib/dbus/machine-id and blanks /etc/machine-id if it's present. Refractainstaller excludes /var/lib/dbus/machine-id and does nothing with /etc/machine-id. Isos made with live-sdk will have /var/lib/dbus/machine-id, and it's the same number every boot unless we remove the file. I just added 'rm -f /var/lib/dbus/machine-id' to blend_finalize() and now the iso has a different machine-id on every boot. If /etc/machine-id is missing, systemd-journald will fail. If the file is empty, it'll get a new number. (That doesn't concern us, but there's code for it in refractasnapshot because people use that on debian with systemd.) Thanks a lot for the analysis fsmithred. I guess we should open a bug report against dbus to correct the behaviour of the dbus init script (and ensure that /var/lib/dbus/machine-id is regenerated at each boot). On the other hand, it looks like /etc/machine-id mighr come from Debian installations "converted" to Devuan, but we should check whether any of the installer components might have put it there. We should collect as many reports as possible of things that won't work if /etc/machine-id does not exist. Anybody willing to help with this: if your Devuan installation has a file /etc/machine-id, could you please move/remove it and report any application complaining about that, including the version of Devuan you are using? Thanks KatolaZ This thread inspired me to finally upgrade my beowulf in VB. /etc/machine-id is not present after the upgrade. Neither is it present in jessie or ascii in VB. All were clean installs and not migrated from Debian. golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
Rowland: > On Fri, 8 Mar 2019 11:44:49 -0600 > "Jamey Fletcher" wrote: ... > > I have it here on my Gentoo install - and /var/lib/dbus/machine-id is > > a symlink to it. It's basically the same length as a MD5SUM - why > > not just standardize on the MD5SUM of an empty 0-byte file ( > > d41d8cd98f00b204e9800998ecf8427e ) and tell them to take a running > > leap from the ISS? > > Now that's an idea, if they are tracking us, one ID will appear to be > everywhere at once, that should confuse them ;-) No, it tells "them" that you are using e.g. Devuan, and that you are concerned about it for some reason. Depending about how many who is doing so, you might be singled out. If it is for tracking, best is to not to have the infrastructure for this at all, i.e. bug programs that wants it and tell distributions to stop using it. Regards, /Karl Hammar ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On Fri, Mar 08, 2019 at 06:38:32PM +0100, Arnt Karlsen wrote: [cut] > > > > I don't seem to have it and everything works without it. > > > > It's on my beowulf installations, and I didn't even know that it was > > there :-/ > > ..quick starting point: > ll /proc/sys/kernel/random/boot_id /etc/hostid /etc/machine-id \ > /var/lib/dbus/machine-id /var/db/dbus/machine-id > $ ll bash: ll: command not found $ :P anyway: - /etc/hostid is defined in POSIX 2001 and POSIX 2008 (man gethostid) - /proc/sys/kernel/random/boot_id is randomly generated by the kernel at each boot (see drivers/char/random.c and kernel/sysctl.c in the kernel tree) - /var/lib/dbus/machine-id is used by dbus, and at the moment seems to not being re-generated at each boot (my recollection was wrong: we will fix it) - /etc/machine-id should be used only by systemd components. My2Cents KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
Rowland wrote: > On Fri, 8 Mar 2019 11:44:49 -0600 > "Jamey Fletcher" wrote: >> I have it here on my Gentoo install - and /var/lib/dbus/machine-id is >> a symlink to it. It's basically the same length as a MD5SUM - why >> not just standardize on the MD5SUM of an empty 0-byte file ( >> d41d8cd98f00b204e9800998ecf8427e ) and tell them to take a running >> leap from the ISS? > Now that's an idea, if they are tracking us, one ID will appear to be > everywhere at once, that should confuse them ;-) I had, at one point, proposed to a friend that we set up a tool that would, any time a tracking cookie was set by DoubleClick or one of the other tracking companies, upload it to a pool, from which anytime DoubleClick requested said cookie from your machine, it would retrieve one at random and return it, poisoning their database. Probably have to do it with a local proxy server, but seems feasible. (Kinda like the winnow-and-chaff satellite internet service I wanted to propose. You send your data, encrypted, up to the service, and it's all uploaded to the satellite, and broadcast everywhere, along with all of the other data being sent, mixed up randomly. If the other end could decode it, it was for them, everything else was just semi-random noise to make it more difficult for the Nosy Spy Agency to classify and decrypt. Of course, from a few years on, I don't think it would be quite that easy, but ... maybe, with public-key encryption?) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On Fri, 8 Mar 2019 11:44:49 -0600 "Jamey Fletcher" wrote: > > Anno domini 2019 Fri, 8 Mar 10:45:04 -0600 > > > Nate Bargmann scripsit: > > >> * On 2019 08 Mar 08:00 -0600, KatolaZ wrote: > > >>> and, IIRC, also /var/lib/dbus/machine-id is re-generated at boot > >>> time. But we need to double-check. > > >> Not on this Debian Buster machine. Both /var/lib/dbus/machine-id > >> and /etc/machine-id have a date/time consistent with the initial > >> system installation back in October. The machine has been > >> rebooted a number of times since. I've not tried moving either > >> and seeing what happens on the next system restart. > > > Hm ... same here: > > > nik@t61:~$ ll /var/lib/dbus/machine-id > > -rw-r--r-- 1 root root 33 Sep 15 2015 /var/lib/dbus/machine-id > > nik@t61:~$ ll /etc/machine-id > > -r--r--r-- 1 root root 33 Sep 15 2015 /etc/machine-id > > nik@t61:~$ > > > 2015 ... that was jessie, when this computer was set up ... > > I have it here on my Gentoo install - and /var/lib/dbus/machine-id is > a symlink to it. It's basically the same length as a MD5SUM - why > not just standardize on the MD5SUM of an empty 0-byte file ( > d41d8cd98f00b204e9800998ecf8427e ) and tell them to take a running > leap from the ISS? Now that's an idea, if they are tracking us, one ID will appear to be everywhere at once, that should confuse them ;-) Rowland ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On Fri, Mar 08, 2019 at 12:31:55PM -0500, . fsmithred via Dng wrote: > On 3/8/19, KatolaZ wrote: > > > > Then we could probably just ignore it, right? It turns out I was > > making confusion between /etc/machine-id and > > /car/lib/dbus/machine-id. There is no /etc/machine-id in any of my > > machines, either on ascii or on beowulf, and I had forgotten you had > > pushed the patch to elogind to use the dbus machine-id instead. > > > > We should just double-check that the dbus machine-id is regenerated at > > reboot, as expected. > > > > There's no /etc/machine-id in my beowulf that was an upgrade from > refracta ascii or in the beowulf live iso that I just made with > live-sdk. > > Refractasnapshot excludes /var/lib/dbus/machine-id and blanks > /etc/machine-id if it's present. > > Refractainstaller excludes /var/lib/dbus/machine-id and does nothing > with /etc/machine-id. > > Isos made with live-sdk will have /var/lib/dbus/machine-id, and it's > the same number every boot unless we remove the file. I just added 'rm > -f /var/lib/dbus/machine-id' to blend_finalize() and now the iso has a > different machine-id on every boot. > > If /etc/machine-id is missing, systemd-journald will fail. If the file > is empty, it'll get a new number. (That doesn't concern us, but > there's code for it in refractasnapshot because people use that on > debian with systemd.) > Thanks a lot for the analysis fsmithred. I guess we should open a bug report against dbus to correct the behaviour of the dbus init script (and ensure that /var/lib/dbus/machine-id is regenerated at each boot). On the other hand, it looks like /etc/machine-id mighr come from Debian installations "converted" to Devuan, but we should check whether any of the installer components might have put it there. We should collect as many reports as possible of things that won't work if /etc/machine-id does not exist. Anybody willing to help with this: if your Devuan installation has a file /etc/machine-id, could you please move/remove it and report any application complaining about that, including the version of Devuan you are using? Thanks KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On Fri, Mar 08, 2019 at 11:44:49AM -0600, Jamey Fletcher wrote: > >> Not on this Debian Buster machine. Both /var/lib/dbus/machine-id and > >> /etc/machine-id have a date/time consistent with the initial system > >> installation back in October. The machine has been rebooted a number of > >> times since. I've not tried moving either and seeing what happens on > >> the next system restart. > I have it here on my Gentoo install - and /var/lib/dbus/machine-id is a > symlink to it. It's basically the same length as a MD5SUM - why not just > standardize on the MD5SUM of an empty 0-byte file ( > d41d8cd98f00b204e9800998ecf8427e ) and tell them to take a running leap > from the ISS? This. Let's give all that software a machine-id, and make it _consistent_! In other words, I am Spartacus. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour? ⠈⠳⣄ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
> Anno domini 2019 Fri, 8 Mar 10:45:04 -0600 > Nate Bargmann scripsit: >> * On 2019 08 Mar 08:00 -0600, KatolaZ wrote: >>> and, IIRC, also /var/lib/dbus/machine-id is re-generated at boot >>> time. But we need to double-check. >> Not on this Debian Buster machine. Both /var/lib/dbus/machine-id and >> /etc/machine-id have a date/time consistent with the initial system >> installation back in October. The machine has been rebooted a number of >> times since. I've not tried moving either and seeing what happens on >> the next system restart. > Hm ... same here: > nik@t61:~$ ll /var/lib/dbus/machine-id > -rw-r--r-- 1 root root 33 Sep 15 2015 /var/lib/dbus/machine-id > nik@t61:~$ ll /etc/machine-id > -r--r--r-- 1 root root 33 Sep 15 2015 /etc/machine-id > nik@t61:~$ > 2015 ... that was jessie, when this computer was set up ... I have it here on my Gentoo install - and /var/lib/dbus/machine-id is a symlink to it. It's basically the same length as a MD5SUM - why not just standardize on the MD5SUM of an empty 0-byte file ( d41d8cd98f00b204e9800998ecf8427e ) and tell them to take a running leap from the ISS? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On Fri, 8 Mar 2019 15:46:26 +0100, Dr. wrote in message <201903081546.27040.dr.kl...@gmx.at>: > Anno domini 2019 Fri, 8 Mar 13:15:48 + > Rowland Penny via Dng scripsit: > > On Fri, 8 Mar 2019 13:47:40 +0100 > > Jaromil wrote: > > > > > > > > re all, > > > > > > any thoughts about this new systemd-made thing that freedesktop > > > immediately "standardized" (whatever is their procedure for that, > > > likely smoking cigars among old-boys or so) > > > https://www.freedesktop.org/software/systemd/man/machine-id.html > > > > > > its easy to replace by a script of course that's not the problem > > > (the manpage suggests to use a systemd application for that, not > > > a joke!) but I'm curious if anyone has some background and > > > thoughts about this > > > > > > AFAIK chromium started checking it and its absence on Devuan > > > Beowulf is reported as an error, so we may have to work around > > > this. > > > > > > but first things first: do we want /etc/machine-id? and how? > > > > > > > I would have thought the first question is 'What is it used for ?' > > Surveillance, nothing else. IMO it would be nice to regenerate it > every time the file is read. ..my /etc/cron.d/machine-id: PATH=/bin:/usr/bin:/sbin:/usr/sbin # ..a new /etc/machine-id every minute... ;o) * * * * * root date |md5sum |cut -d" " -f-1 >/etc/machine-id |tee >/dev/null 2>&1 ...keeps e.g. chromium from whining about: "[20478:20478:0307/101807.205617:ERROR:browser_dm_token_storage_linux.cc(101)] Error: /etc/machine-id contains 0 characters (32 were expected)" ..dunno too much about what else they use to track us though... ..those nefarious web browsers should run _only_once_, between the boot-up of the throw-away virtual machine it lives in, and the shut down and the throwing away of that throw-away virtual machine it lived in. > > I don't seem to have it and everything works without it. > > It's on my beowulf installations, and I didn't even know that it was > there :-/ ..quick starting point: ll /proc/sys/kernel/random/boot_id /etc/hostid /etc/machine-id \ /var/lib/dbus/machine-id /var/db/dbus/machine-id -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On 3/8/19, KatolaZ wrote: > > Then we could probably just ignore it, right? It turns out I was > making confusion between /etc/machine-id and > /car/lib/dbus/machine-id. There is no /etc/machine-id in any of my > machines, either on ascii or on beowulf, and I had forgotten you had > pushed the patch to elogind to use the dbus machine-id instead. > > We should just double-check that the dbus machine-id is regenerated at > reboot, as expected. > There's no /etc/machine-id in my beowulf that was an upgrade from refracta ascii or in the beowulf live iso that I just made with live-sdk. Refractasnapshot excludes /var/lib/dbus/machine-id and blanks /etc/machine-id if it's present. Refractainstaller excludes /var/lib/dbus/machine-id and does nothing with /etc/machine-id. Isos made with live-sdk will have /var/lib/dbus/machine-id, and it's the same number every boot unless we remove the file. I just added 'rm -f /var/lib/dbus/machine-id' to blend_finalize() and now the iso has a different machine-id on every boot. If /etc/machine-id is missing, systemd-journald will fail. If the file is empty, it'll get a new number. (That doesn't concern us, but there's code for it in refractasnapshot because people use that on debian with systemd.) fsmithred ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
Anno domini 2019 Fri, 8 Mar 10:45:04 -0600 Nate Bargmann scripsit: > * On 2019 08 Mar 08:00 -0600, KatolaZ wrote: > > and, IIRC, also /var/lib/dbus/machine-id is re-generated at boot > > time. But we need to double-check. > > Not on this Debian Buster machine. Both /var/lib/dbus/machine-id and > /etc/machine-id have a date/time consistent with the initial system > installation back in October. The machine has been rebooted a number of > times since. I've not tried moving either and seeing what happens on > the next system restart. > > - Nate > Hm ... same here: nik@t61:~$ ll /var/lib/dbus/machine-id -rw-r--r-- 1 root root 33 Sep 15 2015 /var/lib/dbus/machine-id nik@t61:~$ ll /etc/machine-id -r--r--r-- 1 root root 33 Sep 15 2015 /etc/machine-id nik@t61:~$ 2015 ... that was jessie, when this computer was set up ... Nik -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
* On 2019 08 Mar 08:00 -0600, KatolaZ wrote: > and, IIRC, also /var/lib/dbus/machine-id is re-generated at boot > time. But we need to double-check. Not on this Debian Buster machine. Both /var/lib/dbus/machine-id and /etc/machine-id have a date/time consistent with the initial system installation back in October. The machine has been rebooted a number of times since. I've not tried moving either and seeing what happens on the next system restart. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: http://www.n0nb.us GPG key: D55A8819 GitHub: N0NB signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On Fri, Mar 08, 2019 at 02:08:39PM +, Mark Hindley wrote: > On Fri, Mar 08, 2019 at 03:00:31PM +0100, KatolaZ wrote: > > > Yes, elogind uses it. But I got upstream to take a patch which uses > > > /var/lib/dbus/machine-id as an alternative to /etc/machine-id. > > > > > > > and, IIRC, also /var/lib/dbus/machine-id is re-generated at boot > > time. But we need to double-check. > > Yes, but only if it is missing, so eg if /var/ is tmpfs or you arrange to > clear > it. > > /var/lib/dbus/machine-id is generated by a dbus-uuidgen(1) call in the dbus > initscript. This doesn't overwrite an existing file so that the machine-id is > not changed during a single uptime. > > Certainly elogind has no requirement for /etc/machine-id to be present or > consistent between boots. Then we could probably just ignore it, right? It turns out I was making confusion between /etc/machine-id and /car/lib/dbus/machine-id. There is no /etc/machine-id in any of my machines, either on ascii or on beowulf, and I had forgotten you had pushed the patch to elogind to use the dbus machine-id instead. We should just double-check that the dbus machine-id is regenerated at reboot, as expected. HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
Anno domini 2019 Fri, 8 Mar 13:15:48 + Rowland Penny via Dng scripsit: > On Fri, 8 Mar 2019 13:47:40 +0100 > Jaromil wrote: > > > > > re all, > > > > any thoughts about this new systemd-made thing that freedesktop > > immediately "standardized" (whatever is their procedure for that, > > likely smoking cigars among old-boys or so) > > https://www.freedesktop.org/software/systemd/man/machine-id.html > > > > its easy to replace by a script of course that's not the problem (the > > manpage suggests to use a systemd application for that, not a joke!) > > but I'm curious if anyone has some background and thoughts about this > > > > AFAIK chromium started checking it and its absence on Devuan Beowulf > > is reported as an error, so we may have to work around this. > > > > but first things first: do we want /etc/machine-id? and how? > > > > I would have thought the first question is 'What is it used for ?' Surveillance, nothing else. IMO it would be nice to regenerate it every time the file is read. > I don't seem to have it and everything works without it. It's on my beowulf installations, and I didn't even know that it was there :-/ Nik > > Rowland > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On Fri, Mar 08, 2019 at 02:23:20PM +0100, KatolaZ wrote: > Jaromil, > > this is currently managed by eudev in devuan and, IIRC, it is simply > regenerated as a random ID at each boot. I guess it's still there > because it is used by several things, including > session-management-related stuff. We had a discussion on IRC with Mark > (LeePen) about that several weeks ago, and IIRC we concluded that > keeping it around but re-generating it at boot was the way to avoid > breakage. Yes, elogind uses it. But I got upstream to take a patch which uses /var/lib/dbus/machine-id as an alternative to /etc/machine-id. Mark ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On Fri, Mar 08, 2019 at 03:00:31PM +0100, KatolaZ wrote: > > Yes, elogind uses it. But I got upstream to take a patch which uses > > /var/lib/dbus/machine-id as an alternative to /etc/machine-id. > > > > and, IIRC, also /var/lib/dbus/machine-id is re-generated at boot > time. But we need to double-check. Yes, but only if it is missing, so eg if /var/ is tmpfs or you arrange to clear it. /var/lib/dbus/machine-id is generated by a dbus-uuidgen(1) call in the dbus initscript. This doesn't overwrite an existing file so that the machine-id is not changed during a single uptime. Certainly elogind has no requirement for /etc/machine-id to be present or consistent between boots. Mark ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On 08-03-19 14:23, KatolaZ wrote: > On Fri, Mar 08, 2019 at 01:47:40PM +0100, Jaromil wrote: >> re all, >> >> any thoughts about this new systemd-made thing that freedesktop >> immediately "standardized" (whatever is their procedure for that, >> likely smoking cigars among old-boys or so) >> https://www.freedesktop.org/software/systemd/man/machine-id.html >> >> its easy to replace by a script of course that's not the problem (the >> manpage suggests to use a systemd application for that, not a joke!) >> but I'm curious if anyone has some background and thoughts about this >> >> AFAIK chromium started checking it and its absence on Devuan Beowulf >> is reported as an error, so we may have to work around this. >> >> but first things first: do we want /etc/machine-id? and how? >> > Jaromil, > > this is currently managed by eudev in devuan and, IIRC, it is simply > regenerated as a random ID at each boot. I guess it's still there > because it is used by several things, including > session-management-related stuff. We had a discussion on IRC with Mark > (LeePen) about that several weeks ago, and IIRC we concluded that > keeping it around but re-generating it at boot was the way to avoid > breakage. > > Any thoughts on the matter are appreciated, but concrete insight on > the ins and outs are much more useful I guess (read: please let's > avoid a useless uninformed flame about that :P). > > My2Cents > > KatolaZ > I opened the link and read: - that it should replace the POSIX gethostid(3) call, - that it should be unique, - should be confidential - and last but not least it is supplemental to D-Bus machine ID. /var/lib/dbus/machine-id could even be a symlink to /etc/machine-id Besides the possibility to network boot with the systemd.machine_id= kernel commandline i do not see any advantage to user of systemadministrator. I do see the possibilities to abuse it and the only reason for existing i can think of is DRM or surveillance. If this is flaming, so be it. Grtz. Nick signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On Fri, Mar 08, 2019 at 01:49:20PM +, Mark Hindley wrote: > On Fri, Mar 08, 2019 at 02:23:20PM +0100, KatolaZ wrote: > > Jaromil, > > > > this is currently managed by eudev in devuan and, IIRC, it is simply > > regenerated as a random ID at each boot. I guess it's still there > > because it is used by several things, including > > session-management-related stuff. We had a discussion on IRC with Mark > > (LeePen) about that several weeks ago, and IIRC we concluded that > > keeping it around but re-generating it at boot was the way to avoid > > breakage. > > Yes, elogind uses it. But I got upstream to take a patch which uses > /var/lib/dbus/machine-id as an alternative to /etc/machine-id. > and, IIRC, also /var/lib/dbus/machine-id is re-generated at boot time. But we need to double-check. Thanks Mark KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
Jaromil: > any thoughts about this new systemd-made thing that freedesktop > immediately "standardized" (whatever is their procedure for that, > likely smoking cigars among old-boys or so) > https://www.freedesktop.org/software/systemd/man/machine-id.html ... . It doesn't say "why". Why should I (we) provide a means to uniquely identify my systems ? I don't need it. Is it for - the nice though not useful concept, yes we reinvent things you know - the ongoing trend for more surveillance from the authorities - the ongoing trend for more surveillance from the advertising firms - the ongoing trend for more surveillance for "copyright" reason . It says "This ID uniquely identifies the host." - on the lan I can just as well use hostname or the primary ip-number - on the internet I use the fqdn or the ip-number The uniqness part will fail without someone guarantying the uniqness. Do we have an "IEEE handling out oui's" - for machine-id's ? Even if there were some IEEE, pci- or usb-consortium handling out vendor parts of the id's, there is no guaranty for uniqness since that number is just what's the local admin fancies, or is it for "tamperproof" hardware, something oppressive regimes would like. And I have seen pci cards with the wrong vendor part: "the programmer left and we don't have the code so we cannot change it" as the vendor put it. > AFAIK chromium started checking it and its absence on Devuan Beowulf > is reported as an error, so we may have to work around this. Isn't that a bug, the above man page says: It should be considered "confidential", and must not be exposed in untrusted environments, in particular on the network. Why would a network centric program need this unless it wants to expose it ? > but first things first: do we want /etc/machine-id? and how? In my view it falls in the completely unnessesary or the potentially dangerous group. I don't want it. Regards, /Karl Hammar ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On Fri, Mar 08, 2019 at 02:23:20PM +0100, KatolaZ wrote: > > but first things first: do we want /etc/machine-id? and how? > this is currently managed by eudev in devuan and, IIRC, it is simply > regenerated as a random ID at each boot. > we concluded that keeping it around but re-generating it at boot was the > way to avoid breakage. And I say you're 100% right here. The machine-id: * is a privacy issue * gets broken when cloned systems are involved but defusing it by re-generating every boot works around both of the above while requiring no patches to affected software. > Any thoughts on the matter are appreciated, but concrete insight on > the ins and outs are much more useful I guess (read: please let's > avoid a useless uninformed flame about that :P). Be realistic... avoiding an uninformed flame would be against our rules :) Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour? ⠈⠳⣄ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On Fri, Mar 08, 2019 at 01:47:40PM +0100, Jaromil wrote: > > re all, > > any thoughts about this new systemd-made thing that freedesktop > immediately "standardized" (whatever is their procedure for that, > likely smoking cigars among old-boys or so) > https://www.freedesktop.org/software/systemd/man/machine-id.html > > its easy to replace by a script of course that's not the problem (the > manpage suggests to use a systemd application for that, not a joke!) > but I'm curious if anyone has some background and thoughts about this > > AFAIK chromium started checking it and its absence on Devuan Beowulf > is reported as an error, so we may have to work around this. > > but first things first: do we want /etc/machine-id? and how? > Jaromil, this is currently managed by eudev in devuan and, IIRC, it is simply regenerated as a random ID at each boot. I guess it's still there because it is used by several things, including session-management-related stuff. We had a discussion on IRC with Mark (LeePen) about that several weeks ago, and IIRC we concluded that keeping it around but re-generating it at boot was the way to avoid breakage. Any thoughts on the matter are appreciated, but concrete insight on the ins and outs are much more useful I guess (read: please let's avoid a useless uninformed flame about that :P). My2Cents KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
On Fri, 8 Mar 2019 13:47:40 +0100 Jaromil wrote: > > re all, > > any thoughts about this new systemd-made thing that freedesktop > immediately "standardized" (whatever is their procedure for that, > likely smoking cigars among old-boys or so) > https://www.freedesktop.org/software/systemd/man/machine-id.html > > its easy to replace by a script of course that's not the problem (the > manpage suggests to use a systemd application for that, not a joke!) > but I'm curious if anyone has some background and thoughts about this > > AFAIK chromium started checking it and its absence on Devuan Beowulf > is reported as an error, so we may have to work around this. > > but first things first: do we want /etc/machine-id? and how? > I would have thought the first question is 'What is it used for ?' I don't seem to have it and everything works without it. Rowland ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] new freedesktop "standard": /etc/machine-id
re all, any thoughts about this new systemd-made thing that freedesktop immediately "standardized" (whatever is their procedure for that, likely smoking cigars among old-boys or so) https://www.freedesktop.org/software/systemd/man/machine-id.html its easy to replace by a script of course that's not the problem (the manpage suggests to use a systemd application for that, not a joke!) but I'm curious if anyone has some background and thoughts about this AFAIK chromium started checking it and its absence on Devuan Beowulf is reported as an error, so we may have to work around this. but first things first: do we want /etc/machine-id? and how? ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
