Bug#714917: encrypting submissions creates /root/.gnupg/*

2013-07-05 Thread Bill Allombert
On Thu, Jul 04, 2013 at 11:22:29AM +0200, Ansgar Burchardt wrote:
 Package: popularity-contest
 Version: 1.58
 Severity: normal
 
 Enabling the encryption of submissions will result in creating a /root/.gnupg
 directory including a gpg.conf, secring.gpg, trustdb.gpg, random_seed.
 
 Just using popularity-contest shouldn't do this. Maybe passing --no-config or
 --homedir /some/temporary/directory to gpg would be a good idea. It would also
 result in not using (maybe unwanted) settings from root's gpg.conf.

Jakub Wilk in http://lists.debian.org/debian-devel/2013/06/msg00681.html
suggest to use --no-options:

   --no-options
  Shortcut  for  --options /dev/null. This option is detected before an 
attempt to
  open an option file.  Using this option will also  prevent  the  
creation  of  a
  ‘~/.gnupg’ homedir.

Could you check whether this would address this bug ?

Thanks for testing popcon encryption!
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#714917: encrypting submissions creates /root/.gnupg/*

2013-07-05 Thread Ansgar Burchardt
On 07/05/2013 14:44, Bill Allombert wrote:
 On Thu, Jul 04, 2013 at 11:22:29AM +0200, Ansgar Burchardt wrote:
 Enabling the encryption of submissions will result in creating a /root/.gnupg
 directory including a gpg.conf, secring.gpg, trustdb.gpg, random_seed.

 Just using popularity-contest shouldn't do this. Maybe passing --no-config or
 --homedir /some/temporary/directory to gpg would be a good idea. It would 
 also
 result in not using (maybe unwanted) settings from root's gpg.conf.
 
 Jakub Wilk in http://lists.debian.org/debian-devel/2013/06/msg00681.html
 suggest to use --no-options:
 
--no-options
   Shortcut  for  --options /dev/null. This option is detected before 
 an attempt to
   open an option file.  Using this option will also  prevent  the  
 creation  of  a
   ‘~/.gnupg’ homedir.
 
 Could you check whether this would address this bug ?

No, doesn't work:

/etc/cron.daily # diff -u popularity-contest.ori popularity-contest
--- popularity-contest.ori  2013-07-05 14:53:57.009406485 +0200
+++ popularity-contest  2013-07-05 14:55:42.583330879 +0200
@@ -71,7 +71,7 @@
 if [ $ENCRYPT = yes ]  [ -x $GPG ]; then
   POPCONGPG=$POPCON.gpg
   rm -f $POPCONGPG
-  $GPG --no-default-keyring --keyring $KEYRING --trust-model=always \
+  $GPG --batch --no-tty --no-options --no-default-keyring --keyring
$KEYRING --trust-model=always \
--armor -o $POPCONGPG -r $POPCONKEY --encrypt $POPCON
   POPCON=$POPCONGPG
 fi

/etc/cron.daily # ./popularity-contest
gpg: keyblock resource `/root/.gnupg/secring.gpg': file open error
gpg: fatal: /root/.gnupg: directory does not exist!
secmem usage: 1408/1408 bytes in 2/2 blocks of pool 1408/32768
cat: /var/log/popularity-contest.gpg: No such file or directory

Same with only --no-options (and without --batch --no-tty). No idea why
gpg wants to access the secret keyring if it's not used, but using an
empty (temporary) directory with --homedir might work.

It also looks like the script continues even though calling gpg failed.
Maybe you want to use set -e?

Ansgar


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#714917: [Popcon-developers] Bug#714917: encrypting submissions creates /root/.gnupg/

2013-07-05 Thread Bill Allombert
On Fri, Jul 05, 2013 at 03:03:27PM +0200, Ansgar Burchardt wrote:
 On 07/05/2013 14:44, Bill Allombert wrote:
  On Thu, Jul 04, 2013 at 11:22:29AM +0200, Ansgar Burchardt wrote:
  Enabling the encryption of submissions will result in creating a 
  /root/.gnupg
  directory including a gpg.conf, secring.gpg, trustdb.gpg, random_seed.
 
  Just using popularity-contest shouldn't do this. Maybe passing --no-config 
  or
  --homedir /some/temporary/directory to gpg would be a good idea. It would 
  also
  result in not using (maybe unwanted) settings from root's gpg.conf.

Does --no-config exist ? It is not documented and gpg just say
Invalid option.

It is rather painful to create dummy gpg HOME directories for no good reason.
Maybe we should ask the gpg maintainers
 
 It also looks like the script continues even though calling gpg failed.
 Maybe you want to use set -e?

Yes. Strange I never noticed it was missing before.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#714917: encrypting submissions creates /root/.gnupg/*

2013-07-04 Thread Ansgar Burchardt
Package: popularity-contest
Version: 1.58
Severity: normal

Enabling the encryption of submissions will result in creating a /root/.gnupg
directory including a gpg.conf, secring.gpg, trustdb.gpg, random_seed.

Just using popularity-contest shouldn't do this. Maybe passing --no-config or
--homedir /some/temporary/directory to gpg would be a good idea. It would also
result in not using (maybe unwanted) settings from root's gpg.conf.

Ansgar

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-48-generic (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages popularity-contest depends on:
ii  debconf [debconf-2.0]  1.5.50
ii  dpkg   1.16.10

Versions of packages popularity-contest recommends:
ii  cron  3.0pl1-124
ii  gnupg 1.4.12-7
ii  ssmtp [mail-transport-agent]  2.64-7

Versions of packages popularity-contest suggests:
pn  anacron  none

-- debconf information excluded


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org