Patchwork [v4,0/3] zypper: support signed repositories

login
register
mail settings
Submitter Steve Sakoman
Date Jan. 31, 2012, 1:39 a.m.
Message ID <CAOSpxdZsOeOWuB5EcjFf5cN6kkMWzAaWXYue5m2OX_jwWQZEfw@mail.gmail.com>
Download mbox | patch
Permalink /patch/20369/
State New
Headers show

Comments

Steve Sakoman - Jan. 31, 2012, 1:39 a.m.
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

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:


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.

Steve


On Mon, Jan 30, 2012 at 3:56 PM, Saul Wold <sgw@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@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
>>
>
Steve Sakoman - Jan. 31, 2012, 3:54 a.m.
On Mon, Jan 30, 2012 at 7:23 PM, Saul Wold <sgw@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@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@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
>>>>
>>>
>>
>
Anders Darander - Jan. 31, 2012, 7:42 a.m.
* Steve Sakoman <steve@sakoman.com> [120131 06:32]:

> On Mon, Jan 30, 2012 at 7:23 PM, Saul Wold <sgw@linux.intel.com> wrote:
> > On 01/30/2012 05:39 PM, Steve Sakoman wrote:

> > 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.

I think you'll have to modify the oe-classic recipe to use GnuPG v1.4.7,
as it seems that GnuPG was relicensed to GPLv3 in 1.4.8... At least that
was the conclusion I came to when I looked at this last summer.
(Unfortunately, I didn't have time to work through it).

Cheers,
Anders
Steve Sakoman - Jan. 31, 2012, 4:50 p.m.
On Mon, Jan 30, 2012 at 11:42 PM, Anders Darander <anders@chargestorm.se> wrote:
> * Steve Sakoman <steve@sakoman.com> [120131 06:32]:
>
>> On Mon, Jan 30, 2012 at 7:23 PM, Saul Wold <sgw@linux.intel.com> wrote:
>> > On 01/30/2012 05:39 PM, Steve Sakoman wrote:
>
>> > 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.
>
> I think you'll have to modify the oe-classic recipe to use GnuPG v1.4.7,
> as it seems that GnuPG was relicensed to GPLv3 in 1.4.8... At least that
> was the conclusion I came to when I looked at this last summer.
> (Unfortunately, I didn't have time to work through it).

This makes me wonder whether libzypp/zypper is an appropriate long
term choice for those who want to avoid GPLv3.

The zypp project obviously made the choice to switch to GPLv3 years
ago and it will be an ongoing problem to try to support old versions
with GPLv2.

Perhaps yum would be a better choice for the GPLv3 averse, since IIRC
it is still GPLv2.

Steve
Anders Darander - Feb. 1, 2012, 11:11 a.m.
* Steve Sakoman <sakoman@gmail.com> [120131 17:50]:
> On Mon, Jan 30, 2012 at 11:42 PM, Anders Darander <anders@chargestorm.se> wrote:
> > * Steve Sakoman <steve@sakoman.com> [120131 06:32]:
> >> On Mon, Jan 30, 2012 at 7:23 PM, Saul Wold <sgw@linux.intel.com> wrote:
> >> > On 01/30/2012 05:39 PM, Steve Sakoman wrote:

> >> > 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.

> > I think you'll have to modify the oe-classic recipe to use GnuPG v1.4.7,
> > as it seems that GnuPG was relicensed to GPLv3 in 1.4.8... At least that
> > was the conclusion I came to when I looked at this last summer.
> > (Unfortunately, I didn't have time to work through it).

> This makes me wonder whether libzypp/zypper is an appropriate long
> term choice for those who want to avoid GPLv3.

> The zypp project obviously made the choice to switch to GPLv3 years
> ago and it will be an ongoing problem to try to support old versions
> with GPLv2.

> Perhaps yum would be a better choice for the GPLv3 averse, since IIRC
> it is still GPLv2.

How does yum handle the signatures? Does it also do it using
gpg/gpg2-commands? If so, we would probably have the same problem with
yum as with libzypp/zypper. (Possible without having to patch gpg2 ->
gpg, but as they are quite compatible, that should be a minor issue). We
would still have problems using later GnuPG 1.4.x...

Or is yum (or any other package manager) using GpgME? (The library
designed to make it easier for applications to interface with gpg). If
so, it should be OK, as gpgme is licensed under GPLv2(+?)

Cheers,
Anders
Koen Kooi - Feb. 1, 2012, 11:13 a.m.
Op 1 feb. 2012, om 12:11 heeft Anders Darander het volgende geschreven:

> * Steve Sakoman <sakoman@gmail.com> [120131 17:50]:
>> On Mon, Jan 30, 2012 at 11:42 PM, Anders Darander <anders@chargestorm.se> wrote:
>>> * Steve Sakoman <steve@sakoman.com> [120131 06:32]:
>>>> On Mon, Jan 30, 2012 at 7:23 PM, Saul Wold <sgw@linux.intel.com> wrote:
>>>>> On 01/30/2012 05:39 PM, Steve Sakoman wrote:
> 
>>>>> 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.
> 
>>> I think you'll have to modify the oe-classic recipe to use GnuPG v1.4.7,
>>> as it seems that GnuPG was relicensed to GPLv3 in 1.4.8... At least that
>>> was the conclusion I came to when I looked at this last summer.
>>> (Unfortunately, I didn't have time to work through it).
> 
>> This makes me wonder whether libzypp/zypper is an appropriate long
>> term choice for those who want to avoid GPLv3.
> 
>> The zypp project obviously made the choice to switch to GPLv3 years
>> ago and it will be an ongoing problem to try to support old versions
>> with GPLv2.
> 
>> Perhaps yum would be a better choice for the GPLv3 averse, since IIRC
>> it is still GPLv2.
> 
> How does yum handle the signatures? Does it also do it using
> gpg/gpg2-commands? If so, we would probably have the same problem with
> yum as with libzypp/zypper. (Possible without having to patch gpg2 ->
> gpg, but as they are quite compatible, that should be a minor issue). We
> would still have problems using later GnuPG 1.4.x...
> 
> Or is yum (or any other package manager) using GpgME? (The library
> designed to make it easier for applications to interface with gpg). If
> so, it should be OK, as gpgme is licensed under GPLv2(+?)

And is yum a binary or a script? I'm in the 'statically linked package manager' camp, so switching to a script is only going to make me sad ;)

regards,

Koen
Steve Sakoman - Feb. 1, 2012, 2:33 p.m.
On Wed, Feb 1, 2012 at 3:11 AM, Anders Darander <anders@chargestorm.se> wrote:
> * Steve Sakoman <sakoman@gmail.com> [120131 17:50]:
>> On Mon, Jan 30, 2012 at 11:42 PM, Anders Darander <anders@chargestorm.se> wrote:
>> > * Steve Sakoman <steve@sakoman.com> [120131 06:32]:
>> >> On Mon, Jan 30, 2012 at 7:23 PM, Saul Wold <sgw@linux.intel.com> wrote:
>> >> > On 01/30/2012 05:39 PM, Steve Sakoman wrote:
>
>> >> > 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.
>
>> > I think you'll have to modify the oe-classic recipe to use GnuPG v1.4.7,
>> > as it seems that GnuPG was relicensed to GPLv3 in 1.4.8... At least that
>> > was the conclusion I came to when I looked at this last summer.
>> > (Unfortunately, I didn't have time to work through it).
>
>> This makes me wonder whether libzypp/zypper is an appropriate long
>> term choice for those who want to avoid GPLv3.
>
>> The zypp project obviously made the choice to switch to GPLv3 years
>> ago and it will be an ongoing problem to try to support old versions
>> with GPLv2.
>
>> Perhaps yum would be a better choice for the GPLv3 averse, since IIRC
>> it is still GPLv2.
>
> How does yum handle the signatures? Does it also do it using
> gpg/gpg2-commands? If so, we would probably have the same problem with
> yum as with libzypp/zypper. (Possible without having to patch gpg2 ->
> gpg, but as they are quite compatible, that should be a minor issue). We
> would still have problems using later GnuPG 1.4.x...

I don't know what yum does, and to be honest I'm not too motivated to find out!

I'm happy with zypp/zypper and that is the reason for jumping through
hoops to get full support for signed repositories :-)

Yum was merely mentioned as an option for those who can't deal with GPLv3.

> Or is yum (or any other package manager) using GpgME? (The library
> designed to make it easier for applications to interface with gpg). If
> so, it should be OK, as gpgme is licensed under GPLv2(+?)

No idea on this one either!

Steve
Steve Sakoman - Feb. 1, 2012, 2:34 p.m.
On Wed, Feb 1, 2012 at 3:13 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>
> Op 1 feb. 2012, om 12:11 heeft Anders Darander het volgende geschreven:
>
>> * Steve Sakoman <sakoman@gmail.com> [120131 17:50]:
>>> On Mon, Jan 30, 2012 at 11:42 PM, Anders Darander <anders@chargestorm.se> wrote:
>>>> * Steve Sakoman <steve@sakoman.com> [120131 06:32]:
>>>>> On Mon, Jan 30, 2012 at 7:23 PM, Saul Wold <sgw@linux.intel.com> wrote:
>>>>>> On 01/30/2012 05:39 PM, Steve Sakoman wrote:
>>
>>>>>> 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.
>>
>>>> I think you'll have to modify the oe-classic recipe to use GnuPG v1.4.7,
>>>> as it seems that GnuPG was relicensed to GPLv3 in 1.4.8... At least that
>>>> was the conclusion I came to when I looked at this last summer.
>>>> (Unfortunately, I didn't have time to work through it).
>>
>>> This makes me wonder whether libzypp/zypper is an appropriate long
>>> term choice for those who want to avoid GPLv3.
>>
>>> The zypp project obviously made the choice to switch to GPLv3 years
>>> ago and it will be an ongoing problem to try to support old versions
>>> with GPLv2.
>>
>>> Perhaps yum would be a better choice for the GPLv3 averse, since IIRC
>>> it is still GPLv2.
>>
>> How does yum handle the signatures? Does it also do it using
>> gpg/gpg2-commands? If so, we would probably have the same problem with
>> yum as with libzypp/zypper. (Possible without having to patch gpg2 ->
>> gpg, but as they are quite compatible, that should be a minor issue). We
>> would still have problems using later GnuPG 1.4.x...
>>
>> Or is yum (or any other package manager) using GpgME? (The library
>> designed to make it easier for applications to interface with gpg). If
>> so, it should be OK, as gpgme is licensed under GPLv2(+?)
>
> And is yum a binary or a script? I'm in the 'statically linked package manager' camp, so switching to a script is only going to make me sad ;)

IIRC yum is a script.  It would make me sad too, and that is why I
intend to stick with libzypp/zypper for rpm based images.

Steve

Patch

--- 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