Everything

php

Home » Project » Newsgroups » php.internals » pecl binaries in PHP Win releases? »

pecl binaries in PHP Win releases?

php.internals

Christian Stocker

23 years ago

Hi

As it's quite hard/expensive for Windows users to compile their own
extensions, is there a possibility to add some PECL-extensions into the
Windows releases? Mainly there are ext/radius and ext/imagick, which I
know do compile on Windows (and wouldn't add that much to the download,
since ext/imagick for example does not statically compile the whole
imagemagick libraries)

Would be great, if someone could add them to the windows compile scripts
on snaps.php.net.

chregu

--
christian stocker | bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich
phone +41 1 240 56 70 | mobile +41 76 561 88 60 |  fax +41 1 240 56 71
http://www.bitflux.ch  |  chregu@bitflux.ch  |  gnupg-keyid 0x5CE1DECB

Jani Taskinen

23 years ago

On 3 Apr 2003, Christian Stocker wrote:

>As it's quite hard/expensive for Windows users to compile their own
>extensions, is there a possibility to add some PECL-extensions into the
>Windows releases? Mainly there are ext/radius and ext/imagick, which I
>know do compile on Windows (and wouldn't add that much to the download,
>since ext/imagick for example does not statically compile the whole
>imagemagick libraries)
>
>Would be great, if someone could add them to the windows compile scripts
>on snaps.php.net.

Why not make a separate package of the extra extensions..?

--Jani

Michael Bretterklieber

23 years ago

Hi,

Jani Taskinen schrieb:

> On 3 Apr 2003, Christian Stocker wrote:
>
>
>>As it's quite hard/expensive for Windows users to compile their own
>>extensions, is there a possibility to add some PECL-extensions into the
>>Windows releases? Mainly there are ext/radius and ext/imagick, which I
>>know do compile on Windows (and wouldn't add that much to the download,
>>since ext/imagick for example does not statically compile the whole
>>imagemagick libraries)
>>
>>Would be great, if someone could add them to the windows compile scripts
>>on snaps.php.net.
>
>
>     Why not make a separate package of the extra extensions..?
>

in general its a good idea, but I'm thinking about how
Webspace-Providers are installing and maintaining PHP, everything what
is not in the "standard" distribution doesen't exist for them.
It's already a problem to convince them installing additional "standard"
extensions or PEAR.

One possibility would be to move nearly (some extensions should stay in
the PHP-dist like DB-extensions) all extensions to this extra package,
then they have no chance to come around installing this extra package.

bye,

--
------------------------------- ----------------------------------
Michael Bretterklieber          - Michael.Bretterklieber@jawa.at
JAWA Management Software GmbH   - http://www.jawa.at
Liebenauer Hauptstr. 200        -------------- privat ------------
A-8041 GRAZ                     GSM: ++43-(0)676-84 03 15 712
Tel: ++43-(0)316-403274-12      E-mail: michael@bretterklieber.com
Fax: ++43-(0)316-403274-10      http://www.bretterklieber.com
------------------------------- ----------------------------------
"...the number of UNIX installations has grown to 10, with more
expected..." - Dennis Ritchie and Ken Thompson, June 1972

Christian Joergensen

23 years ago

-----Original Message-----
From: Michael Bretterklieber [mailto:mbretter@jawa.at]
Sent: Thursday, April 03, 2003 1:24 PM
To: Jani Taskinen
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] pecl binaries in PHP Win releases?

> in general its a good idea, but I'm thinking about how
> Webspace-Providers are installing and maintaining PHP, everything what
> is not in the "standard" distribution doesen't exist for them.
> It's already a problem to convince them installing additional "standard"
> extensions or PEAR.

You can always make your own PEAR installation altering the include_path
at runtime. I'm not sure if you can do the same thing with PECL libraries
using dl() and extension_dir. Could anyone elaborate? :-)

--
Christian Joergensen | Shockwaved            | p: [+45] 70 27 22 27
Code poet            | http://shockwaved.com | f: [+45] 33 69 11 74

Michael Bretterklieber

23 years ago

Christian Joergensen schrieb:

> -----Original Message-----
> From: Michael Bretterklieber [mailto:mbretter@jawa.at]
> Sent: Thursday, April 03, 2003 1:24 PM
> To: Jani Taskinen
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] pecl binaries in PHP Win releases?
>
>
>>in general its a good idea, but I'm thinking about how
>>Webspace-Providers are installing and maintaining PHP, everything what
>>is not in the "standard" distribution doesen't exist for them.
>>It's already a problem to convince them installing additional "standard"
>>extensions or PEAR.
>
>
> You can always make your own PEAR installation altering the include_path
> at runtime. I'm not sure if you can do the same thing with PECL libraries
> using dl() and extension_dir. Could anyone elaborate? :-)

sure you can, but - hehehe - only if
- dl() is not deactivated via php.ini
- safe_mode is not activated
- and dl() is also not supported on multithreaded servers.

bye,

--
------------------------------- ----------------------------------
Michael Bretterklieber          - Michael.Bretterklieber@jawa.at
JAWA Management Software GmbH   - http://www.jawa.at
Liebenauer Hauptstr. 200        -------------- privat ------------
A-8041 GRAZ                     GSM: ++43-(0)676-84 03 15 712
Tel: ++43-(0)316-403274-12      E-mail: michael@bretterklieber.com
Fax: ++43-(0)316-403274-10      http://www.bretterklieber.com
------------------------------- ----------------------------------
"...the number of UNIX installations has grown to 10, with more
expected..." - Dennis Ritchie and Ken Thompson, June 1972

Dan Kalowsky

23 years ago

On Thursday, April 3, 2003, at 05:30  AM, Christian Stocker wrote:

> As it's quite hard/expensive for Windows users to compile their own
> extensions, is there a possibility to add some PECL-extensions into the
> Windows releases? Mainly there are ext/radius and ext/imagick, which I
> know do compile on Windows (and wouldn't add that much to the download,
> since ext/imagick for example does not statically compile the whole
> imagemagick libraries)

There was talk of providing PECL binary download system awhile back for
users of Windows (and potentially OS X).  The biggest problem with
providing such a service was PHP had no infrastructure to certify
releases.  AKA an end user had no way to authenticate and prove that a
binary download originated from and is issued by the PHP Group.

Marko Karrapinen had written up a proposal for doing just this in
August 2002, but unfortunately, it hadn't gone much further than that.

> Would be great, if someone could add them to the windows compile
> scripts
> on snaps.php.net.

I would like to suggest that this NOT happen until we can provide an
authorization mechanism.  All it takes is one rogue extension compiled
and written by someone outside of the PHP Group to destroy the already
fragile trust in the PECL system.

>---------------------------------------------------------------<

Dan Kalowsky                    "Momma take this badge offa me,
http://www.deadmime.org/~dank    I can't use it anymore."
dank-nom@aps-deadmime.org        - "Knockin on Heavens Door",
kalowsky@php.net                        Bob Dylan

Christian Stocker

23 years ago

On Thu, 2003-04-03 at 14:42, Dan Kalowsky wrote:

> On Thursday, April 3, 2003, at 05:30  AM, Christian Stocker wrote:
>
> > As it's quite hard/expensive for Windows users to compile their own
> > extensions, is there a possibility to add some PECL-extensions into the
> > Windows releases? Mainly there are ext/radius and ext/imagick, which I
> > know do compile on Windows (and wouldn't add that much to the download,
> > since ext/imagick for example does not statically compile the whole
> > imagemagick libraries)
>
> There was talk of providing PECL binary download system awhile back for
> users of Windows (and potentially OS X).  The biggest problem with
> providing such a service was PHP had no infrastructure to certify
> releases.  AKA an end user had no way to authenticate and prove that a
> binary download originated from and is issued by the PHP Group.
>
> Marko Karrapinen had written up a proposal for doing just this in
> August 2002, but unfortunately, it hadn't gone much further than that.
>
> > Would be great, if someone could add them to the windows compile
> > scripts
> > on snaps.php.net.
>
> I would like to suggest that this NOT happen until we can provide an
> authorization mechanism.  All it takes is one rogue extension compiled
> and written by someone outside of the PHP Group to destroy the already
> fragile trust in the PECL system.

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...)

chregu

>
>  >---------------------------------------------------------------<
> Dan Kalowsky                    "Momma take this badge offa me,
> http://www.deadmime.org/~dank    I can't use it anymore."
> dank-nom@aps-deadmime.org        - "Knockin on Heavens Door",
> kalowsky@php.net                        Bob Dylan

--
christian stocker | bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich
phone +41 1 240 56 70 | mobile +41 76 561 88 60 |  fax +41 1 240 56 71
http://www.bitflux.ch  |  chregu@bitflux.ch  |  gnupg-keyid 0x5CE1DECB

Dan Kalowsky

23 years ago

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.

>---------------------------------------------------------------<

Dan Kalowsky                    "Thought I'd visit the club,
http://www.deadmime.org/~dank    Got as far as the door."
dank-nom@aps-deadmime.org      - "Don't Get Around Much Anymore",
kalowsky@php.net                        Ella Fitzgerald

Wez Furlong

23 years ago

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:

Dan Kalowsky

23 years ago

On Thu, 3 Apr 2003, Wez Furlong wrote:

> 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).

I'm of the opinion that once we start down this path it cannot be
retracted.  Thus, we should take every step possible to ensure it is done
right, and not in a half-assembled manner as this proposal requests.

> 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...

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.

> 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.

Once again it would need to be defined and written at the very least.

> 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.

Thats a question I don't know.

>---------------------------------------------------------------<

Dan Kalowsky			"I'll walk a thousand miles just
http://www.deadmime.org/~dank	 to slip this skin."
dank-nom@aps-deadmime.org	 - "Streets of Philadelphia",
kalowsky@php.net		 	Bruce Springsteen

Wez Furlong

23 years ago

On Thu, 3 Apr 2003, Dan Kalowsky wrote:

> I'm of the opinion that once we start down this path it cannot be
> retracted.  Thus, we should take every step possible to ensure it is done
> right, and not in a half-assembled manner as this proposal requests.

How is this different from building any of the other extensions as DLLs
and including them in the snapshot?

> 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?

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.

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.

They could even install it by hand.

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.

However, since a great many people watch the CVS, any outright malicious
code would be detected immediately.

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?

We only really need digital signatures on officially released packages.

--Wez.

Dan Kalowsky

23 years ago

On Thursday, April 3, 2003, at 03:46  PM, Wez Furlong wrote:

>> 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"
dank-nom@aps-deadmime.org        - "Mojo",
kalowsky@php.net                        Muddy Waters

Wez Furlong

23 years ago

On Thu, 3 Apr 2003, Dan Kalowsky wrote:

> On Thursday, April 3, 2003, at 03:46  PM, Wez Furlong wrote:
> > 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.

The point is that there has been plenty of opportunity for someone to
screw up in the past; continuing as we are does not increase the risk.

> 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.

You will find that, in practice, the administrator will be the person
running the pear command under win32.

> 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).

But that is no different from the current situation.
(And thus not inherently more dangerous)

> 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 validity of the download is partly what I am referring to when
I mention mirroring.

> > 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.

I think that you will have to settle for signed and implicitly certified
when the infrastructure is in place, unless someone volunteers to review
every line of code in every pecl package each time it is updated.

For now, I see no reason not to make them available (provided that its
not too much effort for Edin to set up the build env on the snaps
machine).

--Wez.

Christian Stocker

23 years ago

> For now, I see no reason not to make them available (provided that its
> not too much effort for Edin to set up the build env on the snaps
> machine).

I agree here completely with Wez, I don't see a difference between
compiling extensions from php4/ext to compiling pear/PECL extensions on
snaps. It's more or less the same deal, except that it's in another
directory.

The main problem is that there is no infrastructure right now to provide
binaries within PEAR/PECL, so there's no pear commandline command to
install those packages at all without recompiling. And not everyone has a
compiler on Windows nor do they know, how to compile something. I have the
possibility to compile some PECL extensions for Windows and put them
online for downloading, but I don't see a reason to do that (besides that
the windows compiler is not on my box and I have to wait for an
opportunity to use it), when we have such a nice infrastructure with the
snaps thingy (and the great work of Edin). We don't even have to include
them in the offficial release, but maybe just add an additional
zip-package with the PECL extensions.

And what happens with all those extensions, which are moved from php4/ext
to pear/PECL? Are there no windows extension available for them anymore?
Or were there never anyway? (I don't know to how many extensions that
happened already..)

chregu

Shane Caraveo

23 years ago

Dan Kalowsky wrote:

>
> I would like to suggest that this NOT happen until we can provide an
> authorization mechanism.  All it takes is one rogue extension compiled
> and written by someone outside of the PHP Group to destroy the already
> fragile trust in the PECL system.
>

Is *any* windows binary distribution from php and mirrors signed via an
authorization mechanism?  There's an MD5, but that's on a web page which
is also mirrored.  Though trust in PECL may be a valid argument.

Shane