The main point of the signature is to allow the end-user to detect if a mirror site is holding tampered binary (or source) packages.
I agree that a signature system is a good idea for releases that are destined to be mirrored, but it just doesn't seem to be much of a high priority for snaps which are rebuilt every few hours, from potentially unstable code and intended to be used by people that are testing things (and thus are ready to deal with breakage). This is a moot issue: PHP 5 is alpha and there is no signature system in 4.3.x, so there is no more danger in providing an unsigned official PHP 4.3.x PECL extension than there is in forcing third parties to compile and distribute their own... By all means lets have a certification system in PHP 5 (provided someone steps forward and actually implements it, and volunteers to audit and review the code etc. etc), but there is no need to hold back people using 4.3.x in the meantime. The real question is how easy it is to prep the win32 snap building machine to fetch and build the latest stable versions of these PECL packages. --Wez. On Thu, 3 Apr 2003, Dan Kalowsky wrote: > On Thursday, April 3, 2003, at 07:52 AM, Christian Stocker wrote: > > > The ideas was not to add compiled extensions to snaps.php.net, but to > > compile them like all the other extensions are compiled on > > snaps.php.net. It just takes the source from pecl/whatever. The > > injection of bad code is much lower then (of course, someone could > > still > > inject bad code into CVS...) > > Until you get to third parties distributing the same option. Like I > said, I'd rather see a proper authentication mechanism in place before > this sort of thing is put into practice. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
