[pacman-dev] [PATCH] (newgpg) Let pacman specify GnuPG's home directory.

[Gerhard Brauer]

Am Thu, 18 Dec 2008 10:22:25 -0600
schrieb "Aaron Griffin" <aaronmgriffin at gmail.com>:

> On Thu, Dec 18, 2008 at 7:02 AM, Gerhard Brauer <gerbra at archlinux.de>
> wrote:
> > I've not tested your patch (today evening maybe), but i am not very
> > happy with this triple state. If i choose to use a repo which offers
> > signed packages then i want the "full program", so if something
> > wrong with one package i don't want it get installed/upgraded.
> > And if i have a repo without signing then i don't put the option in
> > the repo section of pacman.conf.
> 
> I think "Optional" makes sense in some cases. Let's take the community
> repo, where things tend to be a hodge-podge of ideas and attitudes. I
> can imagine half the packages being signed, some being unsigned, and
> some being signed by keys not in the keyring.

If we wan't this (or if the [community] situation lead us to MUST wan't
this) then such a "Optional" is ok IMHO (with a pacman warning...)

But the question (also the TU's must discuss this) is: why not also
sign community packages per policy?
- The build tools (where signing is integrated) are both the same for
  developers and TUs.
- Also the TU's have the same interest like the devs that their
  packages are on good integrity when they leaves their machines and
  that this could be checked before the users installed these. (we make
  this signing thing not for funny ;-)
- Only TU's(and Devs) putting packages in community, so the count of
  needed keys is not soo much. But TUs come and go more often than
  Devs, so a separate keyring makes sense IMHO cause it changes often.

So if we find a solution to avoid this "Optional" setting, that would be
better IMHO.

(To clear: I'm neither a Dev nor a TU (and badly also not a C
programmer...), my suggestions comes most from the "user side" of this
theme... But i like always to say: "We" <g>)

Regards
	Gerhard