Page MenuHome GnuPG

Error emitted: gpg: error reading symlink '/proc/curproc/file': No such file or directory
Open, Needs TriagePublic

Description

Beginning in gpg 2.3.3 (did not occur in 2.3.2), there is an error emitted when running on macOS when most operations are performed.

E.g.:

gpg: error reading symlink '/proc/curproc/file': No such file or directory
gpg: assuming signed data in 'gnupg-2.3.3.tar.bz2'
gpg: Signature made Tue Oct 12 08:48:46 2021 PDT
gpg:                using EDDSA key 6DAA6E64A76D2840571B4902528897B826403ADA
gpg: Good signature from "Werner Koch (dist signing 2020)" [full]

The problem appears to be in common/homedir.c. The routine unix_rootdir() assumes that /proc is available, and issues an error diagnostic when it discovers it missing.

The error seems to be harmless, but emitting an error message about it could alarm users.

Is the error of no consequence? If so, perhaps the contents of unix_rootdir() could be stubbed out and just return NULL on the apple platform.

Details

Version
2.3.3

Event Timeline

werner added a subscriber: werner.

We now require a way to get the actual image of a process. For macOS the BSD method is used and we obviously need to find another way for macOS.

No, the error is harmless. I guess it shouldn't be printed (except when debugging).

unix_rootdir() is guarded with

#ifndef HAVE_W32_SYSTEM /* Unix */

It would make sense to also exclude macOS.

OTOH, this is now also used when running tests which means tests couldn't be run on macOS.

The point of unix_rootdir() is to find out whether a gpgconf.ctl file exists next to the gpgconf executable. I guess we need an alternative implementation for macOS for this. Would be great if someone more familiar with macOS could provide a patch.

On macOS _NSGetExecutablePath could be used, but iiuc this requires linking against dyld. For other OSes we would also need more code. I doubt that this makes a lot of sense these days; but we should come up with a solution, even if that means we need an envvar to specify the location of that open gpgconf.ctl file.

Urgs, I already implemented this:

if ((name = getenv ("GNUPG_BUILD_ROOT")) && *name == '/')
    {
      /* Try a fallback for systems w/o a supported /proc
       * file system.  */
      xfree  (buffer);
      buffer = xstrconcat (name, "/bin/gpgconf", NULL);
      log_info ("trying fallback '%s'\n", buffer);
    }

I second this. This is problematic on (Free)BSD too, where /proc is usually optional and might not be mounted at all. I concur that this should be silenced if not running in debug mode.

Can't we use $(bindir) at configure time to figure the path? Or perhaps I don't understand the difference with the gnupg_bindir function in the same file :/

gnupg_bindir() uses unix_rootdir() falling back to the builtin configure time path if unix_rootdir() returns NULL. So, there is no difference.

$(bindir) at configure time may be completely different from the actual location of the binary at runtime, e.g. in case of AppImages where the actual location of the binary inside the AppImage is some path below a temporary mount point.

Thanks for the clarification. So it's just a matter of not emitting the warning I guess?