[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Duplicity-talk] gpg 1 or 2?
From: |
Scott Hannahs |
Subject: |
Re: [Duplicity-talk] gpg 1 or 2? |
Date: |
Mon, 13 Jul 2015 11:33:28 -0700 |
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