From: Theodore Ts'o <tytso@mit.edu>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: [RFH] gpg --import entropy while running tests
Date: Wed, 28 Dec 2016 11:05:21 -0500 [thread overview]
Message-ID: <20161228160520.dsybuqljzkzsik2d@thunk.org> (raw)
In-Reply-To: <20161228083930.5li6cb6yplusc26m@sigill.intra.peff.net>
On Wed, Dec 28, 2016 at 03:39:30AM -0500, Jeff King wrote:
> > https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=4473db1ef24031ff4e26c9a9de95dbe898ed2b97
> >
> > So this does seem like a gpg bug.
>
> I've submitted a bug report to gpg:
>
> https://bugs.gnupg.org/gnupg/issue2897
>
> so we'll see what they say.
Yeah, they are definitely doing something very.... hard to explain.
Pid 8348 is the gpg-agent process which the main gpg program (pid
8344) connected to. It starts trying to get randomness in response to
a KEYWRAP command:
8348 10:58:57.882909 access("/dev/random", R_OK) = 0
8348 10:58:57.883205 access("/dev/urandom", R_OK) = 0
8348 10:58:57.883472 open("/dev/urandom", O_RDONLY) = 9
8348 10:58:57.883729 fcntl(9, F_GETFD) = 0
8348 10:58:57.883914 fcntl(9, F_SETFD, FD_CLOEXEC) = 0
It opens /dev/urandom, but then never uses fd 9 ever again. Instead,
it uses getrandom, but in a pretty silly fashion, with lots of sleeps
in between, and not between each progress report, either:
8348 10:58:57.884129 write(8, "S PROGRESS need_entropy X 30 120", 32 <unfinished ...>
8344 10:58:57.884338 <... read resumed> "S PROGRESS need_entropy X 30 120", 1002) = 32
8348 10:58:57.884424 <... write resumed> ) = 32
8344 10:58:57.884488 read(5, <unfinished ...>
8348 10:58:57.884550 write(8, "\n", 1 <unfinished ...>
8344 10:58:57.884715 <... read resumed> "\n", 970) = 1
8348 10:58:57.884800 <... write resumed> ) = 1
8344 10:58:57.884883 read(5, <unfinished ...>
8348 10:58:57.884951 nanosleep({0, 100000000}, NULL) = 0
8348 10:58:57.985363 select(10, [9], NULL, NULL, {0, 100000}) = 1 (in [9], left {0, 99994})
8348 10:58:57.985593 getrandom("&\275\354^\256\320\3w\21:R]`eJ\t\t\350\245\202>\255\237\324\324\340\24^c\323\210\376"..., 90, 0) = 90
8348 10:58:57.985751 write(8, "S PROGRESS need_entropy X 120 12"..., 33) = 33
8344 10:58:57.985885 <... read resumed> "S PROGRESS need_entropy X 120 12"..., 1002) = 33
8348 10:58:57.985934 write(8, "\n", 1 <unfinished ...>
8344 10:58:57.985982 read(5, <unfinished ...>
8348 10:58:57.986015 <... write resumed> ) = 1
8344 10:58:57.986048 <... read resumed> "\n", 969) = 1
8348 10:58:57.986090 nanosleep({0, 100000000}, <unfinished ...>
8344 10:58:57.986142 read(5, <unfinished ...>
8348 10:58:58.086253 <... nanosleep resumed> NULL) = 0
8348 10:58:58.086370 write(8, "S PROGRESS need_entropy X 30 120", 32) = 32
8344 10:58:58.086502 <... read resumed> "S PROGRESS need_entropy X 30 120", 1002) = 32
8348 10:58:58.086541 write(8, "\n", 1 <unfinished ...>
8344 10:58:58.086579 read(5, <unfinished ...>
8348 10:58:58.086604 <... write resumed> ) = 1
8344 10:58:58.086630 <... read resumed> "\n", 970) = 1
8348 10:58:58.086661 nanosleep({0, 100000000}, <unfinished ...>
8344 10:58:58.086703 read(5, <unfinished ...>
8348 10:58:58.186815 <... nanosleep resumed> NULL) = 0
8348 10:58:58.186894 select(10, [9], NULL, NULL, {0, 100000}) = 1 (in [9], left {0, 99995})
8348 10:58:58.187038 getrandom("\365\221\374m\360\235\27\330\264\223\365\363<6\302\324F\5\354Q|,\366\253\337u\226\265\345\250CA"..., 90, 0) = 90
The worst part of this is that the commit description claims this is a
workaround for libgcrypt using /dev/random, but it's not using
/dev/random --- it's using getrandom, and it pointlessly opened
/dev/urandom first (having never opened /dev/random).
This looks like a classic case of Lotus Notes / Websphere disease ---
to many d*mned layers of abstraction....
- Ted
prev parent reply other threads:[~2016-12-28 17:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-28 7:23 [RFH] gpg --import entropy while running tests Jeff King
2016-12-28 8:02 ` Jeff King
2016-12-28 8:39 ` Jeff King
2016-12-28 16:05 ` Theodore Ts'o [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161228160520.dsybuqljzkzsik2d@thunk.org \
--to=tytso@mit.edu \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).