From: Saul Wold <sgw@linux.intel.com>
To: Steve Sakoman <steve@sakoman.com>
Cc: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH v4 0/3] zypper: support signed repositories
Date: Mon, 30 Jan 2012 15:56:10 -0800 [thread overview]
Message-ID: <4F272E1A.6040702@linux.intel.com> (raw)
In-Reply-To: <CAOSpxdajJLZSuzZS5qb4UPpjuS55ZWB=RR3a0oi9hNDF8J++Fw@mail.gmail.com>
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
>
next prev parent reply other threads:[~2012-01-31 0:04 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-30 21:12 [PATCH v4 0/3] zypper: support signed repositories Steve Sakoman
2012-01-30 21:12 ` [PATCH v4 1/3] libksba: add recipe for 1.2.0 Steve Sakoman
2012-01-30 21:12 ` [PATCH v4 2/3] gnupg: add recipe for 2.0.18 Steve Sakoman
2012-01-30 21:12 ` [PATCH v4 3/3] zypper: add missing runtime dependences on gzip and gnupg Steve Sakoman
2012-01-30 21:50 ` [PATCH v4 0/3] zypper: support signed repositories Saul Wold
2012-01-30 22:04 ` Steve Sakoman
2012-01-30 22:13 ` Saul Wold
2012-01-30 23:29 ` Steve Sakoman
2012-01-30 23:56 ` Saul Wold [this message]
2012-01-31 0:37 ` Steve Sakoman
2012-01-31 1:39 ` Steve Sakoman
[not found] ` <4F275EB2.1020308@linux.intel.com>
2012-01-31 3:54 ` Steve Sakoman
2012-01-31 7:42 ` Anders Darander
2012-01-31 16:50 ` Steve Sakoman
2012-02-01 11:11 ` Anders Darander
2012-02-01 11:13 ` Koen Kooi
2012-02-01 14:34 ` Steve Sakoman
2012-02-01 14:33 ` Steve Sakoman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F272E1A.6040702@linux.intel.com \
--to=sgw@linux.intel.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=steve@sakoman.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox