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() might
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
> diff
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, always do danger
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 data the a
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
> m
On Wed, Jun 23, 2021 at 10:54 AM Craig Francis wrote:
>
> On Wed, 23 Jun 2021 at 14:37, Larry Garfield wrote:
>
> > I'm still very torn on is_literal; I fear that the people who would
> > benefit from it are the very people that don't use the tools that would
> > leverage it (DBALs et al), and so
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
hing new, in true Internals 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 Develo
On Fri, Nov 3, 2017 at 3:49 PM, Matteo Beccati 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?
> > 2. Is there a b
es:
1. Which DB drivers (and which versions) 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/paragon
On Sun, Jul 2, 2017 at 12:51 PM, Scott Arciszewski
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-312452732
>
> I'
mp;e=
>> 8a589076f305c31501565a2cfe0f6ff;hb=refs/heads/master
>>
>>
> --
> http://twitter.com/ghrd
>
>
>
> --
> PHP Internals - 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/>
voted for better cryptography in
PHP 7.2.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
t? Not so much.
In cryptography protocols, salts are considered 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 Tue, Feb 7, 2017 at 10:22 PM, Scott Arciszewski
> wrote:
>
>>
>>
>> Although the RFC itself says that salts are optional, the argument to
>> make them required in PHP's implementation has merit. The only downside is:
>> If you're integrating with
lts 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 arg
; - 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 wrote:
> On Fri, Feb 3, 2017 at 9:44 PM, Scott Arciszewski
> wrote:
>>
>> I've opened the vote for the libsodium RFC.
>>
>> https://wiki.php.net/rfc/libsodium
>>
>> See https://externals.io/thread/62
On Sat, Feb 4, 2017 at 5:37 AM, Fleshgrinder 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 majority
> > than
On Fri, Feb 3, 2017 at 6:19 PM, Yasuo Ohgaki wrote:
> Hi Scott and all,
>
> On Sat, Feb 4, 2017 at 5:44 AM, Scott Arciszewski
> wrote:
>
>> I've opened the vote for the libsodium RFC.
>>
>> https://wiki.php.net/rfc/libsodium
>>
>> See https://e
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 &
On Mon, Jan 30, 2017 at 4:37 PM, Jakub Zelenka wrote:
> On Mon, Jan 30, 2017 at 7:40 PM, Scott Arciszewski
> wrote:
>
>>
>> On Sun, Jan 29, 2017 at 2:04 PM, Jakub Zelenka wrote:
>>
>>> Hi,
>>>
>>> On Wed, Jan 11, 2017 at 6:22 PM, Scott
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 wrote:
> Hi,
>
> On Wed, Jan 11, 2017 at 6:22 PM, Scott Arciszewski
> wrote:
>
>> Hi all,
>>
>> I'm resurrecting my RFC to add libsodium as a core extension to PHP 7.2.
>>
>>
> I'm still
On Tue, Jan 17, 2017 at 5:49 AM, Scott Arciszewski
wrote:
> On Thu, Jan 12, 2017 at 5:23 AM, Julien Pauli wrote:
>
>> On Wed, Jan 11, 2017 at 7:22 PM, Scott Arciszewski
>> wrote:
>>
>>> Hi all,
>>>
>>> I'm resurrecting my RFC to add libso
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 wrote:
> On Wed, Jan 11, 2017 at 7:22 PM, Scott Arciszewski
> wrote:
>
>> Hi all,
>>
>> I'm resurrecting my RFC to add libsodium as a core extension to PHP 7.2.
>>
>> In response to feedback from P
reatly
appreciate 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>
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
Paragon Initiative En
On Sun, Nov 6, 2016 at 2:19 PM, Jakub Zelenka wrote:
> Hi,
>
> On Thu, Nov 3, 2016 at 4:11 PM, Scott Arciszewski
> wrote:
>>
>> Hi,
>>
>> Can we change openssl_public_encrypt() and openssl_private_decrypt() from
>> defaulting to PKCS1v1.5 padding,
tographers from 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>
n 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
wrote:
derivative): 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
wrote:
> I thought someone beat me to it?
>
> Scott Arciszewski
> Chief Development
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 wrote:
> I would still be OK adding this in RC2, TBH. I didn't realize it was
> missed, and it'
I was making a reference to the DROWN attack
On Jul 14, 2016 4:28 AM, "Matteo Beccati" 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 massive +1 from me. (Ca
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, Ja
be the new 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 wrote:
>
> On Jul 10, 2016 2:38 AM, "Charles R. Portwood II" &
AY 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/>
ric/ec/
> [8] https://golang.org/pkg/crypto/elliptic/#GenerateKey
> [9]
>
> 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/>
ave 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/>
> 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 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
>> don't want to c
Hi Pierre,
On Thu, Jun 2, 2016 at 10:30 AM, Pierre Joye wrote:
> hi Scott,
>
> On Wed, Jun 1, 2016 at 2:49 PM, Scott Arciszewski wrote:
>> Hi PHP Internals Team,
>>
>> Let's begin discussing the prospect of adding libsodium as a core extension
>> in PHP 7.
On Sun, Jun 5, 2016 at 4:12 AM, Fleshgrinder 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 as
>> what's provided by para
n't we have something more concise and put the rest in
> the docs?
That's a point worth considering. (Alternatively: Eschew scrypt.)
> This came out longer than I expected (hopefully somebody made this far?)
> and more disorganised, so I provide a quick summary:
> - Need better nam
sounds like a call to action for https://wiki.php.net/rfc/php71-crypto
rather than a point of concern for adopting libsodium.
Compare the following two snippets which accomplish the same "goal"
(anonymous public-key encryption).
https://3v4l.org/nYVPf
Here's a congrue
ly 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/>
t 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 wrote:
> On 1 June 2016 at 15:45, Scott Arciszewski wrote:
>
>> On Wed, Jun 1, 2016 at 6:48 AM, Marco Pivetta wrote:
>>
>>> Hey Scott,
>>>
>>> On 1 June 2016 at 09:49, Scott Arciszewski wrote:
>>
On Wed, Jun 1, 2016 at 9:46 AM, Marco Pivetta wrote:
> On 1 June 2016 at 15:45, Scott Arciszewski wrote:
>
>> On Wed, Jun 1, 2016 at 6:48 AM, Marco Pivetta wrote:
>>
>>> Hey Scott,
>>>
>>> On 1 June 2016 at 09:49, Scott Arciszewski wrote:
>>
On Wed, Jun 1, 2016 at 6:48 AM, Marco Pivetta wrote:
> Hey Scott,
>
> On 1 June 2016 at 09:49, Scott Arciszewski wrote:
>
>> Hi PHP Internals Team,
>>
>> Let's begin discussing the prospect of adding libsodium as a core
>> extension
>> in PHP 7.1.
ld like 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>
;U'
> 'VV== ' 'U' 'U'
> 'VV= =' 'U' (false)
> 'VVV=V' 'UUU' 'UU'
> '=*' 'UUU' 'UUU'
&
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
HP 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
ny measured a _negligible_ performance hit (5 * 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/>
> 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/>
quot;}', 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 weirde
s://ajf.me/
>
> --
> 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/>
ction 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/>
On Tue, Mar 22, 2016 at 7:11 PM, Andrea Faulds wrote:
> Hi Scott,
>
> Scott Arciszewski wrote:
>
>> PHP already offers bin2hex()/hex2bin() and
>> base64_encode()/base64_decode().
>> This covers part, but not all, of RFC 4648.
>>
>> I'd like to ext
No objections here.
On Mar 22, 2016 3:23 PM, "Stanislav Malyshev" wrote:
> Hi!
>
> > be in the spirit of what was voted on to keep it (at least as an alias
> for
> > random_bytes()). However, that was not covered by what everyone voted
> for.
> > How would you like to proceed?
>
> I'd say keep it
lternative implementation. i.e.
* bin2hex_ts()
* base64_encode_ts()
* base32_encode_ts()
Does anyone have any questions or concerns?
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
On Tue, Mar 22, 2016 at 2:21 PM, Nikita Popov wrote:
> On Tue, Mar 22, 2016 at 6:00 PM, Scott Arciszewski
> wrote:
>
>> Hi all,
>>
>> https://wiki.php.net/rfc/mcrypt-viking-funeral
>>
>> The tally of closing (2016-03-22T17:00:00) is 23 Yes, 6 No. This is
On Tue, Mar 22, 2016 at 1:41 PM, Ferenc Kovacs wrote:
>
>
> On Tue, Mar 22, 2016 at 6:00 PM, Scott Arciszewski
> wrote:
>
>> Hi all,
>>
>> https://wiki.php.net/rfc/mcrypt-viking-funeral
>>
>> The tally of closing (2016-03-22T17:00:00) is 23 Yes, 6
ch written soon.
Additionally, I will have a decrypt-only mcrypt polyfill project written
hopefully before 7.1.0-alpha but definitely before 7.1.0. This will allow
people to migrate towards something better, e.g.
openssl_encrypt()/openssl_decrypt().
Scott Arciszewski
Chief Development Officer
Par
PHP developers will be given more than enough rope to
hang themselves (and the company they work for) with their fumbled
cryptography engineering. Let's take away the noose and give everyone a
safety net.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>
it is provided for people
reading the RFC that miss parts of the mailing list discussion.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
Noted and agreed.
On Mar 15, 2016 9:56 PM, "David Zuelke" wrote:
> I think I've said this before; please call it ext-sodium, not
> ext-libsodium.
>
> David
>
>
> > On 15.03.2016, at 18:40, Scott Arciszewski wrote:
> >
> > Link to RFC: https://
On Tue, Mar 15, 2016 at 1:59 PM, Fleshgrinder wrote:
> On 3/15/2016 6:40 PM, Scott Arciszewski wrote:
> > Link to RFC: https://wiki.php.net/rfc/libsodium
> >
> > I'd like to bump the RFC to make Libsodium a core extension, as per
> > Ferenc's suggestion on
c()
As it currently stands, the PHP extension in PECL uses a namespace +
function format.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
On Tue, Mar 15, 2016 at 1:09 PM, Ferenc Kovacs wrote:
>
>
> On Tue, Mar 15, 2016 at 5:11 PM, Scott Arciszewski
> wrote:
>
>> Hi PHP team,
>>
>> I've opened the vote on https://wiki.php.net/rfc/mcrypt-viking-funeral
>> which aims to deprecate ext/mcryp
On Tue, Mar 15, 2016 at 12:26 PM, Pierre Joye wrote:
> On Mar 16, 2016 12:22 AM, "Remi Collet" wrote:
> >
> > Le 15/03/2016 17:11, Scott Arciszewski a écrit :
> > > Hi PHP team,
> > >
> > > I've opened the vote on
> >
ion of the mcrypt ciphers so people can migrate their
code towards something better.
This vote is opened on March 15th, 2016 and will close March 22th at 17:00
UTC.
(Sidenote: Apologies for the brief unannounced hiatus from participating
here.)
Scott Arciszewski
Chief Development Officer
Paragon
ls - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
What worries me is when memory corruption bugs are published in the RC#
changelog before the fix is available. That could bite us one day.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>
d good, and
> reduce them within the maximum range.
>
> I joined the other person proposing not to change anything else in our
> MT implementation as there is little to no benefit.
>
> If we need pure implementation of one pseudo RNG or another, we can
> provide new implementa
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
Have I shared this here?
https://github.com/paragonie/seedspring
Warning: May summon Cthulhu if deployed to production.
Sc
them in scope.
So I disagree that notions such as, "IIRC we needed it one, two times over
20 years?" are worth any future consideration.
Let's start with a solution that is appropriate for 50% or more of
situations, and take it one step at a time. There are no 100% or even 99%
sol
Let's start with a rhetorical question: When you are adding unit tests to a
legacy code base, where do you start?
...
Typically, you start at the extremes and work your way to the core of the
application, refactoring as you need to go.
I think many people agree that a Code of Conduct, in the abs
Hey,
I haven't submitted the pull request yet.
I'm waiting to see how the Argon2 team handles the mitigation for an attack
on the memory-hardness of Argon2i (specifically; other Argon2 variants were
unaffected).
So if anyone was holding their breath, please don't. :)
Scott Ar
rep ^Encoded
> Encoded:
> $argon2d$m=4096,t=3,p=1$c2FsdA$Js0T8jeqwDeja/AQ+x2o4SUn22MofUW2f88RlMRhQso
>
> I haven't been involved in this closely, though.
>
> Alexander
I'm going to write the pull request tonight then. If there's any
reason to not merge it, plea
Does adding Argon2 as a possible choice for password_hash() +
password_verify() need an RFC? Or can I just submit a pull request?
It won't be changing the default in 7.1, and IIRC this sort of change
was already agreed upon as part of the original password_hash() RFC.
Scott Arciszewski
On Sun, Jan 10, 2016 at 6:56 PM, David Zuelke wrote:
> Can we call that extension "sodium" please without the "lib" prefix?
>
> David
>
>
>> On 07.01.2016, at 08:26, Scott Arciszewski wrote:
>>
>> Hi everyone,
>>
>> I
On Sun, Jan 10, 2016 at 4:59 PM, Rowan Collins wrote:
> On 10/01/2016 21:41, Scott Arciszewski wrote:
>>
>> Hi Rowan,
>>
>>> >I think what people are suggesting is not that libsodium shouldn't be
>>> >supported under-the-hood, just that the fact
On Sun, Jan 10, 2016 at 4:31 PM, Rowan Collins wrote:
> On 07/01/2016 16:11, Scott Arciszewski wrote:
>>
>> I'm personally not going to bother pushing
>> for a pluggable crypto API if the only option is to use OpenSSL and
>> all its legacy cruft.
>
>
>
I've proposed across several RFCs
is superior to maintaining the status quo.
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
we can make PHP 7.1 the pinnacle of usable security. :)
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
On Thu, Jan 7, 2016 at 1:32 PM, Lior Kaplan wrote:
> On Jan 7, 2016 6:59 PM, "Remi Collet" wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Le 07/01/2016 17:54, Scott Arciszewski a écrit :
>> > All,
>> >
>&g
is the stuff of
nightmares. I recall an 800+ line C function. (Have fun auditing
that!)
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
On Thu, Jan 7, 2016 at 10:51 AM, Pierre Joye wrote:
> HI Scott,
>
> On Thu, Jan 7, 2016 at 8:26 PM, Scott Arciszewski wrote:
>> Hi everyone,
>>
>> I've updated the RFC to make libsodium a core PHP extension in 7.1, to
>> include references to the online doc
On Thu, Jan 7, 2016 at 10:54 AM, Scott Arciszewski wrote:
> On Thu, Jan 7, 2016 at 10:52 AM, Rouven Weßling
> wrote:
>> Hi Scott,
>>
>> questions inline.
>>
>>> On 07 Jan 2016, at 14:26, Scott Arciszewski wrote:
>>>
>>> I've upd
On Thu, Jan 7, 2016 at 10:52 AM, Rouven Weßling wrote:
> Hi Scott,
>
> questions inline.
>
>> On 07 Jan 2016, at 14:26, Scott Arciszewski wrote:
>>
>> I've updated the RFC to make libsodium a core PHP extension in 7.1, to
>> include references
On Thu, Jan 7, 2016 at 10:20 AM, Bishop Bettini wrote:
> On Thu, Jan 7, 2016 at 8:26 AM, Scott Arciszewski
> wrote:
>>
>> I've updated the RFC to make libsodium a core PHP extension in 7.1, to
>> include references to the online documentation.
>>
>> htt
at
deprecating ext/mcrypt back to PECL and add more hash functions to
ext/hash.
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
1 - 100 of 192 matches
Mail list logo
