[OE-core] [PATCH v4 0/3] zypper: support signed repositories

[Steve Sakoman]

On Mon, Jan 30, 2012 at 7:23 PM, Saul Wold <sgw at linux.intel.com> wrote:
> On 01/30/2012 05:39 PM, Steve Sakoman wrote:
>>
>> I took a quick look at the zypper code and discovered that the gpg2
>> dependency actually comes from the libzypp (package/libzypp.spec
>> excerpt):
>>
>> %if 0%{?suse_version}
>> Requires:       gpg2
>> %else
>> Requires:       gnupg2
>> %endif
>>
> So, should your DEPENDS patch really be against libzypp instead of zypper?

Yes.  In fact, though it isn't called out explicitly in libzypp.spec,
the libzypp source code does indeed make use of gzip so both runtime
dependencies in my original patch belong with libzypp and not zypper.

Can you feel a v5 coming?

>> That said, the gpg2 utility seems to be quite compatible with gpg
>> (version 1.x), so we may get away with using an earlier version of
>> gnupg with GPLv2.
>>
>> The required patch for libzypp is quite simple:
>>
>> --- git/zypp/KeyRing.cc-orig    2012-01-30 17:26:49.000000000 -0800
>> +++ git/zypp/KeyRing.cc 2012-01-30 17:27:57.000000000 -0800
>> @@ -37,7 +37,7 @@ using namespace zypp::filesystem;
>>  #undef  ZYPP_BASE_LOGGER_LOGGROUP
>>  #define ZYPP_BASE_LOGGER_LOGGROUP "zypp::KeyRing"
>>
>> -#define GPG_BINARY "/usr/bin/gpg2"
>> +#define GPG_BINARY "/usr/bin/gpg"
>>
>>  ///////////////////////////////////////////////////////////////////
>>  namespace zypp
>>
>> Of course you'll need to import the older gnupg recipe from oe-classic
>> to test this - not sure I should touch that since I've been poking
>> through the GPLv3 version of gnupg..
>>
>> Since the gnupg v2 package has a symlink from gpg to gpg2 the above
>> patch should work just fine with the new code too.  I'll test&
>> verify.
>>
> I will wait to pull this until I hear back from you with another pull
> request.  Thanks for digging into this, better to get it solved now then
> figure it out later that we missed a GPLv2 dependency.

I'll do a build with the libzypp RDEPENDS change and verify no issues,
and then a test build with the gpg2 -> gpg change and verify that too.

If it works, then that patch should likely get bundled with the
introduction of a GnuPG V1.4.10 recipe import from oe-classic.

Steve

>> Steve
>>
>>
>> On Mon, Jan 30, 2012 at 3:56 PM, Saul Wold<sgw at linux.intel.com>  wrote:
>>>
>>> On 01/30/2012 03:29 PM, Steve Sakoman wrote:
>>>>
>>>>
>>>> On Mon, Jan 30, 2012 at 2:13 PM, Saul Wold<sgw at linux.intel.com>
>>>>  wrote:
>>>>
>>>>> This would imply that we need to have a GPLv2 Version of the gnupg
>>>>> recipe also, Steve if you had to look at or handle the newer GPLv3
>>>>> gnupg
>>>>> code itself, you may not be able to write the GPLv2 recipe or create
>>>>> patches
>>>>> for it, can you arrange for someone to create that patch?
>>>>
>>>>
>>>>
>>>> OE-classic has a recipe for gnupg-1.4.10, so perhaps the safest
>>>> approach would be to import that recipe since I *have* browsed the
>>>> gnupg v2 code.
>>>>
>>> You mean v3 code no doubt.
>>>
>>>
>>>> I know from experience that signed repositories won't work for that
>>>> version as-is.  Zypper explicitly uses gpg2.
>>>>
>>> Any idea how much work there is there? Do you know of anyone that can
>>> help
>>> out with this?
>>>
>>>
>>>> It *may* be that gpg and gpg2 are compatible enough that you could get
>>>> away with a symlink and a v1.x version of gnupg.  Or perhaps one could
>>>> patch zypper to try gpg if gpg2 isn't present.  Thoughts?
>>>>
>>> I think it would be clearer if we patch zypper for gpg instead of hiding
>>> behind a symlink.  Other tools that may want to use gpg2 might get the
>>> wrong
>>> thing.
>>>
>>> Another possibility would be disable signed repos for non-GPLv3, but I am
>>> not wild about that idea since it's highly likely that a commercial
>>> vendor
>>> would want to provide signed repos in a non-GPLv3 device for security and
>>> sanity.
>>>
>>> Sau!
>>>
>>>
>>>> Steve
>>>>
>>>
>>
>