One of the suggestions/complaints I got when we discussed Debian's debuginfod service on debian-devel was that the debuginfod client should inform the user before downloading the first file and ask for her consent before proceeding. I'm not a debuginfod hacker, but I think this would probably require some sort of permanent file (under ~/.config/, maybe?) where the decision can be stored, and some way to allow the user to easily change this decision later.
Getting all interactive from within a library such as libdebuginfod client is not really good practice nor generally practical. I'd think that the setting of the environment variable & call into the library embodies consent by the enveloping application.
Thanks for the reply, Frank. Yeah, I thought about the good practices, too. My rationale for filing this bug against debuginfod instead of e.g. GDB is that it is more uniform to have the actual agent who performs the download worry about obtaining permission, instead of having each library user (GDB, perf, etc.) do it. As for the setting of the environment variable being considered consent, one of the points raised in the discussion on debian-devel is that, with the way things are implemented now (using a /etc/profile.d/ snippet), the user will likely not be aware that DEBUGINFOD_URLS is set unless she herself was the one who installed the system. Also, and arguably, DEBUGINFOD_URLS's purpose is just to specify which debuginfod servers should be consulted, not if it is OK to do the actual request. Anyway, I'm not opposed to the idea that it is the actual library user who should obtain explicit user consent here. In a way, you could even consider that libdebuginfod is a wrapper around libcurl, and I totally agree that the library should implement the mechanism and that its clients should implement the policy.
> the user will likely not be aware that DEBUGINFOD_URLS is set unless > she herself was the one who installed the system. The way I'd address this is to advise the sysadmin to set this by default systemwide only if the user base is going to be copacetic with this, or if they are informed somehow (release notes?) so they can easily opt out. If pure documentation is not enough, maybe have some path from logon through to the calling application print out the env var that first time. Note that hypothetical unintentional information leakage is very small: buildids, and perhaps the curl User-Agent: field. That's it. (It won't get to querying source files unless the debuginfo is found first.) Closing as WONTFIX on account of the impropriety of a low level library engaging in interactive dialogue.
Instead of WONTFIX for debuginfod, I am reopening this against GDB because I still think it is a good idea for the client to implement this feature.
(In reply to Sergio Durigan Junior from comment #4) > Instead of WONTFIX for debuginfod, I am reopening this against GDB because I > still think it is a good idea for the client to implement this feature. Hi Sergio. Since commit 7811fa5995 gdb will print a notice when debuginfod is enabled and give the user a chance to opt out. Closing this bug as FIXED.
(In reply to Aaron Merey from comment #5) > (In reply to Sergio Durigan Junior from comment #4) > > Instead of WONTFIX for debuginfod, I am reopening this against GDB because I > > still think it is a good idea for the client to implement this feature. > > Hi Sergio. Since commit 7811fa5995 gdb will print a notice when debuginfod > is enabled and give the user a chance to opt out. Closing this bug as FIXED. That's awesome, Aaron. Thanks a lot.