Re: Hi

[Michael A. Yetto]

On Thu, 16 Feb 2017 15:51:40 -0500
"Stephane R."  writes, and having
writ moves on:

>Can I never receive a message from u again 
>
>Sent from my iPad
>

If you look at the headers of every message, including your own, you
will find the following header.

List-Unsubscribe: ,
 

Use either the webpage or mailto URL to unsubscribe. If you never look
back here for the answer to your question you'll have to try a
different method.

Mike Yetto
-- 
"There is danger from all men. The only maxim of a free
government ought to be to trust no man living with power to
endanger the public liberty."
 - John Adams


pgpj99ogjwiDX.pgp
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GPG homedir path length limit

[Daniel Kahn Gillmor]

On Thu 2017-02-16 11:51:07 -0500, Werner Koch wrote:
> So that the /var/run/user/ directory is not cluttered with many
> directories.  Setting a different GNUPGHOME is an exception and thus it
> is fine to require an explicit creation.  Remember that not /var/run
> does not need to be a temporary directort - there is more than Linux in
> this world.

If it's an exception, it's infrequent.  So by definition, we won't be
cluttering /run/user/$(id -u)/gnupg/ with many directories.

If we clean up the directories automatically as i recommended when the
daemons terminate, it won't leave a cluttered residue.

The one common work pattern that this misses is this one:

 * create a temporary GNUPGHOME for experimentation
 * when done, do:   rm -rf "$GNUGHOME"

Without the socketdir creation, the daemons will work as long the path
is short enough, and they terminate cleanly when the temporary homedir
is destroyed.

With the socketdir creation, the daemons will work regardless of the
path length, but they won't terminate cleanly if the temporary homedir
is destroyed.  That would be unfortunate.

So my current proposal for GNU/Linux systems for daemons like gpg-agent
and dirmngr when using a non-standard $GNUPGHOME is:

  * daemons create the ephemeral socketdir automatically if possible.
  * clients try the ephemeral socketdir first, then fall back to
in-$GNUPGHOME sockets (i think this is already the case).
  * daemons watch the $GNUPGHOME with inotify, and auto-terminate if the
$GNUPGHOME itself is destroyed.
  * daemons try to rmdir() on the ephemeral socketdir on termination,
failing quietly on ENOTEMPTY.

I've documented this as a bug report at:

   https://bugs.gnupg.org/gnupg/issue2964

>> I personally like the simplicity and uniformity of "if /run/user/$(id
>> -u)/ exists and is writable, then we will use it for the socketdir."
>
> That is non-portable.

What's non-portable about it?  If it's not possible to create the
directory, we don't create it, and fall back to trying locally.  if it
is possible, we do create it and use it.

This thread should probably move over to gnupg-devel at some point, i
guess...

   --dkg

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

Re: GPG homedir path length limit

[Daniel Kahn Gillmor]

On Thu 2017-02-16 04:12:36 -0500, Justus Winter wrote:
> That is still wrong.  The length of the path of the socket is not
> limited in any way, the length of the path passed to connect is.

this is a clever approach to *connect* to such a socket, on some
systems.

But if you ever use getsockname (e.g. common/sysutils.c and
dirmngr/dns.c), the long socket path names are bound to fail on *any*
system, right?

--dkg

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

Re: Aw: Re: Re: SmartCard v2.1 : factory reset fails

[NIIBE Yutaka]

Hello,

Thanks a lot for your report in detail, in the style which I can replicate.

I'm afraid you are facing same issue what I encountered in 2011.

CHANGE REFERENCE DATA (OpenPGP card specification 2.0):
https://www.gniibe.org/log/bugreport/gnupg/openpgp-card-spec-2.0-chenge-reference-data.html

IIUC, this protocol is due to smartcard practice and standard.  I had
asked Achim (the author of OpenPGPcard specification) if this could be
changed.  No positive answer, but I think that the problem is clear
enough.

Fib Moro  wrote:
> It then asks me to "Please enter the Admin PIN".
> Now, in the believe that *123456789* was the correct default Admin PIN value,
> I would enter this *wrong* value.
> I am then prompted to enter "New Admin PIN" value and confirm that. 
> Let's say I use the value *smartcardrocks*.
> My change is then confirmed with;
>
>>
> PIN changed.
> <

Yes.  Now, New Admin PIN is *9smartcardrocks*.

> I would now be in the believe that *smartcardrocks* is the new correct Admin
> PIN.

I understand your expectation.  It was exactly same of mine.  But, new
Admin PIN is *9smartcardrocks*, which is totally confusing.

> However, any subsequent command that would require the Admin PIN would fail
> (e.g. moving keys to card, setting reset code, changing admin pin).

Naturally.

> For example, when I try to set a new reset code I am asked to enter the Admin
> PIN. 
> I enter *smartcardrocks* I get "Error setting the Reset Code: Bad PIN".
> I enter *12345678* I also get "Error setting the Reset Code: Bad PIN".
>
> I seems the Admin PIN is then broken and set to an "unknown" value.
>
> Can you replicate the above described behavior?

Yes.  The bug (from my point of view) is still there.


No, I don't have an idea to keep this problem forever.  I am currently
considering KDF generation scheme by host side.  I'm going to send my
proposal to Achim.  In this new scheme, the length of string for PIN is
fixed.  And then, this problem will be no longer valid.  That's my
development now.
-- 

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

Re: Hi

[Fernando Cassia]

On 2/16/17, Stephane R.  wrote:
> Can I never receive a message from u again

You, or someone with access to your device, subscribed your e-mail
address to this mailing list. A mailing list is a discussion list,
based on e-mail.

You need to unsubscribe yourself. Details on how to do so are at the
URL linked at the bottom of every e-mail that you receive from this
list

FC
-- 
During times of Universal Deceit, telling the truth becomes a revolutionary
act
- George Orwell

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

Re: Upgrade instructions required from GnuPG v2.0.14 to 2.1.18

[Robert J. Hansen]

> Could you please provide us instructions how to upgrade 2.0.14 to 2.1.18
> and also rollback instructions if anything goes wrong.

This is a system administration question.  You will have better luck
asking on a mailing list devoted to your specific operating system.


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

Hi

[Stephane R.]

Can I never receive a message from u again 

Sent from my iPad

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

Upgrade instructions required from GnuPG v2.0.14 to 2.1.18

[Srikanth Gangisetty]

Hello Team

Could you please provide us instructions how to upgrade 2.0.14 to 2.1.18 and 
also rollback instructions if anything goes wrong.

Thank you

Regards
G Srikanth

Srikanth Gangisetty
Database Technology Consultant
Interoute,
New Castle House
Castle Boulevard, Nottingham
NG7 1FT UK
direct line: +44 (0)1156847218
email: srikanth.gangise...@interoute.com

[cid:image001.jpg@01D21419.03FBFEB0]Interoute named Best Cloud Service Provider 
at the UK Cloud Awards 2016


[cid:image007.jpg@01D28870.32A3DC80] 

[cid:image005.png@01D28870.32A3DC80] 
   
[cid:image008.jpg@01D28870.32A3DC80]  
[cid:image009.jpg@01D28870.32A3DC80] 
  
[cid:image010.jpg@01D28870.32A3DC80] 



Interoute Communications Limited is a limited company registered in England and 
Wales.

Registered address: 31st Floor   25 Canada Square   Canary Wharf   London   E14 
5LQ
Registered number: 4472687



**
All quotes, offers or proposals are (i) made based on Interoute's standard 
terms and conditions (ii) subject to contract, survey and availability; and 
(iii) only valid for a period of 30 days from the date of this message.
Information transmitted in this message is intended only for the addressee and 
may contain confidential and/or privileged material.   If you have received 
this message in error, please send it back to us, and immediately and 
permanently delete it.   Information on our terms of confidentiality & how we 
process data, monitor communications and for terms of use can be found on our 
website at www.interoute.com
**




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

GPG, subkeys smartcard and computer

[Stefano Tranquillini]

Hi all,
I'm sort of new to GPG/PGP, I'm not new to the encryption/crypto world and
to computers, however, some concepts are yet not clear to me.

I can't get my head around on how to use GPG in the "correct" way to
guarantee the maximum result. That is: protect, at the best, my privacy and
also don't get the system too complicated.

The problems that I've are multiple, I'll try to summarize them here asking
for help. I've read the manual, but it's a bit outdated, and online I found
scattered information that does not always explain why some decision are
made.

My ideal setup is:

   - Master generated on offline pc and stored in a cold storage
   - subkeys for the pc (main pc, that I use everyday) - i need
   (A)utenticate (E)encrypt (S)ign keys
   - subkeys for the smartcard - if I use a pc of someone else, and as
   backup for what is worth. (In the future I may switch to just the
   smartcard, removing the keys from pc, but I would like to have the keys on
   the pc for time being)
   - I would like to avoid moving the master ouside the offline pc/cold
   storage

Create the master:

I should create the master on a device that is not my primary one and that
is not online. It seems kind of freak approach to me, but I can understand
why. Once created, I backup it to a file which I store on a usb key or
somewhere outside of computers. With the master I can create, later,
subkeys for what I need and the revoke certificate in case of compromised
subkeys.  Other than the master key, do I've to export anything else (not
talking of subkeys yet, that's next topic)?

When creating the master, I've two possibility: (i) use the dafault setting
that results in a (SC) key or (ii) set it as only (C). The best solution
seems to be the second, right? (
http://security.stackexchange.com/questions/32386/why-do-pgp-master-keys-only-have-a-single-subkey-and-tie-certification-with-sig).
Is it worth to use that approach or, as of today, the (i) is fine? I still
don't get the full benefit of one or the other solution

Create the subkey

With the master key I can create subkeys. I should do it from the offline
pc in which I created the key, or import the master in a pc and then create
the subkeys (it doesn't sound so safe though). Now:

   -  should each subkey be for only one scope (A) (S) (E) or is it fine if
  one key does  two or three scopes (ASE) or (SE)?
  - once subkeys are creted I've to export them and also their revoke
  certifications (do they have one)? correct?
  - I've a smartcard, but I've also a pc, should I create 6 subkeys, 2
  for A, 2 for S and 2 for E and move the 3 A S E to the yubikey and the
  other 3 to the pc?.
  - moving the keys on the smartcard is done via "keytocard" but to
  move the keys on the pc I've to export subkeys, will this export also the
  keys on the smartcard and then I'll need the smartcard to access some of
  those? how can I decide what to import where?
  - Do I've to rexport my public key or anything else to let the world
  know my subkeys?
  - Do I've to export anything else to achieve my scenario's goal?

Am I missing anything? Or is there anything that can guide me to achieving
my goals?

PS: Sorry for the long questions, but I can't find online something that
explains my scenario. Solutions are for base cases or for smart-card only.
Well, probably there's a guide, but I can't find it out.

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

Re: GPG homedir path length limit

[Werner Koch]

On Wed, 15 Feb 2017 18:12, d...@fifthhorseman.net said:

> Why does this need to be created manually?  Why not try to create it if
> possible the first time there's a chance to use it, no matter what?

So that the /var/run/user/ directory is not cluttered with many
directories.  Setting a different GNUPGHOME is an exception and thus it
is fine to require an explicit creation.  Remember that not /var/run
does not need to be a temporary directort - there is more than Linux in
this world.

> I personally like the simplicity and uniformity of "if /run/user/$(id
> -u)/ exists and is writable, then we will use it for the socketdir."

That is non-portable.


Salam-Shalom,

   Werner

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


pgpxDgUNrwL5v.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GPG homedir path length limit

[Werner Koch]

On Thu, 16 Feb 2017 10:12, jus...@g10code.com said:

> That is still wrong.  The length of the path of the socket is not
> limited in any way, the length of the path passed to connect is.

That is your experience from Linux but that is not in general true.  The
maximum length of a file length is limited and thus is the length of the
socket.  And that length limit depends on the file system

> I still believe we could have/should have made it just work with any
> home directory.

The reason why we switched to /var/run is to allow the use of remotely
mounted home directories without the redirect-file hack.  That this also
fixes build problems is merely a side effect.


Salam-Shalom,

   Werner

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


pgp6TqmZ4h2XC.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Expanding web-of-trust with subkey

[Teemu Likonen]

Daniel Kahn Gillmor [2017-02-15 13:46:13-05] wrote:

> right, so your use of "trust-model direct" switches the meaning of the
> "trust" flag from its usual "ownertrust" semantics to be what we'd
> normally call "validity".
>
> Note also that when you mark a key itself as "trusted" in this way,
> you're asking GnuPG to treat *all* user IDs on it as valid.

> So if the keyholder updates their key at some point in the future to
> add a new User ID, your GnuPG installation is going to blindly accept
> that User ID as legitimate.

Yes. I have also considered (and used a little) local signatures for the
same use case: local-sign a key after checking it on a web page or in a
tofu-like manner. Local signature can obviously validate only selected
user ids but so far I've concluded that signatures are too strong
statement for not really checked "seems ok" keys. I know that there are
certification levels (like "--default-cert-level 1") but it's just
simpler to use "trust-model direct" and define the level directly.
Changing the decision later is also easier.

> please be aware that if you switch from "trust-model direct" to
> "trust-model tofu+pgp", then your previous assignments of "trust" will
> transform into indications of "ownertrust".

That has been my assumption. Thanks for verifying.

-- 
/// Teemu Likonen   - .-..    //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///


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

Re: Problems with GPGME1.8 and Python 3.5 bindings

[Justus Winter]

Hi,

Jean-François Schaff  writes:

> Thank you Justus for your advice, I could fix that and use the lib
> from Python.

Good.

> I had not realized that both gpg and gpg2 are installed by default on
> Ubuntu 16.04 LTS.

How is that related to your problem?

> Do you know if there is any plan to better document the python
> bindings in the GPGME doc?

Yes, there are plans.  There currently is no documentation, because we
wanted to find a solution that would cover GPGME as well as all
bindings.  Last year we spoke about that at one of our hackathons, and
decided to give Sphinx a shot.

> I may be able to help with that if needed.

Help is always needed.  However, the first step is to integrate Sphinx
in our build system.  If you feel up to that, great!  We'd need a DCO
From you.  If you wanted to write documentation, also great, but that is
not what we need right now.


Cheers,
Justus


PS: You wrote almost the same mail yesterday.  That is not helping...


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

Re: Problems with GPGME1.8 and Python 3.5 bindings

[Jean-François Schaff]

Hi,

2017-02-13 11:46 GMT+01:00 Justus Winter :
> Hi :)
>
> Jean-François Schaff  writes:
>
>> I'm new to gpg, and trying to use the Python bindings included in
>> PGPME. I'm using Ubuntu 16.04 LTS.
>>
>> I have done the following things:
> ...
>> - compiled and installed gpgme-1.8.0
>>
>> Everything seems to build and install as expected, but when I finally
>> try to use the python package (import gpg) I get the following error:
>>
>> (venv) jfs@Danube-linux:~/webdev/mms$ python
>> Python 3.5.2 (default, Nov 17 2016, 17:05:23)
>> [GCC 5.4.0 20160609] on linux
>> Type "help", "copyright", "credits" or "license" for more information.
> import gpg
>> Traceback (most recent call last):
> ...
>> ImportError: 
>> /home/jfs/webdev/mms/venv/local/lib/python3.5/site-packages/gpg/_gpgme.cpython-35m-x86_64-linux-gnu.so:
>> symbol gpgme_pubkey_algo_string, version GPGME_1.1 not defined in file
>> libgpgme.so.11 with link time reference
>
> gpgme_pubkey_algo_string is new in GPGME 1.7.  This suggests that the
> version 1.8 that you built is not picked up.  How you resolve that is
> really up to you and your needs.  You could for example add the
> $your_install_prefix/lib to LD_LIBRARY_PATH in your bin/activate script.
>
>
> Cheers,
> Justus

Thank you Justus for your advice, I could fix that and use the lib
from Python. I had not realized that both gpg and gpg2 are installed
by default on Ubuntu 16.04 LTS.

Do you know if there is any plan to better document the python
bindings in the GPGME doc? I may be able to help with that if needed.

Cheers,
Jean-François

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

Aw: Re: Re: SmartCard v2.1 : factory reset fails

[Fib Moro]

Dear Yutaka,

> 
> Let us show more info about your key.  I'm afraid your key size
> is not the one OpenPGP card supports.  I tested RSA-2048 with
> OpenPGP card version 2.1, it works fine for me.
> -- 
> 

==
1. Moving keys to card
==

Using the correct default Admin PIN value of *12345678* I could now
successfully move private keys to card, which also set the PIN retry counter
correctly:

>
gpg/card> verify 
...
Key attributes ...: rsa4096 rsa4096 rsa4096
...
PIN retry counter : 3 3 3
...
<

Sofar so good.

===
2. Changing Admin PIN
===

However, one quite awkward behavior I noticed that I think caused a whole lot
confusion on my side. 

On a card after fresh factory-reset, the first thing I did was trying to set
Admin PIN:

>
gpg/card> admin
Admin commands are allowed

gpg/card> passwd
gpg: OpenPGP card no. DXXX detected

1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code
Q - quit

Your selection? 3
<

It then asks me to "Please enter the Admin PIN".
Now, in the believe that *123456789* was the correct default Admin PIN value,
I would enter this *wrong* value.
I am then prompted to enter "New Admin PIN" value and confirm that. 
Let's say I use the value *smartcardrocks*.
My change is then confirmed with;

>
PIN changed.
<

I would now be in the believe that *smartcardrocks* is the new correct Admin
PIN.
However, any subsequent command that would require the Admin PIN would fail
(e.g. moving keys to card, setting reset code, changing admin pin).

For example, when I try to set a new reset code I am asked to enter the Admin
PIN. 
I enter *smartcardrocks* I get "Error setting the Reset Code: Bad PIN".
I enter *12345678* I also get "Error setting the Reset Code: Bad PIN".

I seems the Admin PIN is then broken and set to an "unknown" value.

Can you replicate the above described behavior?

Thank you kindly.

fibmoro

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

Cannot decrypt with 1.4.21 but with 1.2.2

[Öberg Fredrik]

I work in an organization where we sometimes receive and send encrypted files. 
This is far from our core business and we are no experts on this, so please 
bear with me.
For managing the files, we use scripts calling gpg.exe. This is a Windows 
environment.
We have been running version 1.2.2 for ages but as we upgraded our server, we 
decided to upgrade GnuPG to 1.4.21. We use the simple installer for GnuPG 
Classic.

Yesterday we received an encrypted file which we couldn't decrypt. This is what 
happens:

C:\>c:\GnuPG_2016\gpg --homedir=C:\Keyring -d -v -v -o output.txt input.gpg
:pubkey enc packet: version 3, algo 16, keyid x
data: [2048 bits]
data: [2048 bits]
gpg: public key is 
gpg: using subkey  instead of primary key 

You need a passphrase to unlock the secret key for
user: "My organization"
2048-bit ELG-E key, ID , created 2009-09-16 (main key ID )

gpg: public key encrypted data: good DEK
:encrypted data packet:
length: unknown
gpg: encrypted with 2048-bit ELG-E key, ID , created 2009-09-16
  "My organization"
gpg: 3DES encrypted data
gpg: [don't know]: invalid packet (ctb=1b)
gpg: decryption okay
gpg: WARNING: message was not integrity protected
gpg: [don't know]: invalid packet (ctb=68)

Just to be sure, this is 1.4.21:

C:\>c:\GnuPG_2016\gpg --version
gpg (GnuPG) 1.4.21

My first guess was that the file was corrupted in some way, as we get if by ftp 
from one of our partners. After hashing and re-transfering the file we could 
rule out file corruption during transfer. Then I decided to try to decrypt the 
file using an older version of GnuPG, 1.2.2. Then decryption works with no 
problem:

C:\>c:\gnupg\gpg -d -v -v -o output.txt input.gpg
:pubkey enc packet: version 3, algo 16, keyid x
data: [2048 bits]
data: [2048 bits]
gpg: public key is 
gpg: using secondary key  instead of primary key 

You need a passphrase to unlock the secret key for
user: "My organization"
gpg: using secondary key  instead of primary key 
2048-bit ELG-E key, ID , created 2009-09-16 (main key ID )

gpg: public key encrypted data: good DEK
:encrypted data packet:
length: unknown
gpg: encrypted with 2048-bit ELG-E key, ID , created 2009-09-16
  "My organization"
gpg: 3DES encrypted data
:literal data packet:
mode b, created , name="",
raw data: 0 bytes
gpg: original file name=''
gpg: decryption okay
gpg: WARNING: message was not integrity protected

Version is 1.2.2:
C:\temp>c:\gnupg\gpg --version
gpg (GnuPG) 1.2.2

Can anybody explain what is happening? Why can we decrypt the file with an 
older version, but not with the newest one?

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

Re: GPG homedir path length limit

[Justus Winter]

Daniel Kahn Gillmor  writes:

> [ Unknown signature status ]
> Hi all--
>
> sorry for the late followup on this thread:
>
> On Mon 2017-01-16 14:16:28 -0500, Werner Koch wrote:
>> On Sun, 15 Jan 2017 00:39, gn...@jelmail.com said:
>>> Just experimenting in a sandbox homedir, I noticed that the homedir path
>>> needs to be below a certain size.
>>
>> That is because on most Unix systems the file name for local socket is
>> limited in size.  Local sockets are used for communication between the
>> components (e.g. gpg and gpg-agent).

That is still wrong.  The length of the path of the socket is not
limited in any way, the length of the path passed to connect is.

I still believe we could have/should have made it just work with any
home directory.


Justus


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