Re: [PHP-DEV] Proposal to unbundle imap/pspell/oci8 extensions for PHP 8.4

> The ext/imap extension isn't going to disappear, it is not going be > unbundled as we can not guarantee the underlaying library is > maintained. Not only is it no longer maintained, the original > purveyors have removed any mention of it from their website. > > For most people, there will be

Re: [PHP-DEV] Proposal to unbundle imap/pspell/oci8 extensions for PHP 8.4

> Considering the lack of updates from upstream as Derick mentioned, > lack of OAuth support (which webklex/php-imap supports), and a > somewhat lackluster documentation for ext-imap in php.net, I think > unbundling ext-imap (along with the other extensions in the proposal) > makes sense. I don't

Re: [PHP-DEV] Re: [PECL-DEV] PHP Servers SSL Certificate Expiry

/bohwaz/a3e4eb91e82f12768b69f8d24cf0cca8 Have a nice day :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Security implications of parsing env variables in .ini

This is a valid concern, as we are side-loading plugins in our software, where plugin information is defined in a .ini file. But somehow I thought that INI_SCANNER_TYPED was a bit like INI_SCANNER_RAW but also able to handle null/true/false values. Unfortunately it's not the case: php >

Re: [PHP-DEV] [VOTE] PDO subclasses

I don't have voting rights, but just wanted to thank you again for your work :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] PDO Subclasses coming to vote soon.

> Yes? > > I think you possibly misread my email. Ah! sorry I understood the opposite, that you were wondering about letting people load extensions from SQL. Great that we are on the same note :) > Sorry, I am in too much pain to look at those before the deadline. > There is always 8.4

Re: [PHP-DEV] PDO Subclasses coming to vote soon.

> As that means that SQLite extensions can only be loaded through C code > (not through SQL), and if someone can upload and execute code to your > server, your server is compromised anyway, having to edit ini files to > enable extension loading, seems like a bad tradeoff. I'm sorry to disagree,

Re: [PHP-DEV] [VOTE] Use exceptions by default in SQLite3 extension

Voting has now ended with 21 votes for the "yes", and zero votes for the "no". Thanks everyone! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Use exceptions by default in SQLite3 extension

Hi Illia, thank you for your feedback. This is actually what I did, first, but I changed after feedback from @Girgias: https://github.com/php/php-src/pull/11058#discussion_r1162723112 > You are likely to get push back not just from myself if you propose > it as such in an RFC I don't have a

[PHP-DEV] [VOTE] Use exceptions by default in SQLite3 extension

Voting has now started for the RFC "Use exceptions by default in SQLite3 extension": https://wiki.php.net/rfc/sqlite3_exceptions The vote is open for 2 weeks. Thanks to the people who wrote the RFC howto page :) BohwaZ -- PHP Internals - PHP Runtime Development Mailing List To u

[PHP-DEV] [RFC] Last chance to discuss "Use exceptions by default in SQLite3 extension" before vote

I'm planning to start the vote on this RFC in a week or two. I changed the RFC to only have one proposal: deprecate warnings in PHP 8.3 and switch to exceptions in 9.0. Feedback is welcome :) Thanks to people who have provided feedback previously and on my PRs.

Re: [PHP-DEV] Moving PHP internals to GitHub

Please no, I want to read e-mails when I want, with my own software, leaving to me the freedom to mark things as important, or read, or unread, or sort them in folders. An important point : not all people in the world have access to the internet at all time. Some people have to fetch the messages

Re: [PHP-DEV] [RFC] [Discussion] SQLite3: remove warnings, move to exceptions

Hi, I updated the RFC I added a second proposal where the only change would be to throw exceptions by default in 8.3 instead of 9.0: https://wiki.php.net/rfc/sqlite3_exceptions I also changed the plan for 9.0: "Calling SQLite3::enableExceptions(true) raises E_DEPRECATED, to alert that the

Re: [PHP-DEV] [RFC] [Discussion] SQLite3: remove warnings, move to exceptions

> As others have said, the correct, responsible way to do this would be > to make it gradual and keep warnings working until 9.0. I would > recommend: > > 1. 8.3, enableExceptions(false) raises E_DEPRECATED. > 2. 9.0 enableExceptions() defaults to true, and calling it with false > is an Error.

[PHP-DEV] [RFC] [Discussion] SQLite3: remove warnings, move to exceptions

Kia ora, I am proposing that the SQLite3 extension stops using warnings for errors and instead throws exceptions by default: https://wiki.php.net/rfc/sqlite3_exceptions Whether we just deprecate warnings first and default to exceptions, and then remove warnings altogether in a later version, or

[PHP-DEV] SQLite3: implement session extension

Hi folks! 2 years ago I implemented some missing APIs in the SQLite3 extension, and I still want to get SQLite3 support in PHP to get better. Today I'll be talking about something that can become very useful: The SQLite3 session extension allows to create changesets from a database, that is to

Re: [PHP-DEV] Increase maximum size of an uploaded file to 50Mbyte

2MB is probably too low and it can be set at something like 20MB, but from my understanding setting it low enough will help prevent DoS attacks. If we change it to something larger, I'm not sure exactly what would be the effect of changing this default for mass-hosting providers where they can

Re: [PHP-DEV] [RFC][Under discussion] Deprecate ${} string interpolation

> > The 4th one is very useful. > > > > $v = ${'param_' . $name}; > > Like Rowan mentioned, the RFC does not propose to deprecate variable > variables, just variable variables as a form of string interpolation. > You'll still be able to use variable variables, even in strings, like > noted

Re: [PHP-DEV] [RFC][Under discussion] Deprecate ${} string interpolation

> The RFC is *only* about how variables are interpolated *inside quoted > strings*. Then it doesn't seem clear in the RFC that it's limited to variables inside strings, maybe it should be made clearer that it's only proposed to deprecate that syntax inside strings, and not the variables variables

Re: [PHP-DEV] [RFC][Under discussion] Deprecate ${} string interpolation

This RFC is confusing two different things: 1. variables inside strings (options 1, 2, 3) 2. dynamic variables names (option 4) The 4th one is very useful. $v = ${'param_' . $name}; There is no other practical way to do that, so removing that feature would mean breaking something useful with

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

Same thing, not everyone wants to use strict types, and the change in PHP 8.1 is a pain, adding (string) everywhere just means adding more code with no gain just to get around a limitation of the language. So thank you Craig for this RFC :) -- PHP Internals - PHP Runtime Development Mailing

Re: [PHP-DEV] [RFC]: Change Default mysqli Error Mode

We should do the same with SQLite3 extension. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] SQLite3, PDO/SQLite and driver specific methods

On Tue, 16 Jun 2020 11:32:01 +0100 / Peter Bowyer said : > Hi list, > > 4 months ago there was a discussion about the future of SQLite3 and > PDO/SQLite extensions (https://externals.io/message/108256), > highlighting the effort required to maintain two codebases. Yes and I haven't had time to

[PHP-DEV] The future of SQLite3 and PDO/SQLite extensions

that accepted? Cheers, BohwaZ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Help with memory leak on zend_call_function

Hi all, I am working on this PR: https://github.com/php/php-src/pull/4797 It implements the ability to set a userland callback function that would allow or deny SQL queries in SQLite using its internal authorizer logic. This is a native feature of SQLite that is currently missing from the

Re: [PHP-DEV] The real world ...

Le 13/06/2019 14:20, Lester Caine a écrit : On 13/06/2019 13:04, Andrey Andreev wrote: You have logs to see the errors; relying on your users to report the actual error messages to you is the worst way to do it. How many website logs can you manage on a daily basis? Given the volume of

Re: [PHP-DEV] The real world ...

If you're so keen on providing the user something to see without having to use display_errors=on: Have you had a look at https://php.net/register_shutdown_function ? You can always use that to figure out whether there was a fatal error and then display something nice to the user. No leaked

Re: [PHP-DEV] open_basedir?

On Fri, 10 May 2019 22:55:51 +0200 / Niklas Keller said : > That's exactly the reason why I'm for removing it. There will always > be ways to circumvent open_basedir and setups like this are insecure. > It gives a false sense of security. It's not better than nothing, > because most hosting

Re: [PHP-DEV] open_basedir?

Kia ora, I'm against deprecating it or removing it. As said earlier, it has some security value, especially with mass hosting. If I'm hosting thousands of websites for thousands of users, using chroot is not doable, and open_basedir is a good alternative (at least it's better than nothing).

Re: [PHP-DEV] Mitigate “Magellan vulnerabilitites” in PHP 7.2?

Thanks Christoph! Just to be clear, this patch doesn't prevent security issues if you don't update your SQLite3 library, it just implements a new option available in newer SQLite versions which will prevent arbitrary changes to the internals of a SQLite database only if you SQLite3 library is

Re: [PHP-DEV] New website for the PHP project

Could not find anything about PDOStmt::setParam either, but I fixed it for you: http://php.net/pdostatement_bindparam You're welcome ;) Ah ah good catch :) I meant bindParam obviously ^^ The fact is http://php.net/bindparam will return nothing about PDOStatement::bindParam which is kind of

Re: [PHP-DEV] New website for the PHP project

Le 04/02/2019 01:14, azjezz a écrit : In my opinion, current design looks old, outdated and bland. This sadly may reflect "badly" on the language reputation nowadays. I find that the main PHP website is quite good actually, the design looks modern, it is quite clear and easy to use and it

Re: [PHP-DEV] Inconsistent float to string vs. string to floatcasting

a date in a different language. So I'm all for deprecating setlocale but before that we would need to have something better for everything that's currently depending on it :) BohwaZ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Unbundle libsqlite3?

On Wed, 19 Sep 2018 19:41:11 +0200 / "Christoph M. Becker" said : > PR #2698[2] seems to require an RFC. IMHO, it's best to present RFCs > and voting on them as early as possible (instead of rushing them at > the last moment). :) Yeah there was an RFC and it was voted no:

Re: [PHP-DEV] Unbundle libsqlite3?

On Mon, 17 Sep 2018 15:16:13 +0200 / "Christoph M. Becker" said : > Hi! > > We bundle an unmodified libsqlite3 for at least two years. Since then > all updates go into any dev, alpha and beta releases, while security > patches (usually backports from libsqlite3) go into stable branches. > >

Re: [PHP-DEV] [RFC] [VOTE] Implement missing SQLite feature "openBlob" in PDO

On Mon, 30 Oct 2017 20:11:18 + / Rowan Collins said : > On 30/10/2017 03:14, Dan Ackroyd wrote: > > The vote for this should have ended..3 days ago. > > > > At which point I believe the vote was actually passing. > > > Hm, that's awkward! > > For the record: >

Re: [PHP-DEV] [RFC] [VOTE] Implement missing SQLite feature "openBlob" in PDO

On Wed, 01 Nov 2017 19:08:56 + / Rowan Collins <rowan.coll...@gmail.com> said : > On 1 November 2017 17:47:55 GMT+00:00, BohwaZ <p...@bohwaz.net> wrote: > >I can't find the place where we can see the voting history? Last > >time I checked the page last week it w

Re: [PHP-DEV] [RFC] [VOTE] Implement missing SQLite feature "openBlob" in PDO

that. On Mon, 30 Oct 2017 03:14:03 + / Dan Ackroyd <dan...@basereality.com> said : > The vote for this should have ended..3 days ago. > > At which point I believe the vote was actually passing. > > cheers > Dan > > On 9 October 2017 at 23:12, BohwaZ/PHP <p.

Re: [PHP-DEV] [RFC] [VOTE] Implement missing SQLite feature "openBlob" in PDO

Le 12/10/2017 12:00, Dan Ackroyd a écrit : On 11 October 2017 at 22:03, BohwaZ/PHP <p...@bohwaz.net> wrote: Hey, For people voting against the RFC, could you please explain your vote here so that we might understand? Cheers. I think people were reasonably clear during the disc

Re: [PHP-DEV] [RFC] [VOTE] Implement missing SQLite feature "openBlob" in PDO

Hey, For people voting against the RFC, could you please explain your vote here so that we might understand? Cheers. Kia ora, After some more discussions, I don't think we have much left to discuss on that topic, so… Voting is now open for 2 weeks on this RFC:

[PHP-DEV] [RFC] [VOTE] Implement missing SQLite feature "openBlob" in PDO

Kia ora, After some more discussions, I don't think we have much left to discuss on that topic, so… Voting is now open for 2 weeks on this RFC: https://wiki.php.net/rfc/implement_sqlite_openblob_in_pdo Vote will end on Wednesday the 25th of October. Thanks to everyone who contributed to the

Re: [PHP-DEV] Re: [RFC] [Discussion] Implement SQLite "openBlob" feature in PDO

I believe that's how PDO::PARAM_LOB is intended to work (based on my reading of the docs and implementations for other drivers). It seems like more of a convenience than anything, though maybe someone had more ideas for how it should work across drivers and never got to follow through on it.

Re: [PHP-DEV] Re: [RFC] [Discussion] Implement SQLite "openBlob" feature in PDO

Taking it to a better solution is that the method sqliteCreateFunction shouldn't exist on the PDO class, but instead on a PDOSqlite that extends PDO. class PDOSqlite extends PDO { public function createFunction(...) {...} } class PDO { public static function connect(string $dsn [,

Re: [PHP-DEV] Re: [RFC] [Discussion] Implement SQLite "openBlob" feature in PDO

On 02/10/17 01:48, BohwaZ/PHP wrote: So for me the use case is quite different here, and openBlob allows stuff that PDO::PARAM_LOB with bindColumn and bindParam cannot allow currently. In conclusion openBlob is still useful as it allows accessing a BLOB outside of a statement and allows

Re: [PHP-DEV] Re: [RFC] [Discussion] Implement SQLite "openBlob" feature in PDO

PDO already has support for large objects (LOBs)[1]. I don't know if and how these are supported by the pdo_sqlite driver, but wouldn't it make sense to use the existing API instead of introducing a new method? [1] Very interesting indeed, didn't

Re: [PHP-DEV] [RFC] [Discussion] Implement SQLite "openBlob" feature in PDO

On Wed, 27 Sep 2017 11:47:21 +0200 / Matteo Beccati said : > On 27/09/2017 11:34, Lester Caine wrote: > > openBlob is a specific feature of SQLite so the decision to use it > > already rules out any other database. IN PDO access to it via the > > generic blob functions is the

[PHP-DEV] Re: [RFC] [Discussion] Implement SQLite "openBlob" feature in PDO

On Wed, 27 Sep 2017 11:41:50 +0200 / "Christoph M. Becker" <cmbecke...@gmx.de> said : > On 26.09.2017 at 04:03, BohwaZ/PHP wrote: > > > following my patch and discussions on this list, here is the RFC > > requested by some people here to implement "

Re: [PHP-DEV] [RFC] [Discussion] Implement SQLite "openBlob" feature in PDO

On Wed, 27 Sep 2017 09:47:51 +0100 / Dan Ackroyd <dan...@basereality.com> said : > On 26 September 2017 at 03:03, BohwaZ/PHP <p...@bohwaz.net> wrote: > > Kia ora, > > > > https://wiki.php.net/rfc/implement_sqlite_openblob_in_pdo > > > Couple of questi

[PHP-DEV] [RFC] [Discussion] Implement SQLite "openBlob" feature in PDO

Kia ora, following my patch and discussions on this list, here is the RFC requested by some people here to implement "openBlob" in the pdo_sqlite driver, to match the "openBlob" method from the SQLite3 extension. https://wiki.php.net/rfc/implement_sqlite_openblob_in_pdo Discussion should

Re: [PHP-DEV] Request access to wiki for RFC on implementing missing pdo_sqlite features

Hello, anyone? :) Kia ora, I'm requesting access to wiki to be able to write the RFC on implementing missing pdo_sqlite features, following pull request https://github.com/php/php-src/pull/2698 and discussion on this list. My account on the wiki is "bohwaz". Cheers. -- PHP Inter

[PHP-DEV] Request access to wiki for RFC on implementing missing pdo_sqlite features

Kia ora, I'm requesting access to wiki to be able to write the RFC on implementing missing pdo_sqlite features, following pull request https://github.com/php/php-src/pull/2698 and discussion on this list. My account on the wiki is "bohwaz". Cheers. -- PHP Internals - P

Re: [PHP-DEV] Matching PDO_SQLite features with SQLite3 extension

However, there have been objections > against PR #2698, so an RFC appears to be appropriate. Cool, that's a rule that makes sense :) maybe it should be in the contributing guide? Can someone give me RFC power on the wiki (my account is "bohwaz")? Thanks. Should I include the proposal for addi

Re: [PHP-DEV] Matching PDO_SQLite features with SQLite3 extension

Le 23/08/2017 16:57, Marco Pivetta a écrit : I suggest adding dedicated functions that given a PDO instance and the parameters you needed do what you want to do. So if I understand correctly: $pdo = new PDO('sqlite::memory:'); $extended = new PDO_Extended_SQLite($pdo); $blob =

Re: [PHP-DEV] Matching PDO_SQLite features with SQLite3 extension

PDO is already a mess, and adding method that appear/disappear dynamically whether you enable an extension or not... is a horror show. From my PoV, since we (doctrine) have to abstract away from it all the time, we'd rather have it as tidy and well-thought-out as possible, especially since

Re: [PHP-DEV] Matching PDO_SQLite features with SQLite3 extension

Yes, because once it lands in core, it sticks around for almost eternity. Yeah but is it necessary for something that is just missing, because the pdo_sqlite implementation is incomplete, and is basically following what already exists, without changing anything? That change was implemented

Re: [PHP-DEV] Matching PDO_SQLite features with SQLite3 extension

Le 22/08/2017 07:55, Adam Baratz a écrit : A new method is an API change to me, so an RFC would be warranted. I'm reluctant to add driver-specific methods, since that seems opposed to PDO's driver-agnostic API, but that's not to say we couldn't hash something out. Do we need a RFC every time

[PHP-DEV] Matching PDO_SQLite features with SQLite3 extension

Hi people of the PHP world, I just have proposed a patch to have SQLite3 open_blob feature implemented in PDO_SQLite: https://github.com/php/php-src/pull/2698 This follows my patch to implement this feature in the SQLite3 extension a few months ago. Now my aim is to implement missing

Re: [PHP-DEV] OBJECT_OPERATOR vs. DOUBLE_COLON

Le 06/07/2017 16:46, Stanislav Malyshev a écrit : Hi! I think that using :: on a variable that contains an object should not "fall back" to a static access on the object's class. Instead the runtime should error out. Why should it not do what it does now? What would it achieve? I don't see