Public key signing packages [was: Problems with new semantic package]

Ovidiu> I don't think the upgrade process is that easy. I'm not an Ovidiu> expert, but managing the public keys and all that, do Ovidiu> require some management effort, which translates into a Ovidiu> non-zero amount of design and code. I don't think it _requires_ any design or code, just that maintainers have keys and publish them. Preferably with multiple signings on public keyservers, of course. But all this is startup cost for maintainers, anyway. We could provide a simple startup guide and helper code, of course. Eg, my tarballs are signed. This is not at all trustworthy since those keys are not cross-signed by anybody. But it's just a couple of lines in my build script, and it would be easy for me to generate new keys, get them signed, etc., and away we go. Ovidiu> I'm not worried about package authors, I worry about the Ovidiu> bad guys modifying legitimate package to run malicious Ovidiu> code. Becoming a legitimate package author is the easiest way to do that. Ovidiu> At the very least we should make sure we don¹t get fooled Ovidiu> into installing malicious packages, and have open sockets Ovidiu> accepting connections from the Internet. Can't happen on XEmacs, yet: we don't have the "listen" socket code. When we do, it should be done as an ELL, and we should find some way to make that code unavailable without explicit operator intervention. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py