Re: New service: https://debuginfod.debian.net
On Sat, 2021-02-27 at 17:30 -0500, Sergio Durigan Junior wrote: > I don't know if I understand the pushback I'm seeing > against using a debconf question for this. FWIW I don't think I've read any actual pushback on that in this thread although I can see how it might appear that way to another reader. I took it as people offering possible alternatives or future extensions -- certainly that was my intention once the intent to have a debconf question was clear (which I tried to clarify but perhaps failed at). When I said earlier "So long as it is opt-in at the gross level" I was referring to the debconf being sufficient. I think (and I have inferred that you think) the need for discussion of alternatives or future improvements isn't especially productive at the current time so I won't prolong that aspect of the thread by replying to the rest of your mail (let me know if I'm wrong and you'd like a reply). Cheers, Ian
Re: New service: https://debuginfod.debian.net
On Saturday, February 27 2021, Paul Wise wrote: > On Sat, Feb 27, 2021 at 10:31 PM Sergio Durigan Junior wrote: > >> Anyway, as I said before, I don't intend to work on this specific idea >> right away, and I don't know if I understand the pushback I'm seeing >> against using a debconf question for this. It seems to me that this is >> exactly why debconf exists (see the popcon package), and it already has >> a cache for the answer. > > I assume folks are wanting a per-user consent to download from > debuginfod services instead of or in addition to the per-system > consent being proposed to add via debconf. Right, that's what I assumed. I agree with this point, by the way. But since it isn't implemented, I think the debconf question is the next best thing we can do. -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/
Re: New service: https://debuginfod.debian.net
On Sat, Feb 27, 2021 at 10:31 PM Sergio Durigan Junior wrote: > Anyway, as I said before, I don't intend to work on this specific idea > right away, and I don't know if I understand the pushback I'm seeing > against using a debconf question for this. It seems to me that this is > exactly why debconf exists (see the popcon package), and it already has > a cache for the answer. I assume folks are wanting a per-user consent to download from debuginfod services instead of or in addition to the per-system consent being proposed to add via debconf. -- bye, pabs https://wiki.debian.org/PaulWise
Re: New service: https://debuginfod.debian.net
On Saturday, February 27 2021, Ian Campbell wrote: > On Sat, 2021-02-27 at 11:21 -0500, Sergio Durigan Junior wrote: >> On Saturday, February 27 2021, Ian Campbell wrote: >> > >> > FWIW that would be my personal preference too (probably with some sort >> > of cache, maybe once per library or executable or some granularity like >> > that)... >> >> BTW, libdebuginfod (which is the library that performs the download from >> the client side) does keep a cache of what's been downloaded, so that >> part at least has been addressed. > > That's good, of course, but I was talking about a cache of the user > opt-in responses rather than asking for permission literally every time > something needed downloading. Let me first clarify that it's libdebuginfod (from elfutils) that does the heavy work of downloading the files here. If you're suggesting that the each client that links against libdebuginfod (like GDB) should first ask the user whether she wants to download things from a debuginfod server, then OK. If you're suggesting that the client (e.g. GDB) should ask the user permission before downloading the debuginfo for each library/application, then I disagree. This would obviously bother the user with a lot of questions and make the experience far from pleasant. But I'm assuming that's not what you're suggesting. Anyway, as I said before, I don't intend to work on this specific idea right away, and I don't know if I understand the pushback I'm seeing against using a debconf question for this. It seems to me that this is exactly why debconf exists (see the popcon package), and it already has a cache for the answer. I'm planning to update my MR to elfutils this weekend. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/
Re: New service: https://debuginfod.debian.net
On Sat, 2021-02-27 at 11:21 -0500, Sergio Durigan Junior wrote: > On Saturday, February 27 2021, Ian Campbell wrote: > > > > FWIW that would be my personal preference too (probably with some sort > > of cache, maybe once per library or executable or some granularity like > > that)... > > BTW, libdebuginfod (which is the library that performs the download from > the client side) does keep a cache of what's been downloaded, so that > part at least has been addressed. That's good, of course, but I was talking about a cache of the user opt-in responses rather than asking for permission literally every time something needed downloading. Ian.
Re: New service: https://debuginfod.debian.net
On Saturday, February 27 2021, Ian Campbell wrote: > On Sat, 2021-02-27 at 11:47 +0100, Kurt Roeckx wrote: > On Thu, Feb 25, 2021 at 03:55:17PM -0500, Sergio Durigan Junior wrote: >> As I said in the announcement message, I have proposed a Merge >> Request >> against elfutils in order to enable the automatic usage of our >> debuginfod server. I know that there are people who are not >> comfortable >> with having a debugger consult a remote server "behind their backs", >> so >> a possible mitigation to this issue would be to have a debconf >> question >> asking whether the user wants to enable system-wide debuginfod usage >> or >> not. > > The other option is that the application asks before downloading > each time. > > FWIW that would be my personal preference too (probably with some sort > of cache, maybe once per library or executable or some granularity like > that) but since I don't plan on working on anything like that myself > and it seems like a awful lot of quite complex work I wouldn't want to > try and insist (even if I had grounds too, which I'm sure I don't) > someone else does that amount of work, so long as it is opt-in at the > gross level. I appreciate the opinions here. I agree that it would be nice to have the application ask for permission, and I can try to work with upstream in order to get this done, but for now I will go with the debconf opt-in alternative. BTW, libdebuginfod (which is the library that performs the download from the client side) does keep a cache of what's been downloaded, so that part at least has been addressed. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/
Re: Unsolicited internet access in default installs (was: New service: https://debuginfod.debian.net)
Quoting Johannes Schauer Marin Rodrigues (2021-02-27 15:24:52) > Quoting Steinar H. Gunderson (2021-02-27 13:46:27) > > On Sat, Feb 27, 2021 at 12:29:34PM +, Thaddeus H. Black wrote: > > > I would prefer Kurt's option. Network silence is important. > > > Network noise would probably be a bug. A sysadmin should not be > > > made to take special precautions to avoid the inadvertent > > > disclosure of the user's presence on the network. > > > > It's 2021; machines are not silent on the network. That ship sailed > > long ago. > > I was about to write a rant, stating that it's unacceptable for any > requests to remote servers to be made by a Debian default installation > without my explicit consent. So I ran: > > qemu-system-x86_64 -enable-kvm -m 2G -netdev user,id=u1 -device > e1000,netdev=u1 -object filter-dump,id=f1,netdev=u1,file=install.pcap -cdrom > debian-testing-amd64-DVD-1.iso -hdd disk.img Neat! Now added to https://wiki.debian.org/PrivacyIssues#Detection_tools Thanks, Johannes. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Unsolicited internet access in default installs (was: New service: https://debuginfod.debian.net)
On Sat, Feb 27, 2021 at 03:24:52PM +0100, Johannes Schauer Marin Rodrigues wrote: > No idea why we are still asking whether popcon should be enabled or not > because > apparently it's 2021 and it's okay to tell others out there that I just > installed Debian. This is a strawman, though. popcon contains a persistent identifier; a random HTTP request will not. Furthermore, your machine will send out and answer various ICMP traffic, mDNS stuff, multicast groups, CIFS name queries, etc. etc. etc. on whatever local network it's connecting to. It's completely fine to limit the amount of personal data we are divulging for no good reason, but machines don't live in network silence. debuginfod is a genuinely useful service, will leak much less information about what you've got installed than apt already does, and we should not just block its use based on such a (non-)goal. That being said, I would assume the logical thing to do is that gdb asks the first time, and then remembers your choice. /* Steinar */ -- Homepage: https://www.sesse.net/
Unsolicited internet access in default installs (was: New service: https://debuginfod.debian.net)
Quoting Steinar H. Gunderson (2021-02-27 13:46:27) > On Sat, Feb 27, 2021 at 12:29:34PM +, Thaddeus H. Black wrote: > > I would prefer Kurt's option. Network silence is important. Network > > noise would probably be a bug. A sysadmin should not be made to take > > special precautions to avoid the inadvertent disclosure of the user's > > presence on the network. > > It's 2021; machines are not silent on the network. That ship sailed long ago. I was about to write a rant, stating that it's unacceptable for any requests to remote servers to be made by a Debian default installation without my explicit consent. So I ran: qemu-system-x86_64 -enable-kvm -m 2G -netdev user,id=u1 -device e1000,netdev=u1 -object filter-dump,id=f1,netdev=u1,file=install.pcap -cdrom debian-testing-amd64-DVD-1.iso -hdd disk.img And found out that I was wrong and you are right. Even though I answered "No" to all questions related to mirrors and popcon during the installation, the above command still recorded a DNS query for debian.map.fastlydns.net and a subsequent download of /debian-security/dists/bullseye-security/InRelease. Later on, after the installation had finished and gnome started, I see requests to cdn.fwupd.org where something got downloaded from and then some communication with 0.debian.pool.ntp.org. No idea why we are still asking whether popcon should be enabled or not because apparently it's 2021 and it's okay to tell others out there that I just installed Debian. signature.asc Description: signature
Re: New service: https://debuginfod.debian.net
On Sat, 2021-02-27 at 11:47 +0100, Kurt Roeckx wrote: On Thu, Feb 25, 2021 at 03:55:17PM -0500, Sergio Durigan Junior wrote: > As I said in the announcement message, I have proposed a Merge > Request > against elfutils in order to enable the automatic usage of our > debuginfod server. I know that there are people who are not > comfortable > with having a debugger consult a remote server "behind their backs", > so > a possible mitigation to this issue would be to have a debconf > question > asking whether the user wants to enable system-wide debuginfod usage > or > not. The other option is that the application asks before downloading each time. FWIW that would be my personal preference too (probably with some sort of cache, maybe once per library or executable or some granularity like that) but since I don't plan on working on anything like that myself and it seems like a awful lot of quite complex work I wouldn't want to try and insist (even if I had grounds too, which I'm sure I don't) someone else does that amount of work, so long as it is opt-in at the gross level. Ian.
Re: New service: https://debuginfod.debian.net
On Sat, Feb 27, 2021 at 12:29:34PM +, Thaddeus H. Black wrote: > I would prefer Kurt's option. Network silence is important. Network > noise would probably be a bug. A sysadmin should not be made to take > special precautions to avoid the inadvertent disclosure of the user's > presence on the network. It's 2021; machines are not silent on the network. That ship sailed long ago. /* Steinar */ -- Homepage: https://www.sesse.net/
Re: New service: https://debuginfod.debian.net
Thanks for consulting us, Sergio, before proceeding. On Sat, Feb 27, 2021 at 11:47:40AM +0100, Kurt Roeckx wrote: > On Thu, Feb 25, 2021 at 03:55:17PM -0500, Sergio Durigan Junior wrote: > > As I said in the announcement message, I have proposed a Merge Request > > against elfutils in order to enable the automatic usage of our > > debuginfod server. I know that there are people who are not comfortable > > with having a debugger consult a remote server "behind their backs", so > > a possible mitigation to this issue would be to have a debconf question > > asking whether the user wants to enable system-wide debuginfod usage or > > not. > > The other option is that the application asks before downloading > each time. I would prefer Kurt's option. Network silence is important. Network noise would probably be a bug. A sysadmin should not be made to take special precautions to avoid the inadvertent disclosure of the user's presence on the network. This question is an overall question of clean operating-system design: concerns are to be separated. Debugging and networking are separate spheres of administration. To conflate the two would probably be an error. As far as debconf goes, the fewer questions, the better. signature.asc Description: PGP signature
Re: New service: https://debuginfod.debian.net
On Thu, Feb 25, 2021 at 03:55:17PM -0500, Sergio Durigan Junior wrote: > As I said in the announcement message, I have proposed a Merge Request > against elfutils in order to enable the automatic usage of our > debuginfod server. I know that there are people who are not comfortable > with having a debugger consult a remote server "behind their backs", so > a possible mitigation to this issue would be to have a debconf question > asking whether the user wants to enable system-wide debuginfod usage or > not. The other option is that the application asks before downloading each time. Kurt
Re: New service: https://debuginfod.debian.net
Quoting Ian Campbell (2021-02-24 18:50:39)
> What are the security implications for users/clients of using this or more
> importantly enabling it by default?
>
> Presumably clients have to trust that the server is not going to feed
> them malicious debug info. Are the tools which consume this information
> written to operate on completely untrusted inputs? It seems like many
> of them could have been written historically with the assumption that
> their inputs are mostly to be trusted. I suppose the use https helps
> mitigate this at least a bit when it comes to a debian.{org,net}
> service.
>
> What about information leakage? apart from debugids does this leak
> anything else to the server? On a quick look it seems like it might
> potentially leak source code paths (at least the leaf bits) to things
> being debugged -- does this mean that if a user is debugging private
> software (perhaps unpublished or perhaps proprietary software for
> $work) on a Debian system they are at risk of leaking the source
> filenames if they run gdb on one of their binaries while debugging? This
> might be a problem if it comes to enabling this transparently.
This sounds like it should be treated in a similar way as we treat submissions
to popcon.debian.org where we ask the user explicitly and which is not getting
enabled unless with explicit consent by the user.
Thanks!
cheers, josch
signature.asc
Description: signature
