Re: [PHP-DEV] Deprecating uniqid()
Hey Ben, hey all Am 02.05.20 um 21:13 schrieb Ben Ramsey: >> On May 2, 2020, at 13:57, AllenJB wrote: >> >> Hi all, >> >> I'd like to discuss deprecating uniqid() >> >> I believe it's dangerously bad a doing "what it says on the tin". New >> developers still reach for it and do not read the warnings on the manual >> page (or if they do, don't fully understand how bad it is). >> >> For older codebases that still rely on it, a userland replacement can be >> easily implemented (and could be published on Packagist). >> >> I noticed there was an RFC [0][1] brought up 2 years ago, but was never >> voted on. Does anyone know why this was? >> >> [0] https://externals.io/message/102097 >> [1] https://wiki.php.net/rfc/deprecate-uniqid >> >> Is there interest in deprecating this function? >> >> If not deprecation, how could it be (further) "improved"? My first thought >> is to make the "more entropy" option enabled by default (the argument could >> remain so that it can be disabled by codebases that rely on the lower length >> and can take the tradeoffs). > > > Instead of deprecating and removing it, would anyone be opposed to replacing > the internals of the function so that it uses `random_bytes()` under the > hood, while all other functionality remains the same? I'D rather deprecate it and give a clear advice on what to use instead (i.e. in the docs) than changing the internal behaviour and break code. As replacement I could think of showing people the way to UUIDs. As the function itself was never intended for cryptographically secure values I would not see random_* functions or the like as a replacement. My 0.02 € Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +-+ | http://hei.gl/root-ca | +-+ signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Deprecating uniqid()
On Sun, May 3, 2020 at 2:57 PM Rowan Tommins wrote: > > A common suggestion is to use binhex(random_bytes($desired_length / 2)), > which isn't particularly elegant, and in my experience, the main > requirement is "a unique string of printable/alphanumeric characters, so > limiting to [0-9a-f] is just limiting entropy for no reason. > Yes, a base_convert(..., 16, 32) around that would help but I'd really prefer a simple function than a chain of 3 functions (even if we had Larry's pipe operator :-p) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecating uniqid()
Hey Allen, there's been discussion on whether we should deprecate or replace its functionality. Without changing the output format, it's impossible to have enough entropy. Without consensus on the best way forward, I've just never cared to put this to a vote. I'll happily collaborate on moving this RFC forward for PHP 8. Best, Niklas Am Sa., 2. Mai 2020 um 20:57 Uhr schrieb AllenJB : > > Hi all, > > I'd like to discuss deprecating uniqid() > > I believe it's dangerously bad a doing "what it says on the tin". New > developers still reach for it and do not read the warnings on the manual > page (or if they do, don't fully understand how bad it is). > > For older codebases that still rely on it, a userland replacement can be > easily implemented (and could be published on Packagist). > > I noticed there was an RFC [0][1] brought up 2 years ago, but was never > voted on. Does anyone know why this was? > > [0] https://externals.io/message/102097 > [1] https://wiki.php.net/rfc/deprecate-uniqid > > Is there interest in deprecating this function? > > If not deprecation, how could it be (further) "improved"? My first > thought is to make the "more entropy" option enabled by default (the > argument could remain so that it can be disabled by codebases that rely > on the lower length and can take the tradeoffs). > > AllenJB > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Always available JSON extension
Hi Levi, > Have we reached out to package maintainers for OS distributions that are not > bundling json today to make sure all their concerns are resolved? I CCed them on the GitHub PR just now. https://github.com/php/php-src/pull/5495#issuecomment-623163698 Hopefully, this is due to packaging conventions carrying over from php 5 and there are no remaining blockers. I didn't see this done for moving the hash extension into core, but I think most packagers were compiling it statically. - Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Always available JSON extension
Have we reached out to package maintainers for OS distributions that are not bundling json today to make sure all their concerns are resolved?
[PHP-DEV] Re: [RFC] Always available JSON extension
Hi internals,
I plan to start the vote for https://wiki.php.net/rfc/always_enable_json on May
13th
> I've created https://wiki.php.net/rfc/always_enable_json with an
>implementation at https://github.com/php/php-src/pull/5495
>
> The proposal is to make it impossible to disable the JSON extension through
> configuration or build options,
> and require that JSON be built statically instead of as a shared library
> (to avoid linker errors or extension=json being commented out).
Discussion of this idea prior to creating this RFC can be seen at
https://externals.io/message/109783
("Moving json extension to core?")
Thanks,
- Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] opcache.jit directive should be split up
Hi CHU Zhaowei, By alias, I meant "an **alternative** name or label that refers to an item, and can be used to locate or access it." (add a way to set the option without removing existing ways) (Users would have the choice of using both the magic numbers or the strings to refer to the same setting value). > E.g. what does "minimal" mean in this context? It's a short label based on the description of the value in https://wiki.php.net/rfc/jit#phpini_defaults > 1 - **minimal** JIT (call standard VM handlers) It would be easier for someone to remember/infer what opcache.jit_optimization_level=minimal means than 1 if they saw it in their php.ini or a command line invocation, with or without familiarity with the JIT. (without needing to go to php.net) Regards, - Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecating uniqid()
On 03/05/2020 09:54, Jakob Givoni wrote: I'm using this function frequently, but I am ok with deprecating it as I think the name is dangerously misleading - basically, anything that mentions "unique" without saying to what, is a misnomer. However, as it's useful to have a function in core that gives you a random string with a fixed length that is unique within some well-defined boundaries, I'd like to be sure there is an easy replacement for the function when the time comes to upgrade php. Ideally something that is guaranteed to be unique within the current php process and takes the same arguments as uniqid. I definitely think that all deprecations should come with clear guidance of either "use this instead" or "what you're doing is fundamentally wrong". I'm not sure it needs to retain the same arguments, or even the same output format, though, just fit the same use cases. The prefix can be added trivially, and the "hex, dot, numeric" output of the "more entropy" version is not often particularly helpful. A common suggestion is to use binhex(random_bytes($desired_length / 2)), which isn't particularly elegant, and in my experience, the main requirement is "a unique string of printable/alphanumeric characters, so limiting to [0-9a-f] is just limiting entropy for no reason. I wonder if we could add a parameter to random_bytes, or an accompanying function, that would return only alphanumeric characters; or perhaps accept a range of characters to allow in some form. Regards, -- Rowan Tommins (né Collins) [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecating uniqid()
On Sat, May 2, 2020 at 9:58 PM Nikita Popov wrote: > > On Sat, May 2, 2020 at 9:13 PM Ben Ramsey wrote: > > > > On May 2, 2020, at 13:57, AllenJB wrote: > > > > > > Hi all, > > > > > > I'd like to discuss deprecating uniqid() > > > > > > I believe it's dangerously bad a doing "what it says on the tin". New > > developers still reach for it and do not read the warnings on the manual > > page (or if they do, don't fully understand how bad it is). > > > > > > For older codebases that still rely on it, a userland replacement can be > > easily implemented (and could be published on Packagist). > > > > > > I noticed there was an RFC [0][1] brought up 2 years ago, but was never > > voted on. Does anyone know why this was? > > > > > > [0] https://externals.io/message/102097 > > > [1] https://wiki.php.net/rfc/deprecate-uniqid > > > > > > Is there interest in deprecating this function? > > > > > > If not deprecation, how could it be (further) "improved"? My first > > thought is to make the "more entropy" option enabled by default (the > > argument could remain so that it can be disabled by codebases that rely on > > the lower length and can take the tradeoffs). > > > > > > Instead of deprecating and removing it, would anyone be opposed to > > replacing the internals of the function so that it uses `random_bytes()` > > under the hood, while all other functionality remains the same? > > > > I believe this has been discussed in the past, and the basic problem is > that uniqid() currently only returns 13 hex characters, so we can encode at > most 52 bits of entropy without changing the output format. This is > insufficient. Changing the format could break assumptions, such as database > column sizes. > > Personally, I would be in favor of deprecating the function. I've run into > an issue caused by non-unique uniqid() somewhat recently myself as well. > > Regards, > Nikita I'm using this function frequently, but I am ok with deprecating it as I think the name is dangerously misleading - basically, anything that mentions "unique" without saying to what, is a misnomer. However, as it's useful to have a function in core that gives you a random string with a fixed length that is unique within some well-defined boundaries, I'd like to be sure there is an easy replacement for the function when the time comes to upgrade php. Ideally something that is guaranteed to be unique within the current php process and takes the same arguments as uniqid. Best, Jakob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
