Abhilash, I see no reason to have more that one keyring for public keys and another for the private ones. In both cases, those key rings are a flat table indexed by the Key_id. It doesn't matter if the "owner" of the key is a list or a subscriber (or any other user) As for user keys, I think that they should be treated as a ManyToMany relation between the public keys and either the lists or users or, perhaps the subscriptions, in a manner similar to the way that Email addresses are associated with a user.
Wacky On Aug 13, 2013, at 9:46 AM, Abhilash Raj <[email protected]> wrote: > Hi all, > > After midterm evaluations I have been working on signing the message > using one the keys associated with the list, now since `python-gnupg` > does not allow selecting keys with key credentials( like address or > list-name name) so we need key_id. As barry suggested we can create a > mapping of address to key_ids and store in a seperate table. > > I was of the opinion that we need key_ids only for signing the content > and hence need to select only list's keys and not user, so can we add a > new column `key_id` to the existing list table? So that the key_id is > easily accessible as a list parameter and can be easily updated. One > point in this would be should we allow more than one key associated with > a user( or address? ). > Any comments on this? (barry?) > > Also I understand that keeping key safe is one of the important tasks > but for the time-being I am simply adding the public and secret keyrings > in "VAR_DIR/gpg/", all the list's private keys are in `secring.gpg` and > all the list's public keys are in `pubring.gpg` and all the user's > public keys are in `userring.gpg`. It will be changed to keep the secret > keys at a more safer location. > > --- > Abhilash Raj > _______________________________________________ > Mailman-Developers mailing list > [email protected] > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://wiki.list.org/x/AgA3 > Searchable Archives: > http://www.mail-archive.com/mailman-developers%40python.org/ > Unsubscribe: > http://mail.python.org/mailman/options/mailman-developers/rkw%40dataplex.net > > Security Policy: http://wiki.list.org/x/QIA9 _______________________________________________ Mailman-Developers mailing list [email protected] http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
