You're right that it's a moot point for 4.3. But if we ever hope to have
PECL seen as a useful feature/functionality, now is the time to provide a
stable framework, not after something has gone wrong (and it doesn't have
to be from something we/PHP have done). The potential for damage that
this can cause is high. It's typically harder to re-gain trust, and this
is the cause of my hesitation to opening this up.
How many third-party extensions are out there that have been compiled by
someone other than our official snaps machine/Edin?
How long have they been available?
What about mirrors carrying win32 binaries for PHP itself?
Because it's already in practice doesn't automatically mean it's necessarily correct either.
Just because we have a pear command to install the binaries, it doesn't make things any more dangerous than they were before - the end user could always, at any time, download and install a bogus extension.
Because we have a pear command to download and install the binaries is exactly the reason why we have to be careful. If you are now auto-installing binaries without administrator interaction (beyond the 'get me this extension' idea), there had better be a way to check the authenticity of a binary once it's been downloaded.
We are not responsible for them doing that, and I don't see how our
image could suffer from an idiot installing software from an unofficial
mirror, just because we have a command line tool that helps them install
it. They need to have enough brains to know the command exists, and
then have enough brains to *type* the URL for the non-PHP.net site that
carries the package.
You're right there is nothing we can nor should do to stop idiots from installing unofficial extensions. But we can and should provide a means for an administrator to verify authenticity. What's to stop someone from claiming "go ahead install this extension, it's from PHP website I downloaded ABC ago"? Yes I realize it's a bad admin practice, but I also realize it happens (and sometimes it's policy).
Signatures are useful for mirroring purposes only; they just indicate the binary has not been tampered with since it was signed. The signature does not assert anything about the reliability of the code, unless we put into place a full blown audit of all PECL packages and sign with a different certificate. This will probably become too much of a burden for our volunteer network, particularly as PECL grows.
I disagree with regards to signatures, they are not useful for mirroring only.
I'm not arguing the reliability of the code, I'm arguing towards the validity of the download. The idea of the signature is exactly what I would like to see put in place (along with the hash inside the signature) before this is put to regular use.
So, its a pretty safe bet that any binaries built by the official php.net snaps machine are "certified". So why not make them available via snaps.php.net?
Go ahead make them available. I'd much rather seem them signed and certified before they are made available though.
We only really need digital signatures on officially released packages.
At the very least on officially released packages.
>---------------------------------------------------------------< Dan Kalowsky "I got my mojo working, but it http://www.deadmime.org/~dank just ain't working on you" [EMAIL PROTECTED] - "Mojo", [EMAIL PROTECTED] Muddy Waters
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
