Re: Surprising command line options handling

[Werner Koch]

On Tue, 24 Feb 2015 00:59, dani...@grinta.net said:

> However, the ordering is not really enforced: this

Right.  Options and commands are actuallay interchangeable but that is
an undocumented features.  In fact the only difference between a command
and an option is that tehre may only be one command but many options.
And the error message for a command is slightly different.

> I find it surprising that unrecognized tokens are simply ignored.
> Wouldn't it be preferable to error out, at least on unrecognized options?

GnuPG does not follow the common GNU model of interchangeable options
and args.  It is modeled like a classic Unix tool.  Using the special
option '--' indicates that everything what follows are args and using
this is suggested to avoid args beeing interpreted as options.

No, we can't error out on an arg which looks like an option because that
may actually be a valid argument.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Surprising command line options handling

[Peter Lebbing]

On 24/02/15 09:34, Werner Koch wrote:
> No, we can't error out on an arg which looks like an option because that
> may actually be a valid argument.

However, if running interactively and --batch is not specified, might it
be useful to print "Warning: --export-options did not match any key"
with the command line Daniele tried in the OP, so people more quickly
recognise that GnuPG is trying to match it to a key rather than
interpret it as an option? It might save on some struggling and head
scratching...

The warning would also help in other cases. What if I want to export
keys A, B and C, but match B wrongly. GnuPG doesn't complain, and I end
up with a file with exported keys. Only later do I realise B is not
among them...

This surprising command line handling has come up here from time to
time, I'm sure it was discussed before... I just can't remember...

I think this point isn't covered in the FAQ yet. I suggest we come up
with a question and answer that cover this case. Something like "GnuPG
ignores options I specify on the command line!" as a question that isn't
a question. Preferably, we make the answer an answer, though.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Surprising command line options handling

[Daniele Nicolodi]

On 24/02/15 09:34, Werner Koch wrote:
>> I find it surprising that unrecognized tokens are simply ignored.
>> Wouldn't it be preferable to error out, at least on unrecognized options?
> 
> GnuPG does not follow the common GNU model of interchangeable options
> and args.  It is modeled like a classic Unix tool.  Using the special
> option '--' indicates that everything what follows are args and using
> this is suggested to avoid args beeing interpreted as options.
> 
> No, we can't error out on an arg which looks like an option because that
> may actually be a valid argument.

Hello Werner,

thank for your answer. Trying to better understand gnupg command line
argument parsing I found that the real confusing thing is that arguments
can be silently ignored:

gpg --list-keys foo

results in an error if there is no key matching "foo", however

gpg --list-keys 41E999D7 foo

does not result in an error and the fact that "foo" does not match any
is not signaled to the user, if there is a key that matches "41E999D7".

I see that in the 2.1 branch there is indeed a check and a warning for
arguments that look like options (start with "--") so I must not be the
only one that found this confusing :)

Why do not error out if an argument cannot be used to identify a key? I
think that signaling to the user that one part of the command line has
not been successfully interpreted is good practice.

Cheers,
Daniele


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

GNU-divert-to-card S2K format

[Léonard Dallot]

Hello,

I am trying to write a program that read GPG privates keys that have
been exported to a GPG smartcard using GPG. Those keys are encoded
unsing a S2K Specifier that is described in RFC 4880 as
"experimental" (Tag 101). GPG (using gpg --list-packets) describes this
as "gnu-divert-to-card S2K", followed by a serial number.

I have tried to find a description of this S2K format, but I haven't
found one. Does anyone know where I can find a description of this
"experimental" S2K ?

Thanks a lot for your help,
Léonard


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Compiled binaries execute but exit with "Abort"

[Errol Casey]

i will try going back to the older version of libgpg-error

This is the order of the build I did; if there are versions of packages
that don't require pth.

Let me know and I will try to rebuild with different versions

1. Build and install pth 2.07
2. Build and install libgpg-error 1.18 (due to another package saying it
needed a newer version that what I had. I think I had older than 1.12)
3. Build and install libgcrypt 1.6.2
4. Build and install libassuan 2.2.0
5. Build and install libksba 1.3.2
6. Build gnupg 2.0.26


On Thu, Feb 19, 2015 at 2:31 PM, Werner Koch  wrote:

> On Thu, 19 Feb 2015 12:01, er...@askerrol.org said:
> > Thanks. Now to figure out why make check fails but make works without
> > error. Are there dependencies besides pth for libgpg-error?
>
> Are you using a recent Pth version?  I recall that older Pth versions
> had problems when used by programs which also make use of pthreads.
> That was actually the reasons for the pcsc-wrapper used by scdaemon.
>
> My tests indicated that there was no more problem - on Linux.  However,
> this might be because glibc implements mutex directly and not in
> libpthread.  Thus we may have the same conflict as we had with older
> glibc versions.
>
> A solution for you might be to go back to libgpg-error 1.12 which has no
> mutexes and thus no need for pthreads.
>
> I doubt that we can do a real fix for that.  I dropped Pth support for a
> reason ;-).  The only thing I can image is an environment variable
> forcing libgpg-error to entire disable the mutex support.
>
>
> Shalom-Salam,
>
>Werner
>
>
> --
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>
>


-- 
Errol Casey
er...@askerrol.org
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GNU-divert-to-card S2K format

[Werner Koch]

On Tue, 24 Feb 2015 15:55, leonard.dal...@taztag.com said:

> I have tried to find a description of this S2K format, but I haven't
> found one. Does anyone know where I can find a description of this
> "experimental" S2K ?

doc/DETAILS shows this

* GNU extensions to the S2K algorithm

  S2K mode 101 is used to identify these extensions.
  After the hash algorithm the 3 bytes "GNU" are used to make
  clear that these are extensions for GNU, the next bytes gives the
  GNU protection mode - 1000.  Defined modes are:
  - 1001 :: Do not store the secret part at all.
  - 1002 :: A stub to access smartcards (not used in 1.2.x)

for everything else you need to look at the code (parse-packet.c)


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GNU-divert-to-card S2K format

[Peter Lebbing]

On 24/02/15 17:52, Werner Koch wrote:
> for everything else you need to look at the code (parse-packet.c)

RFC 4880 specifies that for a string-to-key usage octet of 255, the final two
bytes are a checksum, but it /is/ part of the encrypted data for v4 keys. I was
curious and also had a look at the packets and the source. For the
divert-to-card s2k, RFC 4880 is not very appropriate, and section 5.5.3 should,
I think, be freely interpreted as:

>  The packet contains:
> 
>  - A Public-Key or Public-Subkey packet, as described above.
> 
>  - One octet indicating string-to-key usage conventions.  Zero
>indicates that the secret-key data is not encrypted.  255 or 254
>indicates that a string-to-key specifier is being given.  Any
>other value is a symmetric-key encryption algorithm identifier.

255 for plain checksum s2k

> 
>  - [Optional] If string-to-key usage octet was 255 or 254, a one-
>octet symmetric encryption algorithm.

cipher algo 0

> 
>  - [Optional] If string-to-key usage octet was 255 or 254, a
>string-to-key specifier.  The length of the string-to-key
>specifier is implied by its type, as described above.

specifier 110
hash algo 0
3 bytes prefix GNU
(together 5 bytes)

> 
>  - [Optional] If secret data is encrypted (string-to-key usage octet
>not zero), an Initial Vector (IV) of the same length as the
>cipher's block size.

Used to store up to 16 bytes of serial number

>  - Plain or encrypted multiprecision integers comprising the secret
>key data.  These algorithm-specific fields are as described
>below.
> 
>  - If the string-to-key usage octet is zero or 255, then a two-octet
>checksum of the plaintext of the algorithm-specific portion (sum
>of all octets, mod 65536).  If the string-to-key usage octet was
>254, then a 20-octet SHA-1 hash of the plaintext of the
>algorithm-specific portion.  This checksum or hash is encrypted
>together with the algorithm-specific fields (if string-to-key
>usage octet is not zero).  Note that for all other values, a
>two-octet checksum is required.

This whole block is absent! Somehow I expected no MPI's but two bytes where the
checksum should be. This is not the case.

Note that the serial number for OpenPGP cards has the following format:

D2 76 00 01 24
RID (Registered Application Provider Identifier)[1] for FSFE
01
Application identifier for OpenPGP Application
xx xx
Version number: I've got 01 01 (1.1) and 02 00 (2.0) cards
xx xx
Manufacturer: I've got
00 01 PPC Card Systems
00 05 ZeitControl
The list is in g10/card-util.c
xx xx xx xx
Serial number; note the duplicate use of the name; unique for a
manufacturer (unless manufacturer in range ff 00 to ff fe)
00 00
Reserved for Future Use

16 bytes in total

Cipher algo and hash algo are written as 0, but don't seem to be used/checked on
read.

I just wrote that up because I think I figured it out and didn't want the effort
to go to waste... It is rather unchecked.

HTH,

Peter.

[1] http://www.ansi.org/other_services/registration_programs/rid.aspx?menuid=10

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Compiled binaries execute but exit with "Abort"

[Errol Casey]

got a working gpg2! Thanks. Now to figure out automation. Will post a
separate thread regarding my
issues with removing passphrase,.

On Tue, Feb 24, 2015 at 11:23 AM, Errol Casey  wrote:

> i will try going back to the older version of libgpg-error
>
> This is the order of the build I did; if there are versions of packages
> that don't require pth.
>
> Let me know and I will try to rebuild with different versions
>
> 1. Build and install pth 2.07
> 2. Build and install libgpg-error 1.18 (due to another package saying it
> needed a newer version that what I had. I think I had older than 1.12)
> 3. Build and install libgcrypt 1.6.2
> 4. Build and install libassuan 2.2.0
> 5. Build and install libksba 1.3.2
> 6. Build gnupg 2.0.26
>
>
> On Thu, Feb 19, 2015 at 2:31 PM, Werner Koch  wrote:
>
>> On Thu, 19 Feb 2015 12:01, er...@askerrol.org said:
>> > Thanks. Now to figure out why make check fails but make works without
>> > error. Are there dependencies besides pth for libgpg-error?
>>
>> Are you using a recent Pth version?  I recall that older Pth versions
>> had problems when used by programs which also make use of pthreads.
>> That was actually the reasons for the pcsc-wrapper used by scdaemon.
>>
>> My tests indicated that there was no more problem - on Linux.  However,
>> this might be because glibc implements mutex directly and not in
>> libpthread.  Thus we may have the same conflict as we had with older
>> glibc versions.
>>
>> A solution for you might be to go back to libgpg-error 1.12 which has no
>> mutexes and thus no need for pthreads.
>>
>> I doubt that we can do a real fix for that.  I dropped Pth support for a
>> reason ;-).  The only thing I can image is an environment variable
>> forcing libgpg-error to entire disable the mutex support.
>>
>>
>> Shalom-Salam,
>>
>>Werner
>>
>>
>> --
>> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>>
>>
>
>
> --
> Errol Casey
> er...@askerrol.org
>



-- 
Errol Casey
er...@askerrol.org
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Cannot remove passphrase (gnupg 2.0.26/solaris 10)

[Errol Casey]

When I use gpg2 --edit-key , and then use passwd to
change/remove
passphrase by entering a blank passphrase. I get hung in an input loop

   lqk
x Please re-enter this passphrase x
x x
x Passphrase  x
x x
x x
mqj








You don't want a passphrase - this is probably a *bad* idea!

Do you really
want to do this? (y/N)

I truss the process (this is on Solaris 10), and I see it receiving the
"y\r" but it doesn't continue.

I can type N enter, and see 'N\r" also.

So not sure if it is a local issue with tty, compile issue with pinentry,
or gnupg?

But it accepts my original passphrase, and hitting enter twice and
selecting yes I want to do it, gets me to this last prompt and it will go
no further.

Hmmm:

Thinking the compile/linking of pinentry is the cause. I've seen this
before, but just ran

pinentry --version
ld.so.1: pinentry-curses: fatal: libiconv.so.2: open failed: No such file
or directory
Killed


seems I have to modify LD_LIBRARY_PATH to get pinentry to work; but this
change was made en enviornment when I tried changing passphrase above. Not
sure where the input problem is being generated.

$ pinentry --version
pinentry-curses (pinentry) 0.9.0
$ gpg2 --version
gpg (GnuPG) 2.0.26
libgcrypt 1.6.2
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, RSA, RSA, ELG, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
-- 
Errol Casey
er...@askerrol.org
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Unattended signing

[Ingo Klöcker]

On Tuesday 24 February 2015 01:36:25 Daniele Nicolodi wrote:
> Hello Daniel,
> 
> thanks for your reply.
> 
> On 21/02/15 20:11, Daniel Kahn Gillmor wrote:
> > On Wed 2015-02-18 13:46:19 -0500, Daniele Nicolodi wrote:
> >> I have a sufficient trust in the security of the server where the
> >> automated process runs, but I would like to reduce to a minimum the
> >> risks.
> > 
> > there are risks with unattended signing in general, related to what
> > messages you allow to get passed to your system.  I'm sure you've
> > already thought about this, but i'll just put it out there in case
> > someone else reading this later hasn't thought about it enough.
> 
> I was not very clear on this: the unattended signing is performed by an
> application that collects some sensible data and sends them by email
> encrypted and signed.

I can understand that you want to encrypt the sensible data. But why do you 
want to sign it?


Regards,
Ingo


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Unattended signing

[Daniel Kahn Gillmor]

On Mon 2015-02-23 19:36:25 -0500, Daniele Nicolodi wrote:
> On 21/02/15 20:11, Daniel Kahn Gillmor wrote:
>> Using a subkey is a reasonable approach, and rotating (and destroying)
>> the secret key of the rotated subkey is not a bad idea.
>
> What do you exactly mean by "destroying"? Isn't setting a suitable
> expire date enough?

If your subkey is used for signing, and the subkey is expired, then you
know that you will never want to make signatures with that key again.

That is, only a malicious person who manages to compromise that key
material can make signatures with it.  So why are you keeping it around?
setting a suitable expiry date *should* be enough, but destroying it is
safer, and you have no need to keep the secret part of that key.

   --dkg

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Unattended signing

[Peter Lebbing]

On 24/02/15 23:16, Daniel Kahn Gillmor wrote:
> So why are you keeping it around?

I suppose it depends on your definition of "destroying"...

I think you'd be fine with setting an expiry date and "--delete-secret-key"-ing
the subkey when the time comes.

If you asked me to /destroy/ the key, I would look through my drawers for all
backups I have and do a "shred" on them, and think really hard where any further
copies might have ended up.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

how to disable pinentry

[Smith, Cathy]

Hi

Can someone tell the how to disable pinentry?  I'd like to be able to run gpg 
--edit-key, or to open a password encrypted file without a GUI.  I was able to 
do that in RHEL5, but so far, not in RHEL6 or CentOS 6.

I have gpg 2.0.14 on CentOS 6.6 and RHEL6U6.

I've tried to disable pinentry, without success, with the following
1. comment out use-agent in ~/.gnupg/gpg.conf
2. unset the following variables
GPG_AGENT_INFO
SSH_ASKPASS

I've had less success on RHEL6 box as there is not a default line, use-agent, 
in the gpg.conf file.  On the CentOS box, when I try to run the passwd command 
in gpg --edit-key, I get the message:
can't connect to /home/foo/.gnupg/S.gpg-agent': No such file or 
directory

I did not see a gpg-agent daemon running on either box.  I ran a ps command 
while the gpg-edit-key was running.


Thank you.


Cathy
---
Cathy L. Smith
IT Engineer

Pacific Northwest National Laboratory
Operated by Battelle for the
U.S. Department of Energy

Phone:  509.375.2687
Fax:    509.375.2330
Email:  cathy.sm...@pnnl.gov


-Original Message-
From: gnupg-users-boun...@gnupg.org [mailto:gnupg-users-boun...@gnupg.org] On 
Behalf Of Robert J. Hansen
Sent: Wednesday, March 23, 2011 12:32 PM
To: gnupg-users@gnupg.org
Subject: Re: Deniability

On 3/23/11 3:06 PM, Mark H. Wood wrote:
> My suspicion is that we never had anywhere near as much privacy as 
> many believe.  A hundred years ago...

I grew up in a small town of under 5,000, where the nearest city of more than 
20,000 was an hour's drive away.  Forget "a hundred years ago":
having been back there recently for a funeral, I can tell you small towns are 
still that same way today.

In a sense, I think this validates my thesis.  In a small town the cost of 
sharing information about people within the town, to people within the town, is 
just about nil: you wind up having these conversations while you're at the 
service station filling up your tank, when you're in line at the grocery store, 
when you're ... etc.  But having these same conversations with people outside 
the town involves effort, which in turn means that you can travel 100 miles and 
be reasonably confident nobody there has heard of you.

I agree that the small-town phenomenon argues against the idea of an idyllic 
privacy past.  I just think modern communications means the entire world is 
turning into a small-town phenomena.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Unattended signing

[NdK]

Il 25/02/2015 00:01, Peter Lebbing ha scritto:
> On 24/02/15 23:16, Daniel Kahn Gillmor wrote:

> If you asked me to /destroy/ the key, I would look through my drawers for all
> backups I have and do a "shred" on them, and think really hard where any 
> further
> copies might have ended up.
Use a smartcard and generate on-card a new key that replaces the expired
one. So an attacker could still abuse the key (it's not protected) but
can not extract it to keep copies around.
I really like SCs for signature and authentication[*] keys since often
even if those keys are lost it's not a big deal as long as they can't be
abused.

[*] for auth, only if there's a centralized repository for the public
key, else updating all instances of the pub key stored in devices could
be a major hassle.

BYtE,
 Diego.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users