Just a quick side one, there's no way to make compatible calls from mcrypt
to openssl using "rijndael-192" and "rijndael-256" ciphers, a compatibility
layer is almost impossible. Only AES-128/192/256 (which variants of
"rijndael-128") are possible on both extensions.
On Mon, Feb 9, 2015 at 6:47 PM
Le 02/02/2015 20:11, Anatol Belski a écrit :
https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
voting. Each item is voted separately. The voting ends on 2015-02-09 at
21:00 CET.
Hi,
After discussing this RFC with other people at AFUP (we weren't that
many to participate in
Hi Jan,
On Wed, February 4, 2015 11:13, Jan Schneider wrote:
>
> Zitat von Anatol Belski :
>
>
>> Hi Stas,
>>
>>
>> On Wed, February 4, 2015 07:51, Stanislav Malyshev wrote:
>>
>>> Hi!
>>>
>>>
>>>
And at list this one living native PHP implementation
https://github.com/horde/horde/tree/
Hi Tony,
On Wed, February 4, 2015 10:56, Tony Marston wrote:
> "Pierre Joye" wrote in message
> news:CAEZPtU6au_Fi2bW=e2kiqlerq4h97vhu8nkl-z9katlstef...@mail.gmail.com...
>
>>
>> On Wed, Feb 4, 2015 at 2:09 PM, Stanislav Malyshev
>>
>> wrote:
>>
>>> Hi!
>>>
>>>
Libmcrypt is a dead cow but n
Zitat von Anatol Belski :
Hi Stas,
On Wed, February 4, 2015 07:51, Stanislav Malyshev wrote:
Hi!
And at list this one living native PHP implementation
https://github.com/horde/horde/tree/master/framework/Imap_Client/ (and
more library links in the older thread link above).
This is part o
"Pierre Joye" wrote in message
news:CAEZPtU6au_Fi2bW=e2kiqlerq4h97vhu8nkl-z9katlstef...@mail.gmail.com...
On Wed, Feb 4, 2015 at 2:09 PM, Stanislav Malyshev
wrote:
Hi!
Libmcrypt is a dead cow but not much of a threat for now. On the other
hand cclient is dangerous, it should have been remo
Hi Stas,
On Wed, February 4, 2015 07:51, Stanislav Malyshev wrote:
> Hi!
>
>
>> And at list this one living native PHP implementation
>> https://github.com/horde/horde/tree/master/framework/Imap_Client/ (and
>> more library links in the older thread link above).
>
> This is part of Horde with 9 li
On Wed, Feb 4, 2015 at 4:01 PM, Stanislav Malyshev wrote:
> Hi!
>
>> However, I totally fail to understand your reasoning. We know both
>> libraries are dead. ext/Imap is almost not used anymore by any major
>
>
> What you mean by "major tool relying on imap"? I've used ext/imap
> multiple times i
Hi!
> However, I totally fail to understand your reasoning. We know both
> libraries are dead. ext/Imap is almost not used anymore by any major
What you mean by "major tool relying on imap"? I've used ext/imap
multiple times in the past, and I know others do too. Of course, there
are different l
On Wed, Feb 4, 2015 at 2:09 PM, Stanislav Malyshev wrote:
> Hi!
>
>> Libmcrypt is a dead cow but not much of a threat for now. On the other
>> hand cclient is dangerous, it should have been removed long time ago
>> already.
>
> I'm not sure - what is the dangerous part? Are you referring to some
>
Hi!
> Libmcrypt is a dead cow but not much of a threat for now. On the other
> hand cclient is dangerous, it should have been removed long time ago
> already.
I'm not sure - what is the dangerous part? Are you referring to some
published CVEs or other reports? Then it would be useful to list them
On Feb 4, 2015 1:51 PM, "Stanislav Malyshev" wrote:
>
> Hi!
>
> > And at list this one living native PHP implementation
> > https://github.com/horde/horde/tree/master/framework/Imap_Client/ (and
> > more library links in the older thread link above).
>
> This is part of Horde with 9 listed depende
On Feb 4, 2015 1:30 PM, "Stanislav Malyshev" wrote:
>
> Hi!
>
> I am kind of surprised that RFC about removing whole extensions has
> "Backward Incompatible Changes" listed as "None". Really? No BC impact
> whatsoever by removing imap and mcrypt? Literally nobody ever anywhere
> is using it?
>
> >
Hi!
> And at list this one living native PHP implementation
> https://github.com/horde/horde/tree/master/framework/Imap_Client/ (and
> more library links in the older thread link above).
This is part of Horde with 9 listed dependencies and 9 suggested ones,
and probably also sub-dependencies. It
Hi!
> We keep discussing how to improve security, make php safer by default, etc.
> But for IMAP, you basically open the door with a big shield saying "come
> in, we have free cooking and you can do almost all you want inside via this
> door". This is insane. If it was only up to me I would kick i
Hi!
I am kind of surprised that RFC about removing whole extensions has
"Backward Incompatible Changes" listed as "None". Really? No BC impact
whatsoever by removing imap and mcrypt? Literally nobody ever anywhere
is using it?
> - ext/imap and ext/mcrypt: while I realise that the underlying
> lib
"Anatol Belski" in php.internals (Tue, 3 Feb 2015 09:11:18 +0100):
>Hi Michael,
>
>On Tue, February 3, 2015 08:31, Michael Wallner wrote:
>> On 3 Feb 2015 08:10, "Adam Harvey" wrote:
>
>> I understand your thoughts. How about if we do for mcrypt what we did for
>> mhash, I.e. implement a compatibl
On 03/02/15 12:37, Rowan Collins wrote:
> For what it's worth, we've been running a Linux + MS SQL setup for
> around 10 years, due to a previous migration from Classic ASP to PHP. We
> originally used ext/mssql, and moved to ext/pdo_dblib with PHP 5.4
> (previous versions didn't support nextRowset
Pierre Joye wrote on 03/02/2015 09:14:
On Feb 3, 2015 4:06 PM, "Lester Caine" wrote:
On 03/02/15 08:44, Matteo Beccati wrote:
Marius Adrian Popa has stated to maintain both, and looks like there
several active users who will use that. So going by that, it's not
being
voted on these exts.
I
On 03/02/15 09:14, Pierre Joye wrote:
>> I wonder if ANY mssql users have noticed that they may be left out of
>> PHP7 ... I suspect that may actually have a bigger user base than the
>> paid for 'Interbase' yet it's got no support here.
>
> For mssql, most of them (while we see more and more requ
On Feb 3, 2015 4:06 PM, "Lester Caine" wrote:
>
> On 03/02/15 08:44, Matteo Beccati wrote:
> >> Marius Adrian Popa has stated to maintain both, and looks like there
> >> several active users who will use that. So going by that, it's not
being
> >> voted on these exts.
> >
> > I must have missed th
On 03/02/15 08:44, Matteo Beccati wrote:
>> Marius Adrian Popa has stated to maintain both, and looks like there
>> several active users who will use that. So going by that, it's not being
>> voted on these exts.
>
> I must have missed that, sorry for the noise.
This is a bit of the problem here.
On Feb 3, 2015 2:10 PM, "Adam Harvey" wrote:
>
> On 3 February 2015 at 03:11, Anatol Belski wrote:
> > properly after the voting phase the
> > https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
> > voting. Each item is voted separately. The voting ends on 2015-02-09 at
> > 21:00
On 03/02/2015 09:39, Anatol Belski wrote:
Marius Adrian Popa has stated to maintain both, and looks like there
several active users who will use that. So going by that, it's not being
voted on these exts.
I must have missed that, sorry for the noise.
Cheers
--
Matteo Beccati
Development & Co
Hi Matteo,
On Tue, February 3, 2015 09:09, Matteo Beccati wrote:
> On 02/02/2015 20:21, Lester Caine wrote:
>
>> On 02/02/15 19:11, Anatol Belski wrote:
>>
>>> properly after the voting phase the
>>> https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
>>> voting. Each item is vote
Hi Michael,
On Tue, February 3, 2015 08:31, Michael Wallner wrote:
> On 3 Feb 2015 08:10, "Adam Harvey" wrote:
> I understand your thoughts. How about if we do for mcrypt what we did for
> mhash, I.e. implement a compatible layer on top of openssl? I have not
> checked if it's even possible yet
On 02/02/2015 20:21, Lester Caine wrote:
On 02/02/15 19:11, Anatol Belski wrote:
properly after the voting phase the
https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
voting. Each item is voted separately. The voting ends on 2015-02-09 at
21:00 CET.
I feel this is totally ou
Hi Adam,
thanks for the explanations.
On Tue, February 3, 2015 08:10, Adam Harvey wrote:
> On 3 February 2015 at 03:11, Anatol Belski wrote:
>
>> properly after the voting phase the
>> https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
>> voting. Each item is voted separately.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 03/02/2015 08:10, Adam Harvey a écrit :
> To explain my -1s:
>
> - ext/imap and ext/mcrypt: while I realise that the underlying
> libraries are dead,
This means, if we want to keep them, we have to take ownership and
maintain those libraries.
Do
On 3 Feb 2015 08:10, "Adam Harvey" wrote:
>
> On 3 February 2015 at 03:11, Anatol Belski wrote:
> > properly after the voting phase the
> > https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
> > voting. Each item is voted separately. The voting ends on 2015-02-09 at
> > 21:00 CE
On 3 February 2015 at 03:11, Anatol Belski wrote:
> properly after the voting phase the
> https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
> voting. Each item is voted separately. The voting ends on 2015-02-09 at
> 21:00 CET.
To explain my -1s:
- ext/imap and ext/mcrypt: whil
Hi Andrea,
On Mon, February 2, 2015 23:54, Andrea Faulds wrote:
> Hi Danack,
>
>
>> On 2 Feb 2015, at 22:50, Dan Ackroyd wrote:
>>
>>
>> On 2 February 2015 at 19:11, Anatol Belski
>> wrote:
>>
>>> The voting ends on 2015-02-09 at 21:00 CET.
>>>
>>
>> This is a ridiculously short voting period fo
Hi Danack,
> On 2 Feb 2015, at 22:50, Dan Ackroyd wrote:
>
> On 2 February 2015 at 19:11, Anatol Belski wrote:
>> The voting ends on 2015-02-09 at 21:00 CET.
>
> This is a ridiculously short voting period for a major decision.
> Although the minimum voting time for an RFC is one week, that sho
On 2 February 2015 at 19:11, Anatol Belski wrote:
>The voting ends on 2015-02-09 at 21:00 CET.
This is a ridiculously short voting period for a major decision.
Although the minimum voting time for an RFC is one week, that should
only be used in extremis.
The people affected by this decision are
Hi,
On Tue, Feb 3, 2015 at 12:16 AM, Anatol Belski wrote:
Mcrypt might be dead, but removing it would be a huge BC break. There
was some talk of binding mcrypt_*() functions to ext/openssl - I'd
suggest that instead of removal.
>>> that sounds plausible, but the same one
Hi,
On Mon, February 2, 2015 22:39, Andrey Andreev wrote:
> Hi,
>
>
> On Mon, Feb 2, 2015 at 9:45 PM, Anatol Belski
> wrote:
>
>> On Mon, February 2, 2015 20:30, Andrey Andreev wrote:
>>
>>> Oh, forgot one thing ...
>>>
>>>
>>>
>>> Mcrypt might be dead, but removing it would be a huge BC break. T
Hi,
On Mon, Feb 2, 2015 at 9:45 PM, Anatol Belski wrote:
> On Mon, February 2, 2015 20:30, Andrey Andreev wrote:
>> Oh, forgot one thing ...
>>
>>
>> Mcrypt might be dead, but removing it would be a huge BC break. There
>> was some talk of binding mcrypt_*() functions to ext/openssl - I'd suggest
Hi Uwe,
On Mon, February 2, 2015 21:20, Uwe Schindler wrote:
> Hi,
>
>
> I gave my votes (where I can talk about). I am still maintaining the
> NSAPI
> SAPI. It does not meant that its dead if no commits were made. NSAPI
> upstream API just did not change since years, so why change a running
> sys
> Cc: Nikita Popov; Anatol Belski; PHP internals
> Subject: Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported
> SAPIs and extensions
>
> On Mon, February 2, 2015 20:30, Andrey Andreev wrote:
> > Oh, forgot one thing ...
> >
> >
> > Mcrypt migh
On Mon, February 2, 2015 20:30, Andrey Andreev wrote:
> Oh, forgot one thing ...
>
>
> Mcrypt might be dead, but removing it would be a huge BC break. There
> was some talk of binding mcrypt_*() functions to ext/openssl - I'd suggest
> that instead of removal.
>
that sounds plausible, but the same
Hi,
On Mon, February 2, 2015 20:15, Nikita Popov wrote:
> On Mon, Feb 2, 2015 at 8:11 PM, Anatol Belski
> wrote:
>
>
>> Hi,
>>
>>
>> properly after the voting phase the
>> https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
>> voting. Each item is voted separately. The voting end
Oh, forgot one thing ...
Mcrypt might be dead, but removing it would be a huge BC break. There
was some talk of binding mcrypt_*() functions to ext/openssl - I'd
suggest that instead of removal.
Cheers,
Andrey.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http:
Hi,
On Mon, Feb 2, 2015 at 9:15 PM, Nikita Popov wrote:
> On Mon, Feb 2, 2015 at 8:11 PM, Anatol Belski wrote:
>
>> Hi,
>>
>> properly after the voting phase the
>> https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
>> voting. Each item is voted separately. The voting ends on 2
On 02/02/15 19:11, Anatol Belski wrote:
> properly after the voting phase the
> https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
> voting. Each item is voted separately. The voting ends on 2015-02-09 at
> 21:00 CET.
I feel this is totally out of line since only people who use m
On Mon, Feb 2, 2015 at 8:11 PM, Anatol Belski wrote:
> Hi,
>
> properly after the voting phase the
> https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
> voting. Each item is voted separately. The voting ends on 2015-02-09 at
> 21:00 CET.
>
> Regards
>
> Anatol
>
I get the moti
Hi,
properly after the voting phase the
https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
voting. Each item is voted separately. The voting ends on 2015-02-09 at
21:00 CET.
Regards
Anatol
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://w
46 matches
Mail list logo
