My recommendation is to have a base interface for every operator that can
be overloaded, so that these can be composed together.
AddOverloadInterface { __overloadAdd(): self; }
SubOverloadInterface { __overloadSub(): self; }
MulOverloadInterface { __overloadMul(): self; }
DivOverloadInterface {
http_parse_query() would get my vote (if I had vote karma :P)
On Fri, Aug 6, 2021 at 4:05 AM Mike Schinkel wrote:
> > On Aug 6, 2021, at 3:51 AM, Aleksander Machniak wrote:
> >
> > I agree about the _string suffix removal. However, I know we have
> > parse_url() already, but parse_query()
On Thu, Jun 24, 2021 at 5:22 AM Stephen Reay wrote:
> > If you **inject a `1=1` clause where one didn't exist before**, that's
> > injection. Notice the introduction of an OR operator in the examples
> > you cited.
>
> Please, explain to us all, how `where foo=‘bar’ OR 1=1` is functionally
>
On Thu, Jun 24, 2021 at 4:34 AM Guilliam Xavier
wrote:
>
>
> On Thu, Jun 24, 2021 at 9:14 AM Scott Arciszewski wrote:
>>
>> On Thu, Jun 24, 2021 at 2:10 AM Stephen Reay
>> wrote:
>>
>> > I would absolutely make use of a function that tells me if the st
On Thu, Jun 24, 2021 at 2:10 AM Stephen Reay wrote:
>
>
>
> On 24 Jun 2021, at 08:30, Scott Arciszewski wrote:
>
> On Wed, Jun 23, 2021, 9:23 PM Bruce Weirdan wrote:
>
> On Thu, Jun 24, 2021 at 3:41 AM Scott Arciszewski
> wrote:
>
> The failure condition of
On Thu, Jun 24, 2021 at 2:10 AM Stephen Reay wrote:
> Hi Scott,
>
> I wrote that example where an integer could be dangerous.
I don't disagree that it's an example where an integer could be dangerous.
Danger is too broad to have a meaningful discussion about. You can, of
course,
On Wed, Jun 23, 2021, 9:23 PM Bruce Weirdan wrote:
> On Thu, Jun 24, 2021 at 3:41 AM Scott Arciszewski
> wrote:
> > The failure condition of this query is
> > "return all rows from the table already being queried", not "return
> > arbitrary d
On Wed, Jun 23, 2021 at 8:09 PM Bruce Weirdan wrote:
>
> > - String + int concatenation isn't an injection risk.
>
> I think this demonstrates it very well could be:
> https://externals.io/message/114988#115038
>
> --
> Best regards,
> Bruce Weirdan
>
fore, if the concern is Injection attacks, integer inputs do not
need to be tracked to provide a security gain.
This is only true for integers, not all numeric types. I haven't
investigated the safety of floats in every possible context, and the
`e`, `+`, and `.` characters could be problematic in c
Apologies for my semantic imprecision. I hope the intent of my email
remains clear.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
On Thu, Sep 12, 2019 at 12:56 PM Chase Peeler wrote:
>
>
>
> On Thu, Sep 12, 2019 at 12:51 PM
fashion, create an
RFC and vote on our new addition to the RFC process. (Even Zeev has to
acknowledge that additions are fine, with 2/3 majority.)
But we shouldn't accept his door-shutting terms just because he says so.
Respectfully,
Scott Arciszewski
Chief Development Officer
Paragon Initiative En
currently ?
Thanks
Scott
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
, but it seems an easy fix also
for someone with access to the mailing list.
Would it be possible for this to be applied ? as mentioned earlier this
isnt major but I can't imagine I am the only one who has failures
because of this.
Thanks
Scott
--
PHP Internals - PHP Runtime Development
to vote. looks like the
negative number part is not going to pass so the PR has not been
updated.
Link to RFC if you need it -
https://wiki.php.net/rfc/base_convert_improvements
Any questions please let me know
Thanks
Scott
--
PHP Internals - PHP Runtime Development Mailing List
, but it's probably quicker than
trying to make PHP's DOM implementation spec-compliant.
--scott
On Wed, Mar 20, 2019 at 11:48 AM C. Scott Ananian
wrote:
> On Sun, Mar 17, 2019 at 6:57 PM Rob Richards
> wrote:
>
>> I'll take a look through the lists you have but you n
It seems people is down
For example https://people.php.net/rasmus
Not sure if people are aware
Thanks
Scott
Hi Chu,
Its currently coded to treat that as 'ff' so any odd amount of '-'
makes it negative, and any even amount is positive.
Thanks
Scott
On 19.06.2019 14:12, CHU Zhaowei wrote:
Hi Scott,
Could you clarify what will happen if multiple negative sign occurs.
I didn't find it in the RFC
Ah thats brilliant, I will take a look at updating the tests when I
split the PR tomorrow
Thanks Nikita
Scott
On 19.06.2019 09:13, Nikita Popov wrote:
On Wed, Jun 19, 2019 at 10:06 AM Scott Dutton
wrote:
Hi Joe,
I will have a look at splitting the PR, I am not at a computer where
i
that helps
Scott
On 19.06.2019 08:56, Joe Watkins wrote:
There should probably be a PR targeting 7.4 with the implementation
of "Error on ignored characters" as proposed for 7.4, and a PR
targeting master implementing "Error on ignored characters" with
exception change and implemen
nge
(but as you say there were quite a lot of tests).
Would it be easier for 2 prs ? one for each vote ?
Thanks
Scott
On 19.06.2019 08:31, Joe Watkins wrote:
The implementation of this does not look ready, there are conflicts
so I can't test it locally, but last time CI ran there were many
failu
is to allow negative numbers, eg base_convert('-FF', 16,
10) would return -255 (this returns 255 currently)
Voting ends 3rd July
Thanks
Scott
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
es outside of /docs then run the
tests.
Contributors can then forget about the [ci-skip] and gets the same
effect
This runs on linux but I cant imagine its a big change to make for this
to work on windows ?
You can tweak the diff command to only run tests when certain sets of
files change
Tha
Hi all,
I plan to put this to vote early next week with the two options
One vote for the invalid char deprecation for php7.4 and Exception in
PHP8
One vote for negative numbers PHP8 only - due to BC concerns
Thanks
Scott
--
PHP Internals - PHP Runtime Development Mailing List
Ondrej updated on the 31st (yesterday). The official Ubuntu one (in 18.04 at
least) updated on 30th.
Both do update pretty quickly usually.
Scott
On 1 June 2019 18:56:44 BST, Larry Garfield wrote:
>On Thu, May 30, 2019, at 11:17 PM, Ryan McCullagh wrote:
>> Hi internals group,
values
will not return the expected value (unless there is a way to avoid both
of these?)
Happy to make any changes to the implementation as I said in the PR, my
C is quite rusty
Thanks
Scott
On 23.05.2019 17:32, Derick Rethans wrote:
On Thu, 23 May 2019, Nikita Popov wrote:
On Sat, May 18
translation.
a warning here would have at least indicated there was something wrong
with the input it was being passed instead of just 0.
Thanks
Scott
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
to extreme range's
(also mentioned in the RFC)
If this passes I will fix the effected tests and add some more covering
the new behavior.
https://wiki.php.net/rfc/base_convert_improvements
Let me know your thoughts
Thanks
Scott
--
PHP Internals - PHP Runtime Development Mailing List
It's exussum
Thanks
Scott
On 10 May 2019 05:26:39 BST, Scott Dutton wrote:
>Hi
>
>Could I get Wiki permissions to create an RFC for
>
>https://externals.io/message/104618
>
>Thanks
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsub
Hi
Could I get Wiki permissions to create an RFC for
https://externals.io/message/104618
Thanks
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, Mar 27, 2019 at 5:41 PM C. Scott Ananian
wrote:
> I've created https://github.com/php/php-src/pull/3994 implementing this
> fix, and confirmed that it is sufficient to get my large regexp interned
> when it is rewritten as a class constant referencing
> HTMLData::NAMED_
On Wed, Mar 27, 2019 at 2:30 PM C. Scott Ananian
wrote:
> Continuing this saga: I'm still having performance problems on character
> entity expansion. Here's the baseline code:
> https://github.com/wikimedia/remex-html/blob/master/RemexHtml/Tokenizer/Tokenizer.php#L881
> Of note:
ht I'd run that thought process by folks before I go further.
--scott
On Tue, Mar 26, 2019 at 5:31 AM Nikita Popov wrote:
> On Sat, Mar 23, 2019 at 4:07 PM C. Scott Ananian
> wrote:
>
>> Yup, testing via CLI but Wikimedia will (eventually) be running PHP 7.x
>> with opcache ( ht
pcre_match (and this is with PREG_LENGTH_CAPTURE). So
there's still (in theory) a >2x speedup in preg matching available by
tuning how the subpat_array works and making it less costly to
allocate/free $matches.
--scott
On Sat, Mar 23, 2019 at 6:13 AM Nikita Popov wrote:
> On Sat, Mar 23, 2019 at 6:32 AM
long, and we need to do a zend_string_equal_content() on the 26,137 byte
regexp for every ~5 byte entity in the parsed HTML.
--scott
On Thu, Mar 21, 2019 at 7:35 AM Nikita Popov wrote:
> On Wed, Mar 20, 2019 at 4:35 PM C. Scott Ananian
> wrote:
>
>> On Tue, Mar 19, 2019 at 10:58 AM Nikita Popov
determine the cost of the string copy in the
$matches array. (The string copy is really trivial in this particular case
anyway.)
--scott
On Thu, Mar 21, 2019 at 5:16 PM C. Scott Ananian
wrote:
> Quick status update. I tried to prototype this in pure PHP in the
> wikimedia/remex-htm
from
source using Nikita's proposed patch so that I can actually get an
apples-to-apples comparison.
--scott
On Thu, Mar 21, 2019 at 7:35 AM Nikita Popov wrote:
> On Wed, Mar 20, 2019 at 4:35 PM C. Scott Ananian
> wrote:
>
>> On Tue, Mar 19, 2019 at 10:58 AM Nikita
(for
example wikimedia/zest-css has to return an array instead of a DOMNodeList).
--scott
On Mon, Mar 18, 2019 at 9:44 AM Nikita Popov wrote:
> On Thu, Mar 14, 2019 at 8:33 PM C. Scott Ananian
> wrote:
>
>> I'm floating an idea for an RFC here.
>>
>> I'm working on the wikimedia/remex-html library for high-performance
>> PHP-native HTML5 parsing.
[1][1];
If you introduce a whole new OO accessor object, it starts becoming very
hard to write backward-compatible code.
--scott
was found, then move the prefix returned to the start of the buffer,
wait for the buffer to fill more, then restart.
--scott
On Wed, Mar 20, 2019 at 5:32 AM Nikita Popov wrote:
> Hi internals,
>
> PCRE has some very nice partial matching functionality described at
> https://www.pcre
ere that came from)
--scott
PS. My personal feeling at this time is that it would be better to put the
core libxml abstractions in an extension, to allow fast xpath and perhaps
parse/serialize, but that the actual DOM should be built as a php library
on top of that, in order to allow rapid changes (th
leads to
extreme performance loss -- parsing a 2MB file goes from 0.4s (with
Document#createElement()) to 2.5s (with Document#createElementNS()).
--scott
--
(http://cscott.net)
the matched substring unnecessarily. This would allow greatly reducing the
number of substring copies made during lexing.
Thoughts?
--scott
ps. more ambitious would be to introduce a new "substring" type, which
would share the allocation of a parent string with its own offset and
len
On 11.03.2019 10:51, Nikita Popov wrote:
Both changes sound reasonable to me. Could you show some examples
where the
output is going to change due to the zend_ulong->zend_long switch?
Nikita
Sure!
For example
var_dump(decbin(9223372036854775807));
would currently show
string(64)
k forward to hearing thoughts on this
Thanks
Scott
On Fri, Nov 3, 2017 at 3:49 PM, Matteo Beccati <p...@beccati.com> wrote:
> Hi Scott,
>
> On 03/11/2017 16:33, Scott Arciszewski wrote:
> > 1. Which DB drivers (and which versions) support 1RT prepared statements
> in
> > addition to 2RT prepared statements?
ns) support 1RT prepared statements in
addition to 2RT prepared statements?
2. Is there a better name for this usage than safeQuery()?
If this turns out to be a good idea, I'll write up an RFC targeting PHP 7.3.
-
[1]: https://github.com/paragonie/easydb
Scott Arciszewski
Chief Development Off
On Sun, Jul 2, 2017 at 12:51 PM, Scott Arciszewski <sc...@paragonie.com>
wrote:
>
> Hi all,
>
> Towards the end (currently, anyway) of the pull request discussion, a
> possible resolution emerges for ext/sodium: https://github.com/php/php-
> src/pull/2560#issuecomment-
nals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Hi all,
Towards the end (currently, anyway) of the pull request discussion, a
possible resolution emerges for ext/sodium:
https://github.com/php/php-src/pull/2560#issuecomment-312452732
I've never dealt with licensing issues before, so I'm not sure what the
process is myself.
However, feel free to treat my contributions as CC0/WTFPL/Unlicense so that
everyone can freely just relicense my contributions as whatever license
without complication. You don't even need me to sign off on it. Just, have
at it.
Would it make sense to post an issue on the libsodium-php Github to ask the
contributors if they consent to a relicense? Or should we track them down
and email them individually?
This is new territory for me, so I apologize if anything I said sounds
stupid.
Regards,
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>
for better cryptography in
PHP 7.2.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
ed public information (even if
you don't go out of your way to publish it).
If you have a weak IKM but a strong salt (32 bytes from random_bytes()),
you should still consider the OKM weak.
> Salt is the most important for both input and output key security.
> Salt is mandatory and/or can be used for almost always with PHP.
> Salt usage results in better design/security.
> Salt is often used as final key as combined key.
Don't get me wrong: Having secure random salts is useful (serves as a
useful way to enlarge the effective nonce in a symmetric encryption
protocol).
But the cryptographic secret in this protocol is IKM. Not the salt.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>
On Wed, Feb 8, 2017 at 4:16 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> Hi Scott,
>
> There are applications that do not require salt. In this case, all users
> has to do is
> $salt = NULL
> to omit $salt.
>
Great.
On Wed, Feb 8, 2017 at 6:27 AM, Andrey Andre
at salts are optional, the argument to make
them required in PHP's implementation has merit. The only downside is: If
you're integrating with an implementation that doesn't require salts, and
the application doesn't use salts, you're out of luck. Is that enough of a
downside to dismiss an argu
; - Kotlin: `kotlin*`
> - Ceylon: `ceylon*`
> - ...
I would definitely like to see something like this land in 7.2:
$plaintext = \Std\Sodium\box_open($ciphertext, $key, $nonce);
Is everyone willing to allow the coding standard to be updated at all,
though? I'm taking all the No votes spawned by this thread to mean "we
don't want namespaced functions ever".
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>
On Sat, Feb 4, 2017 at 11:16 AM, Nikita Popov <nikita@gmail.com> wrote:
> On Fri, Feb 3, 2017 at 9:44 PM, Scott Arciszewski <sc...@paragonie.com>
> wrote:
>>
>> I've opened the vote for the libsodium RFC.
>>
>> https://wiki.php.net/rfc/libsodium
On Sat, Feb 4, 2017 at 5:37 AM, Fleshgrinder <p...@fleshgrinder.com> wrote:
>
> On 2/4/2017 12:54 AM, Scott Arciszewski wrote:
> > I like \Sodium\foo instead of sodium_foo, but it deviates from the norm.
> > If we're going to break the norm, we should do so on a stronger
On Fri, Feb 3, 2017 at 6:19 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> Hi Scott and all,
>
> On Sat, Feb 4, 2017 at 5:44 AM, Scott Arciszewski <sc...@paragonie.com>
> wrote:
>
>> I've opened the vote for the libsodium RFC.
>>
>> https
I've opened the vote for the libsodium RFC.
https://wiki.php.net/rfc/libsodium
See https://externals.io/thread/626 for the previous discussion topics.
The vote closes at 21:00 UTC (4 PM Eastern Time) next Friday.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <ht
On Mon, Jan 30, 2017 at 4:37 PM, Jakub Zelenka <bu...@php.net> wrote:
> On Mon, Jan 30, 2017 at 7:40 PM, Scott Arciszewski <sc...@paragonie.com>
> wrote:
>
>>
>> On Sun, Jan 29, 2017 at 2:04 PM, Jakub Zelenka <bu...@php.net> wrote:
>>
>>&
In my previous email, there should have been an additional linebreak before:
> Furthermore, I'd like to raise an additional point.
Sorry if that hurt readability.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
On Sun, Jan 29, 2017 at 2:04 PM, Jakub Zelenka <bu...@php.net> wrote:
> Hi,
>
> On Wed, Jan 11, 2017 at 6:22 PM, Scott Arciszewski <sc...@paragonie.com>
> wrote:
>
>> Hi all,
>>
>> I'm resurrecting my RFC to add libsodium as a core extension to PHP
On Tue, Jan 17, 2017 at 5:49 AM, Scott Arciszewski <sc...@paragonie.com>
wrote:
> On Thu, Jan 12, 2017 at 5:23 AM, Julien Pauli <jpa...@php.net> wrote:
>
>> On Wed, Jan 11, 2017 at 7:22 PM, Scott Arciszewski <sc...@paragonie.com>
>> wrote:
>>
>>
All,
Given that we can now declare a class constant as public, protected, or
private, can we also declare them final in 7.2?
https://3v4l.org/rJG0V
Ideally, this code would error on line 18 rather than 15.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <ht
On Thu, Jan 12, 2017 at 5:23 AM, Julien Pauli <jpa...@php.net> wrote:
> On Wed, Jan 11, 2017 at 7:22 PM, Scott Arciszewski <sc...@paragonie.com>
> wrote:
>
>> Hi all,
>>
>> I'm resurrecting my RFC to add libsodium as a core extension to PHP 7.2.
>>
it.
I'm also developing a polyfill for most of the API features (except
pwhash): https://github.com/paragonie/sodium_compat
Warm regards,
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
> sammyk.me
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
There was a little bit of discussion here previously.
http://externals.io/thread/442#email-12842
Scott Arciszewski
Chief Development Officer
Parago
On Sun, Nov 6, 2016 at 2:19 PM, Jakub Zelenka <bu...@php.net> wrote:
> Hi,
>
> On Thu, Nov 3, 2016 at 4:11 PM, Scott Arciszewski <sc...@paragonie.com>
> wrote:
>>
>> Hi,
>>
>> Can we change openssl_public_encrypt() and openssl_private_decrypt() f
writing
their own high-level RSA implementation, we can at least make it safer by
default.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
er to trigger. (Then again, maybe not! The
underlying structure of djb3 isn't exactly cryptographic.)
To be clear, "Yes this is entirely solved without switching away from djb"
+ "No, randomization just hurts opcache and doesn't buy us any security"
are an acceptable set of answers to these questions. I just wanted to ask.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>
Significant degradation?
SipHash 1-3 is almost as fast as HashDoS-vulnerable hash functions:
https://github.com/funny-falcon/funny_hash
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
On Fri, Sep 16, 2016 at 1:59 AM, Thomas Hruska
): https://www.131002.net/siphash/
(Look at all the other languages that already adopted SipHash.)
https://medium.freecodecamp.com/hash-table-attack-8e4371fc5261#.s5r5j42x3
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
https://github.com/php/php-src/pull/1996
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
On Fri, Sep 2, 2016 at 11:18 AM, Scott Arciszewski <sc...@paragonie.com>
wrote:
> I thought someone beat me to it?
>
> Scot
I thought someone beat me to it?
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
On Fri, Sep 2, 2016 at 11:18 AM, Davey Shafik <da...@php.net> wrote:
> I would still be OK adding this in RC2, TBH. I didn't realize it was
>
I was making a reference to the DROWN attack
On Jul 14, 2016 4:28 AM, "Matteo Beccati" <p...@beccati.com> wrote:
> On 13/07/2016 23:42, Scott Arciszewski wrote:
> > If we don't drop SSL2 support we might DROWN in technical debt.
> >
> > This would get a
If we don't drop SSL2 support we might DROWN in technical debt.
This would get a massive +1 from me. (Can we consider dropping SSL3 too in
7.2?)
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
On Wed, Jul 13, 2016 at 3:11 PM, Jakub Zelen
PASSWORD_DEFAULT in 7.3 if
it remains the best option.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
On Sun, Jul 10, 2016 at 1:24 AM, Pierre Joye <pierre@gmail.com> wrote:
>
> On Jul 10, 2016 2:38 AM, "
p.
You MAY cache the escaped output for performance gains, but keep the
unescaped data in the database in case you need to adjust your escaping
strategy without mangling existing data.
Further reading:
https://paragonie.com/blog/2015/06/preventing-xss-vulnerabilities-in-php-everything-you-need-know
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>
;
> http://www.bouncycastle.org/wiki/display/JA1/Elliptic+Curve+Key+Pair+Generation+and+Key+Factories
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
While we're at it, can we also add a function to generate (ephemeral)
Elliptic Curve Diffie-Hellman keys, and then use openssl_dh_compute_key()
with ECDH keys? Because that would be a lot saner than having to
shell_exec() to the OpenSSL binary in userland.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>
hat too.
>
I don't have data, but a word of caution: Don't grep legacy crypto
libraries for use of rand() or mt_rand() for key/IV generation if you want
to feel any sense of optimism. Speaking from experience here! ;)
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>
get them included.
>
> Regards,
>
> Leigh.
>
Good idea. I'm particularly fond of PCG over MT and LCG (but would not
ever use it for a CSPRNG).
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>
On Sun, Jun 5, 2016 at 4:31 AM, Fleshgrinder <p...@fleshgrinder.com> wrote:
> On 6/5/2016 10:23 AM, Scott Arciszewski wrote:
>> I'm trying to keep concerns separate. I do want to make the pluggable
>> crypto API happen, but I barely have time for this libsodium RFC and I
>
Hi Pierre,
On Thu, Jun 2, 2016 at 10:30 AM, Pierre Joye <pierre@gmail.com> wrote:
> hi Scott,
>
> On Wed, Jun 1, 2016 at 2:49 PM, Scott Arciszewski <sc...@paragonie.com> wrote:
>> Hi PHP Internals Team,
>>
>> Let's begin discussing the prospect
On Sun, Jun 5, 2016 at 4:12 AM, Fleshgrinder <p...@fleshgrinder.com> wrote:
> On 6/5/2016 9:46 AM, Scott Arciszewski wrote:
>> Libsodium already knocks it out of the park compared to OpenSSL and
>> Mcrypt. If we want to talk about a higher-level abstraction-- such
ade this far?)
> and more disorganised, so I provide a quick summary:
> - Need better naming, both namespaces and functions
> - Need better docs explaining what the functions do and why
The docs are currently my responsibility; I apologize for not putting
more time into them.
> The
g like that, I
> think these are stopping points.
>
> I would very interested to hear from Scott about these questions and the
> low level nature of the APIs make it not as friendly or future proof as it
> could.
>
> Cheers
> Pierre
>
Hi Pierre,
My position on the low level n
ntegrates nicely into existing PHP. Without confusion over functions
>> that are doing what already existing functions to. With classes that
>> encapsulate complicated stuff and make it hard to get things wrong.
>>
>> --
>> Richard "Fleshgrinder" Fussenegger
>>
>>
>
The birthday bound of a crypto_box or crypto_secretbox nonce, generated
from a CSPRNG, is 2^96 for one collision. If it's gonna happen, you've got
bigger things to worry about.
I should probably state clearly that the concept of an abstract pluggable
crypto API that supports OpenSSL and Libsodium isn't what I'm proposing
here. Just libsodium.
If I find time to write the pluggable crypto API, I will propose that next.
Unfortunately, that likely won't be until 7.2.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>
nice for C but it is definitely not for PHP in my opinion.
>
> Of course I offer my help to find and define such an API if you guys are
> interested in creating one. :)
>
> --
> Richard "Fleshgrinder" Fussenegger
>
>
Well, for what it's worth, I did write https://github.com/paragonie/halite
as a high-level abstraction.
The goal of this RFC is to get the lower-level functionality (which is
still, I promise, a high-level cryptography API) available.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>
On Wed, Jun 1, 2016 at 9:46 AM, Marco Pivetta <ocram...@gmail.com> wrote:
> On 1 June 2016 at 15:45, Scott Arciszewski <sc...@paragonie.com> wrote:
>
>> On Wed, Jun 1, 2016 at 6:48 AM, Marco Pivetta <ocram...@gmail.com> wrote:
>>
>>> Hey Scott,
>&
On Wed, Jun 1, 2016 at 9:46 AM, Marco Pivetta <ocram...@gmail.com> wrote:
> On 1 June 2016 at 15:45, Scott Arciszewski <sc...@paragonie.com> wrote:
>
>> On Wed, Jun 1, 2016 at 6:48 AM, Marco Pivetta <ocram...@gmail.com> wrote:
>>
>>> Hey Scott,
>&
On Wed, Jun 1, 2016 at 6:48 AM, Marco Pivetta <ocram...@gmail.com> wrote:
> Hey Scott,
>
> On 1 June 2016 at 09:49, Scott Arciszewski <sc...@paragonie.com> wrote:
>
>> Hi PHP Internals Team,
>>
>> Let's begin discussing the prospect of adding libsodium
to open voting on
June 15.
Together, let's make PHP cryptography so safe that it becomes boring.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
''
> '===*' 'UUU' 'UUU'
> 'VVVV' 'UUU' 'UU'
> 'VVV*' 'UU''UU'
> 'VV=V' 'UU''U'
> 'VV=*' 'U' 'U'
> '===*' '' ''
>
> --
> Lauri Kenttä
> --
m/jedisct1/libsodium/commit/c752eb55d9e9992bc38e7790128953427aa0a89f
This could be done as a security patch for PHP 7.0.x if there's any concern
about startup entropy e.g. on embedded devices.
I'm not aware of any such projects being written in PHP, so my intuition is
this is a non-issue for us.
Regar
t; --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Yikes, time really flies.
The new ext/sodium is out, so I suppose it's high time to get that RFC
ready to be voted on.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>
threads, the link to the RFC rough
draft is https://wiki.php.net/rfc/libsodium)
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
* 10^-6
seconds).
Are there any real-world applications that would suffer tremendously from
this academic slow-down?
If so, we should discuss how to proceed.
If not, we might want to consider disregarding the penalty entirely.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>
code_ts()
>
> If you have encode functions, you should have decode too? Otherwise,
> you'd have the same issue every time the key is read.
>
> --
> Stas Malyshev
> smalys...@gmail.com
>
Google Authenticator and Tor Hidden Services both use base32. I was also
going to cover the decoding functions in the RFC.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>
ot;: "foo"}', true);
While this does not:
$x = json_decode('{"_empty_": "no", "": "foo"}');
https://3v4l.org/FJHVV
https://3v4l.org/15Sfm
I'm personally 50/50 on it. I think allowing an empty property is kind of
weird, but not the weirdest beh
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Interestingly, extract() skips keys with \x7F: https://3v4l.org/ZC9ZA
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>
uld function like a destroyed
> one)
>
> The combination of the two would resolve most of the security issues and
> establish the __PHP__SESSION__ key which could later be used to handle the
> race condition issue.
>
Could we also add HTTPS detection and enable the secure flag by default
when a session is established on an HTTPS endpoint?
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>
1 - 100 of 508 matches
Mail list logo
