Re: [Duplicity-talk] gpg 1 or 2?

[Scott Hannahs]

Edgar

Thanks that explains the situation.  I am a bit unsure how to resolve it, but 
the issues are clear.  I think my best approach is just to only allow pgp 1.4.X 
binaries as a dependency.

The OS X Fink package manager allows installation of both gpg v1 and gpg v2.  
(or gnupg v1 and v2) simultaneously.  It installs all the packages in a 
separate directory structure to isolate from OS changes (i.e. not /usr/local 
but rather /sw).  The paths are modified to give this directory tree precedence 
over the defaults.  I think this is standard for many *nix installations as 
well so it should be an issue on other platforms.  Adding extra links in the 
/sw/bin directory can interfere with the installation of other packages and is 
frowned upon.  Also linking to other parts of the OS is considered fragile and 
not interfering with the OS is encouraged.

Thus the Path will point to the correct bin directory.  BUT to allow both gpgv1 
and gpgv2 in the same bin directory they have different file names for the 
binaries.  For obvious historical reasons gpg is version 1 of the software 
package and gpg2 is the version 2.x.x version.  If I can’t allow a setup 
parameter to point the correct binary path, then to use version 2 I can patch 
the code to change that string in gpginterface.py the package manager has a 
patching function, it is just more maintenance from version to version.

My next project is to get duply in the package manager as well….

-Scott


> On Jul 7, 2015, at 2:10 AM, address@hidden wrote:
> 
> On 07.07.2015 01:57, Scott Hannahs wrote:
>> Hmm, "works with either”?   
> 
> means, each and and every, but just one at a time ;))
> 
>> Fink which is the package manager for Mac OS X allows both versions to be 
>> installed simultaneously which are called gpg and gpg2 for the binaries.  
>> How does the gpginterface.py call these binaries?  
> 
> looking for a binary named gpg in PATH env var. fresh in trunk and still 
> unreleased is 
> https://code.launchpad.net/~ed.so/duplicity/gpg.binary/+merge/262540
> 
>> Does it accept gpg2 as the name of the binary in the default path?  
> 
> what's the advantage of gpg over gpg2, when both are installed?
> 
>> Do I need a setup directive to explicitly give the path to gpg2?
> 
> if you want to enforce gpg2 you can
> 
> 1. symlink eg. /usr/local/bin.duplicity/gpg -> /sw/bin/gpg2  and run 
> duplicity with PATH="/usr/local/bin.duplicity/:$PATH"
> 
> 2. download & install latest duplicity source and use the mentioned new 
> parameter
> 
> 3. dirty but quick, patch gpginterface.py around line 286 -> self.call = 'gpg'
> 
>> Unfortunately on my test machine I have /usr/local/gpg (classic) due to 
>> other software and /sw/bin/gpg2 as installed by fink and that I would prefer 
>> to have used by duplicity.  The PATH variable gives precedence to the 
>> /sw/bin/gpg2 but is it needed to specify which binary to use?  I assume this 
>> is in the internals of gpginterface.py?
> 
> try the standard *nix way. run duplicity with a modified PATH env var as 
> outlined above.
> 
> ..ede/duply.net
> 
>> 
>> -Scott
>> 
>>> On Jun 25, 2015, at 2:33 AM, address@hidden wrote:
>>> 
>>> On 23.06.2015 18:17, Scott Hannahs wrote:
>>>> Quick question…  Does duplicity use gpg version 1 or 2 or either?  The 
>>>> README say gpg v1.x but I thought I saw a revision that switched to gpg 
>>>> v2.x but I may be mistaken.  It seems to be working but I may have both 
>>>> versions installed on my system.
>>>> 
>>> 
>>> duplicity works with  either (as GnuPG calls them today)
>>> 
>>> GnuPG stable 2.0.x
>>> GnuPG modern 2.1.x
>>> GnuPG classic 1.4.x
>>> 
>>> be aware that they changed the way passphrases are piped into gpg when 
>>> using gpg " modern" 2.1.x , hence some gpg config setting have to be 
>>> modified. see https://sourceforge.net/p/ftplicity/bugs/76/
>>> 
>>> ..ede/duply.net
>>> 
> 
> _______________________________________________
> Duplicity-talk mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/duplicity-talk