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

[Scott Hannahs]

Ede,

Yeah, I think I am going to go with the "depend on gpg1” explicitly.   I have 
the wrong dependence now but my system also has a gpg1 and so it works.  Not 
sure why I haven’t heard problem reports.  It may be that almost everyone who 
uses gpg has both 1 and 2!

When the 0.7.X branch has a switch (in the setup.py?) then I will start moving 
things to gpg2 dependencies.

Thanks for the help!!

-Scott



> On Jul 13, 2015, at 3:11 AM, address@hidden wrote:
> 
> Hey Scott,
> 
> not sure what your conclusion actually is now. but as i see it, after your 
> detailed explanation, your recipe for duplicity should 
> - depend on gpg1
> - or gpg2 (for duplicity 0.7.x, mind the next release will have the switch)
> 
> patching duplicity sounds like more hassle than necessary in your case.
> 
> it might make sense to have a "stable" 0.6.x package, as there are still some 
> changes that broke features formerly working in duplicity 0.6 . nothing 
> major, but usually easily "fixable" by simply using the "older" release.
> 
> ..ede
> 
> On 11.07.2015 21:08, Scott Hannahs wrote:
>> 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