On 11/29/2014 04:35 AM, Pandu Rao wrote:
> Both /dev/random and /dev/urandom seem to work fine.
Thanks for your checking.
It would be good if you have a small test case which can reproduce the
failure. I tried duplicity with scp myself, but I couldn't reproduce
the bug.
The error occured with the message:
> *** buffer overflow detected ***: gpg terminated
If this is caused by __fdelt_chk, it means that the file descriptor is
> 1024, which is not likely in usual conditions.
Attached is my own test case which can reproduce this error message.
It artificially uses more than 1024 file descriptors, and it kicks the
point of GnuPG.
But, I am not sure if your case is really like that.
I modified /usr/lib/python2.7/dist-packages/duplicity/gpginterface.py
to see the file descriptors in actual use (by the output to stderr).
Invoking duplicity, the maximum number was 12 (for me with ssh), far
lower than 1024.
I suspect if duplicity has some bug not closing file.
--- gpginterface.py~ 2014-05-09 22:27:39.000000000 +0900
+++ gpginterface.py 2014-11-28 16:05:14.089967785 +0900
@@ -404,6 +404,7 @@
# if we are writing
if _fd_modes[fh_name] == 'w': pipe = (pipe[1], pipe[0])
process._pipes[fh_name] = Pipe(pipe[0], pipe[1], 0)
+ print >> sys.stderr, ("PIPE: %d" % pipe[0])
for fh_name, fh in attach_fhs.items():
process._pipes[fh_name] = Pipe(fh.fileno(), fh.fileno(), 1)
--
# Reproduce the gpg 1.14 failure at FD_SET/FD_CLR
# See: https://bugs.debian.org/771263
import os, fcntl
N=1024
fds = {}
maxfd = 0
for i in range(N):
fds[i] = os.open('/etc/motd', os.O_RDONLY) # Any file is OK
if maxfd < fds[i]:
maxfd = fds[i]
print maxfd
from subprocess import check_output
result = check_output(["gpg", "-r", "4ca7babe", "--encrypt", "bug771263.py"])
