[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Uploaded dpkg 1.4.0.28 (source i386 all) to master



On Mon, Sep 21, 1998 at 08:57:05PM +0200, jdassen@wi.leidenuniv.nl wrote:
> [GPG support for dpkg]
> > 	I think this is a important, if not grave, bug in dpkg. Any
> >  move of this magnitude should be discussed, possibly written into
> >  policy, and care should be taken that the rest of the system is ready
> >  for it. 
> 
> I believed there to be concensus that GPG support was a good thing, and
> ought to be implemented ASAP. (For instance, some people can't currently
> develop Debian packages as they refuse to use PGP because of non-freeness).

Then make gpg the optional with possibly some env setting to allow using it
by default?  This seems the correct approach.


> > 	That is not good enough. Until dinstall is in place, the
> >  default should be with pgp. As such, dpkg is broken.
> 
> You might want to remove this version of dpkg from Incoming then.
> 
> I consider this a problem with dinstall, rather than dpkg. Dpkg now defaults
> to a using a free software package for signing source and binary packages;
> free software is what Debian is about.

Yes, that's good and all, but gpg still has a few weaknesses.  As I said,
the appropriate option seems to be support, but not default at this time.


> >  J> If GPG signing cannot be done, the code falls back to using PGP. If GPG
> >  J> signing can be done, but you wish to use PGP signing, you can use the
> >  J> argument "-ppgp -spgp".
> > 
> > 	I have a gpg key that I am using to play with gpg (so I do
> >  have a basis for my judgement that gpg is not yet ready for
> >  prime-time). 
> 
> I'm using gpg too; while it is not flawless, it is usable in my opinion.

Keyring management is a mess at this time.  I will happily switch to it once
I have finished collecting wanted info about the algorithms it uses and the
keyring management support is more refined.

A nice piece of gtk-based (tty or gui, like gdialog and other things) or
maybe just slang-based code which manipulates gpg keyrings and the like
might be a welcome thing..  I'm probably not the only one who misses my
generic dos pgp shell to automate common tasks.  mutt does some of those
related to email, but I loved how my last shell would do all kinds of things
for me---including dealing with multiple public keyrings, something that is
NOT easy to do in mutt.


> > 	dpkg should not make changes of this magnitude without
> >  discussion and approval of the policy group.
> 
> The issue of supporting GPG has come up in a "release goals" discussion;
> there seemed to be no significant objections.

I still believe optional non-default gpg is best right now.  I think rc
would be a good time to make it default with pgp being the option, depending
on the upstream authors or someone making 3rd party software to manage
things gpg does not.


> > 	I must say I am getting concerned about the numerous NMU's for
> >  a package as important as dpkg, and such ill considered changes are
> >  rather the last straw. Ian mentoned recently that dpkg has come to
> >  the top of his list of things to do, perhaps he should rein in all
> >  these NMU's floating around?
> 
> I'd like to see Ian take control of dpkg again. Prior to uploading this dpkg
> NMU I asked him whether he'd mind my changes; he didn't.

I don't MIND the changes either---I'd deal with pgp until things settled for
ISP or I got a version of gpg or addon that could handle things like
removing dead addresses from a key.

Attachment: pgp3PwH18VZpg.pgp
Description: PGP signature


Reply to: