Page MenuHome GnuPG

gpgme_set_armor(myctx, 0) ignored if 'armor' option is set in gpg.conf
Closed, ResolvedPublic

Description

Consider the test program (about symmetric encryption) in the attachment
(credits to mancha user on gnupg irc channel).

gpgme_set_armor(myctx, 0) is ignored if the 'armor' option is set in my
~/.gnupg/gpg.conf
However, gpgme_get_armor(myctx) returns 0 in such cases, which is not consistent
(how can I tell whether to append .gpg or .asc to my encrypted file?)

Steps to reproduce:

  1. gcc -D_FILE_OFFSET_BITS=64 -o mancha-enc mancha-enc.c -lgpgme
  2. make sure 'armor' is set in ~/.gnupg/gpg.conf
  3. ./mancha-enc
  4. type a passphrase

Actual result:
gpgme says armor is not set, yet the encryption output is ASCII

Expected result:
the encryption result should be binary
OR
gpgme_get_armor() should return 1 if the encryption output is going to be ASCII

Details

Version
1.6.0

Event Timeline

elvis renamed this task from gpgme_get_armor ignores 'armor' option in gpg.conf to gpgme_set_armor(myctx, 0) ignored if 'armor' option is set in gpg.conf.Aug 22 2016, 3:07 PM

If a user forces all output of gpg to be armored, it is not gpgme's task to
revert this.

Putting armor into gpg.conf is as bad an idea as putting encrypt into gpg.conf.

gpgme_get_armor() returns gpgme's current state.

I see. So, how can I reliably know whether the output of my program is going to
be ascii or binary (to append either .asc or .gpg)? I should just assume that
'armor' will not be in gpg.conf?

Right. Putting armor into gpg.conf is a very bad idea. Don't assume that. If
users want to shoot into their own foot, let them do so.

werner claimed this task.