On Mon, Sep 21, 1998 at 08:57:05PM +0200, email@example.com 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.
Description: PGP signature