Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 718066 - app-portage/gemato-14.3: gemato verify leaves a running gpg-agent process
Summary: app-portage/gemato-14.3: gemato verify leaves a running gpg-agent process
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Tools (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
: 724872 (view as bug list)
Depends on:
Blocks: 650144
  Show dependency tree
Reported: 2020-04-18 16:03 UTC by Daniele Boffi
Modified: 2020-05-24 02:11 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Daniele Boffi 2020-04-18 16:03:46 UTC
I am used to run the following command in a cron script every night:

#! /bin/sh
/usr/bin/glsa-check -l affected | grep '\[N\]'

Every day I find two instances of processes similar to the following one that I have to kill by hand:

gpg-agent --homedir /tmp/tmpph92pbpr --use-standard-socket --daemon

I am running several other cron jobs during the night that might be the reason as well, but looking at the timestamps the most likely one is the glsa-check
Comment 1 Zac Medico gentoo-dev 2020-04-23 23:26:51 UTC
I think it must be some other cron job because glsa-check does not call gpg or gpg-agent as far as I can tell.
Comment 2 Daniele Boffi 2020-04-24 07:39:25 UTC
(In reply to Zac Medico from comment #1)
> I think it must be some other cron job because glsa-check does not call gpg
> or gpg-agent as far as I can tell.

OK, thanks for the clarification. Another cron job that runs almost at the same time is related to "eix-sync" and "eix-diff". Could this be the reason for the gpg-agent processes?
Comment 3 Zac Medico gentoo-dev 2020-04-24 08:06:36 UTC
Maybe it's the eix-sync cron job. For signature verification, gemato uses gpg.
Comment 4 Zac Medico gentoo-dev 2020-04-24 18:13:58 UTC
In repos.conf, you can use a setting like this to disable the gemato gpg stuff, but it's a security vulnerability so it's best if you manually verify the repository afterwards:

sync-rsync-verify-metamanifest = no

You can manually verify the repository with a command like this:

gemato verify --openpgp-key /usr/share/openpgp-keys/gentoo-release.asc /var/db/repos/gentoo

You can test if running the gemato command in a cron job leaves any gpg-agent processes.
Comment 5 Daniele Boffi 2020-04-25 07:05:59 UTC
After adding to my repos.conf

sync-rsync-verify-metamanifest = no

the problem has disappeared. So this was the cause: thanks!
However, I don't have the dir


where should I look for it?
Moreover, running the gemato command (no cron) results to ghost gpg-agent processes.
Comment 6 Brian Dolbec (RETIRED) gentoo-dev 2020-04-25 12:19:29 UTC
Where your repo is located is specified in the repos.conf/gentoo.conf file:

location: /usr/portage    <== really old location

location: /var/db/repos   <== new default location

Comment 7 Daniele Boffi 2020-04-25 13:42:00 UTC
OK, I got it.

I can confirm that even when I run the command gemato from the command line it leaves two instances of gpg-agent open.

As a temporary fix I can kill them in my cron job after the eix-sync.
Comment 8 Zac Medico gentoo-dev 2020-04-25 19:53:54 UTC
We'll need to examine your gemato and gnupg versions:

emerge --info app-crypt/gnupg app-portage/gemato
Comment 9 Daniele Boffi 2020-04-26 06:14:50 UTC
Portage 2.3.89 (python 3.6.10-final-0, default/linux/amd64/17.0, gcc-8.3.0, glibc-2.29-r7, 4.19.72-gentoo x86_64)
                         System Settings
System uname: Linux-4.19.72-gentoo-x86_64-Intel-R-_Xeon-R-_CPU_E5-1620_0_@_3.60GHz-with-gentoo-2.6
KiB Mem:    16351676 total,   9317448 free
KiB Swap:   16777212 total,  16605692 free
Timestamp of repository gentoo: Sun, 26 Apr 2020 01:30:01 +0000
Head commit of repository gentoo: cf7bc8cee05a4dd95af28b48b66dd5a93e48a5c8
sh bash 4.4_p23-r1
ld GNU ld (Gentoo 2.32 p2) 2.32.0
app-shells/bash:          4.4_p23-r1::gentoo
dev-java/java-config:     2.2.0-r4::gentoo
dev-lang/perl:            5.30.1::gentoo
dev-lang/python:          2.7.17::gentoo, 3.6.10::gentoo
dev-util/cmake:           3.14.6::gentoo
dev-util/pkgconfig:       0.29.2::gentoo
sys-apps/baselayout:      2.6-r1::gentoo
sys-apps/openrc:          0.42.1::gentoo
sys-apps/sandbox:         2.13::gentoo
sys-devel/autoconf:       2.13-r1::gentoo, 2.69-r4::gentoo
sys-devel/automake:       1.13.4-r2::gentoo, 1.16.1-r1::gentoo
sys-devel/binutils:       2.32-r1::gentoo
sys-devel/gcc:            8.3.0-r1::gentoo, 9.2.0-r2::gentoo
sys-devel/gcc-config:     2.1::gentoo
sys-devel/libtool:        2.4.6-r6::gentoo
sys-devel/make:           4.2.1-r4::gentoo
sys-kernel/linux-headers: 4.19::gentoo (virtual/os-headers)
sys-libs/glibc:           2.29-r7::gentoo

    location: /extra/portage
    sync-type: rsync
    sync-uri: rsync://
    priority: -1000
    sync-rsync-verify-max-age: 24
    sync-rsync-verify-jobs: 1
    sync-rsync-verify-metamanifest: no

    location: /usr/local/portage
    masters: gentoo

CFLAGS="-march=native -O2 -pipe"
CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php7.3/ext-active/ /etc/php/apache2-php7.4/ext-active/ /etc/php/cgi-php7.3/ext-active/ /etc/php/cgi-php7.4/ext-active/ /etc/php/cli-php7.3/ext-active/ /etc/php/cli-php7.4/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-march=native -O2 -pipe"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs collision-protect config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-O2 -pipe"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
USE="X acl amd64 bash-completion berkdb bzip2 cdr cli consolekit crypt cups dbus dri dvdr fortran gdbm iconv ieee1394 infinality ipv6 jpeg lapack latex libtirpc maildir mmx multilib ncurses nls nptl openmp pam pcre png policykit pulseaudio readline seccomp session split-usr sse sse2 ssl tcpd tiff truetype unicode vim-syntax xattr zlib" ABI_X86="64" ADA_TARGET="gnat_2018" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="libinput keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-3" POSTGRES_TARGETS="postgres10 postgres11" PYTHON_SINGLE_TARGET="python3_6" PYTHON_TARGETS="python2_7 python3_6" RUBY_TARGETS="ruby24 ruby25" USERLAND="GNU" VIDEO_CARDS="nvidia vesa" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"

                        Package Settings

app-crypt/gnupg-2.2.19::gentoo was built with the following:
USE="bzip2 nls readline smartcard ssl -doc -ldap (-selinux) -tofu -tools -usb -user-socket -wks-server" ABI_X86="(64)"
CFLAGS="-march=native -O2 -pipe -fcommon"

app-portage/gemato-14.3::gentoo was built with the following:
USE="blake2 bzip2 gpg -lzma -sha3 -test -tools" ABI_X86="(64)" PYTHON_TARGETS="python2_7 python3_6 (-pypy3) -python3_7 (-python3_8)"
FEATURES="userfetch network-sandbox assume-digests ebuild-locks unknown-features-warn unmerge-orphans pid-sandbox collision-protect binpkg-docompress merge-sync multilib-strict xattr protect-owned binpkg-dostrip unmerge-logs usersandbox sfperms userpriv usersync parallel-fetch fixlafiles strict config-protect-if-modified preserve-libs distlocks ipc-sandbox news sandbox binpkg-logs"
Comment 10 Daniele Boffi 2020-05-01 10:22:20 UTC
Any hint on how to solve this problem? Thanks!
Comment 11 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2020-05-01 17:51:17 UTC
Does the temporary directory listed in the agent command line still exist?  AFAIK gpg-agent should terminate when the directory is removed.
Comment 12 Daniele Boffi 2020-05-01 18:59:03 UTC
The command is still running even when the directory doesn't exist.

I tried it now and I have the following two instances:

gpg-agent --homedir /tmp/tmp26b_unx0 --use-standard-socket --daemon
gpg-agent --homedir /tmp/tmptej_9u3w --use-standard-socket --daemon

The two directories /tmp/tmp* don't exist.

Actually, I realized about this issue since my partition containing /tmp was growing anomalously and I couldn't figure out where were the files filling it. After I killed the gpg-agent processes the space was freed again.
Comment 13 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2020-05-02 17:32:27 UTC
What filesystem are you using for /tmp?  Does your kernel support inotify()?

FWICS gpg-agent makes some assumptions about 'reliable' inotify and doesn't poll the directory if it assumes inotify will reliably report its disappearance.
Comment 14 Daniele Boffi 2020-05-02 19:01:01 UTC
It's a standard ext4 fs and inotify() works as expected.

I monitored with "inotifywait -m /tmp" while executing gemato
I can confirm that the creation and the deletion of the two /tmp directories are detected. But the two instances of gpg-agent are still present
Comment 15 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2020-05-03 06:17:46 UTC
Could you try mounting tmpfs for the run for comparison?  It could help us triage it.
Comment 16 Daniele Boffi 2020-05-03 07:37:03 UTC
Same issue if /tmp is mounted as tmpfs
Comment 17 Daniele Boffi 2020-05-13 13:17:26 UTC
Is there any other test that we can try? Thanks
Comment 18 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2020-05-13 13:19:24 UTC
I'm sorry, I had a hardware failure and only returned today to start coping with the backlog.  I'm planning to try removing support for old GnuPG versions and then use gpgconf to kill the agent.
Comment 19 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2020-05-16 15:59:58 UTC
I've just pushed a fix to master.  Could you try if -9999 fixes the issue for you before I make a release?
Comment 20 Daniele Boffi 2020-05-16 16:31:36 UTC
(In reply to Michał Górny from comment #19)
> I've just pushed a fix to master.  Could you try if -9999 fixes the issue
> for you before I make a release?

Thanks, I tried but unfortunately the issue is still present. Two instances of gpg-agent after the execution of gemato. Please let me know how to debug further
Comment 21 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2020-05-16 17:33:34 UTC
I'm sorry for asking but are you sure that you've killed prior processes and updated -9999 to include 55a9a2f01baed17eb4b6eff88b0f8a1343a847d4?

The next step to try would be calling 'GNUPGHOME=/tmp/path-to-gnupghome gpgconf --kill all' manually and seeing if that works.
Comment 22 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2020-05-16 17:34:19 UTC
Hmm, no, it probably won't work because the directory will be removed by then.  You could try running gemato in debug mode though, and then it should leave the directory in place for further experiments.
Comment 23 Daniele Boffi 2020-05-16 18:05:01 UTC
(In reply to Michał Górny from comment #21)
> I'm sorry for asking but
No problem

> are you sure that you've killed prior processes

> updated -9999 to include 55a9a2f01baed17eb4b6eff88b0f8a1343a847d4?
This is tricky. I ran eix-sync before updating to gemato-9999

However, now I checked the Manifest within the portage dir and its timestamp is May 7.

The manifest contains:

EBUILD gemato-9999.ebuild 687 BLAKE2B c8e143e634db7c8303840c4c8f873b0bb93d23146b98ab10a127a6695c4973b4ee7dc06045723c8cb2d0ca6c7ce1fb0960636ad98d31efc47c01ed0f67304610 SHA512 c6c10008ca64470bc06f29b0cde937541e9d26530048c03d23f961d3709c2f4983c63e88a20627aed5e1db6990e69c9e21dda07287d43bc1e4b7a48b19e94f7a
Comment 24 Zac Medico gentoo-dev 2020-05-16 18:54:07 UTC
(In reply to Daniele Boffi from comment #23)
> However, now I checked the Manifest within the portage dir and its timestamp
> is May 7.
> The manifest contains:
> EBUILD gemato-9999.ebuild 687 BLAKE2B
> c8e143e634db7c8303840c4c8f873b0bb93d23146b98ab10a127a6695c4973b4ee7dc06045723
> c8cb2d0ca6c7ce1fb0960636ad98d31efc47c01ed0f67304610 SHA512
> c6c10008ca64470bc06f29b0cde937541e9d26530048c03d23f961d3709c2f4983c63e88a2062
> 7aed5e1db6990e69c9e21dda07287d43bc1e4b7a48b19e94f7a

That's fine because the ebuild always pulls latest commits from the master branch here:
Comment 25 Daniele Boffi 2020-05-16 19:20:08 UTC
(In reply to Michał Górny from comment #22)
> You could try running gemato in debug mode

Could you please advise how to run it in debug mode? Thanks
Comment 26 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2020-05-16 20:13:17 UTC
I'm sorry, I've made a silly typo in the code.  Please wait ~15 minutes and rebuild gemato.

For future reference:

(In reply to Daniele Boffi from comment #25)
> Could you please advise how to run it in debug mode? Thanks

In your rsync checkout:

gemato verify --debug -K /usr/share/openpgp-keys/gentoo-release.asc .
Comment 27 Daniele Boffi 2020-05-17 06:23:15 UTC
I am happy to confirm that now everything is OK and, after executing gemato there are no stale gpg-agent processes any more.

Comment 28 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2020-05-17 06:29:49 UTC
Thanks!  I'll push a new release in a few minutes.
Comment 29 Larry the Git Cow gentoo-dev 2020-05-17 07:26:17 UTC
The bug has been closed via the following commit(s):

commit 31da0bf13a1b35662ecc3c5bf4ba651cdeef7156
Author:     Michał Górny <>
AuthorDate: 2020-05-17 06:29:30 +0000
Commit:     Michał Górny <>
CommitDate: 2020-05-17 06:29:30 +0000

    app-portage/gemato: Bump to 14.4
    Signed-off-by: Michał Górny <>

 app-portage/gemato/Manifest           |  1 +
 app-portage/gemato/gemato-14.4.ebuild | 33 +++++++++++++++++++++++++++++++++
 2 files changed, 34 insertions(+)
Comment 30 Zac Medico gentoo-dev 2020-05-24 02:11:20 UTC
*** Bug 724872 has been marked as a duplicate of this bug. ***