te: Tue, Nov 25, 2014 at 12:07 AM
Subject: Re: [php-src] Constant-Time bin2hex() implementation (#909)
To: php/php-src
Cc: Scott Arciszewski
@sarciszewski <https://github.com/sarciszewski> you can drop a mail to
internals at lists.php.net :)
—
Reply to this email directly or view it on GitH
t; -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/25/2014 07:37 AM, Scott Arciszewski wrote:
> > I would like to, at the minimum, suggest making the following
> > functions run in constant time:
> >
> > * bin2hex() * hex2bin() * base64_encode() * base
That is why I updated the PR and made it add a function (ts_bin2hex())
instead of replacing the existing behavior.
I could have sworn I already sent this to the list.
On Wed, Nov 26, 2014 at 3:45 PM, Korvin Szanto
wrote:
> I don't like the idea of any mandatory slow down, trivial or not. This
>
Forgot to reply all, it seems.
-- Forwarded message --
From: Scott Arciszewski
Date: Wed, Nov 26, 2014 at 11:59 AM
Subject: Re: [PHP-DEV] Fwd: [php-src] Constant-Time bin2hex()
implementation (#909)
To: Ferenc Kovacs
On Wed, Nov 26, 2014 at 11:49 AM, Ferenc Kovacs wrote
Hi PHP Internals,
I've been trying to get in contact with the maintainers of libmcrypt, but
every response I've gotten was, "Oh, I haven't been a part of that for
years."
http://sourceforge.net/projects/mcrypt/files/Libmcrypt/
The last update to libmcrypt was in 2007. There are bug fixes in thei
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Le 05/12/2014 17:17, Scott Arciszewski a écrit :
> > Hi PHP Internals,
> >
> > I've been trying to get in contact with the maintainers of
> > libmcrypt, but every response I've gotten was, &q
http://lukasmartinelli.ch/web/2014/11/17/php-dos-attack-revisited.html
Sigh
Not all json_decode()s will operate on user-supplied data. Why not add a
DoS-resistant variant?
I propose the addition of json_safe_decode() to use a randomized hash.
I'm not trolling about the bin2hex() -> ts_bin2hex() when I say this. Well,
not entirely.
On Tue, Dec 23, 2014 at 3:16 PM, Andrea
Hi PHP Internals,
Right now, the libsodium PECL package is in the beta channel. Would it be
possible to include libsodium as a core extension in PHP 7? If so, what
hurdles would need to be cleared before that happens?
http://doc.libsodium.org/
http://pecl.php.net/package/libsodium
https://github.
gt;
> libsodium is too young to seriously consider bundling right now I
> think.
>
> Cheers
> Joe
>
> On Fri, Jan 2, 2015 at 5:05 PM, Scott Arciszewski
> wrote:
>
>> Hi PHP Internals,
>>
>> Right now, the libsodium PECL package is in the beta chann
Hello,
Would it be possible for php.net to publish a cryptographically signed
(e.g. openssl_sign() with a RSA private key kept offline) list in a
pre-defined location (e.g. /stable_versions.txt) so that scripts can be
written to read (and cache) the latest stable versions?
I'm going to write a ki
> That said, if you're OK trusting HTTPS and can do without the manual
signing step,
I'm not and cannot. After Diginotar and the Snowden revelations, I place
zero trust in CAs. :)
> we have an unadvertised JSON backend that can provide
> the stable release information you'd need:
> https://php.ne
You're right, a cursory Google search reveals that someone is maintaining a
php5-nacl package that uses libsodium. This simplifies instructions
greatly! :D
On Jan 9, 2015 6:11 AM, "Johannes Schlüter" wrote:
> On Fri, 2015-01-02 at 12:05 -0500, Scott Arciszewski wrote:
Hi everybody,
I've squashed and rebased my pull request that adds a cache-timing-safe
bin2hex implementation (named ts_bin2hex) to PHP.
https://github.com/php/php-src/pull/909
Before I put more effort into the inverse operation (which, from what I can
tell, is already constant-time), does anyone
As per the conversation on this Pull Request
https://github.com/php/php-src/pull/909#issuecomment-71077928
What functions are involved in real world PHP applications (frameworks,
popular CMSes, etc) that operate on encoded encryption keys that might
benefit from having a timing-safe implementation
https://wiki.php.net/rfc/timing_safe_encoding
Pavel_Kouřil wrote:
> - It is a "setting" that changes the language's behavior; I don't
> think that it matters whether or not it would be an INI setting or the
> declare() one, because both of them are bad.
>
> It allows people who want strict typing to declare it on a per-PHP-file
basis. An INI
On Mar 15, 2015 6:23 AM, "Pavel Kouřil" wrote:
>
> On Sun, Mar 15, 2015 at 9:56 AM, Leigh wrote:
> >
> > On 15 March 2015 at 08:42, Pavel Kouřil wrote:
> >>
> >> Sure, per-file is better than ini setting, but better doesn't mean
> >> good (because it is still a pretty bad approach). The ini sett
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
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, 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 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 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 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 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
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
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 { __
I'd vote yes on this one, if it were an RFC. Please expedite this
deprecation for 7.0.
Can we also deprecate MCRYPT_RAND? I opened an RFC for that a long time ago
and just remembered it.
is a good time to talk about the possibility of making
libsodium a core PHP extension, depending on where things are when we near
the 7.1 feature freeze.
I've just opened an RFC for precisely this purpose:
https://wiki.php.net/rfc/libsodium
Regards,
Scott Arciszewski
Chief Development Offic
ly, has never used
the library before.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
On Fri, May 22, 2015 at 2:26 AM, Michael Wallner wrote:
> On 21/05/15 09:49, Peter Petermann wrote:
> > Hi Scott,
> >
> > I personally
isct1/libsodium GitHub repository.
On May 25, 2015 2:10 AM, "Yasuo Ohgaki" wrote:
> Hi Scott,
>
> On Thu, May 21, 2015 at 10:15 AM, Scott Arciszewski
> wrote:
>
>> Hi Internals Team,
>>
>> I'm sure everyone is really focused (and excited) for PHP 7.0.0
guage already has".
Am I mistaken in believing this would be the way forward?
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
On Tue, May 26, 2015 at 6:47 PM, Anthony Ferrara
wrote:
> Scott,
>
> On Wed, May 20, 2015 at 9:15 PM,
Naive answer: P(inclusion) = 0, due to the feature freeze. Unless I'm
mistaken.
If so, you might need to target 7.1 instead of 7.0.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
On Fri, May 29, 2015 at 2:56 PM, Hanne
ut I'm not sure if there's a better solution.
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
You're right, I misread that part of the documentation.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises
On Wed, Jul 8, 2015 at 6:03 AM, Nikita Popov wrote:
> On Wed, Jul 8, 2015 at 11:59 AM, Scott Arciszewski
> wrote:
>>
>> Hi everyone,
paragonie/random_compat if that helps
anyone acquire it (and, once v1.0.0 is released, include it in your
projects easier).
Please share this with any crypto / security folks that might be
interested in reviewing it.
https://github.com/paragonie/random_compat/issues/11
Thanks,
Scott Arciszewski
Chief D
pt, a caught exception can
let the developer decide how to proceed.
I'd vote in favor of Exceptions (which, by default, will fail closed
but can be handled gracefully through try-catch blocks) rather than
E_WARNING (which fails open) or E_ERROR (which doesn't allow for
graceful handling).
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
zero entropy.
TL;DR we have three options:
1. E_WARNING - fail open, possibly cause security problems for the user
2. E_ERROR - fail closed, but make graceful handling a pain in the neck
3. Exception - fail closed by default, developer can write their own
graceful failure code if they so
On Wed, Jul 15, 2015 at 6:57 AM, Yasuo Ohgaki wrote:
> Hi Scott,
>
> On Wed, Jul 15, 2015 at 7:19 PM, Scott Arciszewski
> wrote:
>>
>> On Wed, Jul 15, 2015 at 4:27 AM, Yasuo Ohgaki wrote:
>> > Hi Sammy,
>> >
>> > On Wed, Jul 15, 2015 at 6:04
Just don't expect me
to be quiet when, in future versions, we transition back to an
Exception. Failing closed is my only priority here.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises
On Wed, Jul 15, 2015 at 7:27 AM, Yasuo Ohgaki wrote:
> Hi Scott,
>
> On W
other selling point for upgrading
swiftly. :)
Though my second vote probably won't count for anything.
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
Aaron Piotrowski
I must have overlooked a detail here.
According to https://github.com/tpunt/PHP7-Reference#throwable-interface
there are Throwables called Error, as a separate designation from an
exception. I didn't see this in the engine exceptions RFC, so I was
unaware that was even a thing.
I
gt;
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
What's easier to read and less likely to result in bugs?
require_once __DIR__ . '/../../../../autoload.php';
or
require_once dirname(__FILE_
> excellent suggestion.
> >
> > Previously, I thought the suggestion was to stick to triggering errors
> > (E_ERROR, E_RECOVERABLE_ERROR, etc.).
> >
> > Scott Arciszewski
> > Chief Development Officer
> > Paragon Initiative Enterprises <https://parag
ed in time for
RC1, consistency should take a back seat to security. Fail hard, throw
an Error, deal with the details later.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises
On Mon, Jul 27, 2015 at 2:53 AM, Anatol Belski wrote:
> Hi Aaron,
>
>> -Origina
On Mon, Jul 27, 2015 at 10:27 AM, Rowan Collins wrote:
> Scott Arciszewski wrote on 27/07/2015 07:57:
>>
>> My only concern is that, we have a fixed timetable for the 7.0.0
>> release. It's certainly a good idea to develop a cogent strategy
>> before moving forwar
On Mon, Jul 27, 2015 at 1:04 PM, Rowan Collins wrote:
> Scott Arciszewski wrote on 27/07/2015 15:45:
>>
>> The problem with fatal errors is that "This function can fail
>> irrecoverably outside of your control" isn't going to encourage
>> adoption.
>
Thoughts?
>
> Anthony
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
Enormous +1 to this from me. This should definitely be off by default.
Scott Arciszewski
Chief Development Officer
Paragon Initiative E
On Thu, Jul 30, 2015 at 11:20 AM, Craig Francis
wrote:
> On 30 Jul 2015, at 14:43, Scott Arciszewski wrote:
>
>> This may have been true at one point in time, but my own experience
>> and the statistics collected by Dan Kaminsky of White Hat Security
>> indicates t
fer Exception (easier
to write a sane backport for PHP 5.6) but I leave this decision in the
hands of others.
/**
* Slightly insane PHP 5 backport but it works
*/
class Error extends Exception { } // Done!
Does anybody feel particularly strong about one or the other?
If so
;)
If there's anything I can do to get those two merged faster, please let me
know.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
security expert, they'll back me up.
Don't enforce insecure defaults just because it's more "consistent".
Consistency is important, sure, but security is MORE important.
Also, death to libmcrypt:
https://paragonie.com/blog/2015/05/if-you-re-typing-word-mcrypt-into-your-code-you-re-doing-it-wrong
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 Fri, Jul 31, 2015 at 8:23 PM, Ferenc Kovacs wrote:
>
>
> On Sat, Aug 1, 2015 at 2:00 AM, Scott Arciszewski
> wrote:
>>
>> On Fri, Jul 31, 2015 at 6:34 PM, Ferenc Kovacs wrote:
>> >
>> > On Tue, Jul 14, 2015 at 11:04 PM, Sammy Kaye Powers
>
t; Exception.
Hi Nikita,
This sounds reasonable to me. As I've said before, I don't have any
real preference for which is thrown. If Aaron (author of the Throwable
RFC that passed unanimously) wants to chime in, I'd almost certainly
go with whatever you, him, and Anthony could ag
;d like to
see any of these happen. If you have specific implementation details
you'd like to discuss or requests, of course those are welcome too. :D
"With great ubiquity comes great responsibility." - Matthew Green
<https://twitter.com/matthew_d_green/status/578567678
:encrypt() will always Encrypt then MAC, and verify the
MAC (in constant time!) before decrypting, and the user never has to
concern themselves with such details. All they will know is that their
messages are encrypted, and tampering with the encrypted data throws
an exception when they try to decr
On Tue, Aug 4, 2015 at 4:13 AM, Lauri Kenttä wrote:
> On 2015-08-03 23:54, Scott Arciszewski wrote:
>>
>> $AES = new \PCO\Symmetric('openssl:cipher=AES-128');
>
>
> It would be great if you could just ask for cipher=AES-128 without
> explic
On Tue, Aug 4, 2015 at 4:26 AM, Peter Lind wrote:
> On 4 August 2015 at 10:13, Lauri Kenttä wrote:
>>
>> On 2015-08-03 23:54, Scott Arciszewski wrote:
>>>
>>> $AES = new \PCO\Symmetric('openssl:cipher=AES-128');
>>
>>
>> It wo
On Tue, Aug 4, 2015 at 8:06 AM, Peter Lind wrote:
> On 4 August 2015 at 13:56, Scott Arciszewski wrote:
>>
>>
>> Hi Peter,
>>
>> It's not really a "made-up string format", in the sense that it has a
>> precedent (PDO).
>>
>
> True
On Tue, Aug 4, 2015 at 8:57 AM, Jakub Zelenka wrote:
> Hi,
>
> On Mon, Aug 3, 2015 at 9:54 PM, Scott Arciszewski
> wrote:
>>
>> Hi,
>>
>> I would like to make it easier for PHP developers to implement
>> cryptography features in their applications. I in
.hu
Not to pile in another voice from not a long-term participant, but
here's my unsolicited $0.02 on this matter:
Personally, I'd be fine with Google Groups. I recently set a few up
for internal discussions (mostly to coordinate future blog posts for
Paragon and brainstorm project ideas) and they're quite pleasant.
One question (open for everyone, I don't necessarily expect Ferenc to know):
Can we still archive messages on third-party sites (e.g.
gmane.org/marc.info)? I've not delved into integration yet.
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 Tue, Aug 4, 2015 at 11:50 AM, Pierre Joye wrote:
> On Tue, Aug 4, 2015 at 3:54 AM, Scott Arciszewski wrote:
>> Hi,
>>
>> I would like to make it easier for PHP developers to implement
>> cryptography features in their applications. I intend to work on some
>&g
during decryption by keeping MACs of each chunk
in memory and verifying each before continuing decryption, so race
conditions (i.e. overwriting or rearranging blocks in the file after
the MAC has been verified) will not allow arbitrary ciphertext
forgery.
If there is a cryptography concern not listed above, that means it
either isn't fresh on my memory (i.e. it's obvious), or it hasn't come
up and might be a source of insecurity in the current iteration of
File.php :O
With all that said, more scrutiny is always welcomed.
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 Tue, Aug 4, 2015 at 10:18 PM, Scott Arciszewski wrote:
> On Tue, Aug 4, 2015 at 8:55 PM, Stanislav Malyshev
> wrote:
>> Hi!
>>
>>> The idea here isn't too far removed from what PDO does versus mysql_*,
>>> mssql_*, pgsql_*, etc. except it's prob
ve I been actively involved.
>
> Anthony
Yeah, sorry, that was my mistake. One of many, I mean.
Sorry for any confusion.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
thing*. As for the particulars of what
should be an Exception and what should be an Error, I don't have a
horse in this race. Exceptions already existed and Errors were already
accepted in the Throwable RFC, so I don't believe this warrants
another RFC and putting this decision off until
; still add one case where a different type is returned on error. This makes
>> random_int from a function returning int, to a function returning int|null.
>
> I would also be in favor of throwing TypeError from zpp calls in new functions
> (and quite frankly, from zpp calls i
las
I agree that this should be a relatively high priority. I'm not sure
what the next steps would be. (Aside: I still have a PR I need to
write that I've been holding off on until the fate of PHP 7's CSPRNG
feature is determined.)
Can we reach some sort of consensus on throw new Ex
On Fri, Aug 21, 2015 at 3:52 AM, Pierre Joye wrote:
> On Fri, Aug 21, 2015 at 9:38 AM, Scott Arciszewski
> wrote:
>> On Wed, Aug 19, 2015 at 11:36 AM, Trevor Suarez wrote:
>>> Ah, I didn't realize this thread existed. I had just commented on the old
>>&
; On Aug 21, 2015 8:10 PM, "Anatol Belski" wrote:
> > >>
> > >> Hi,
> > >>
> > >> > -Original Message-----
> > >> > From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> > >> > Sent: Friday, August 21, 2015 3:37 PM
> &
this RFC up to vote on August 29/30th.
>
> Thanks!
>
> Anthony
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
That still gives us plenty of time before 7.0.0 is finalized, so I
find this agreeable.
Scott
_ERROR), will do far more to make PHP applications
secure than telling people they should RTFM.
Hackers have been saying RTFM since the ARPANET days, and yet most
people still don't. It's a losing battle. Let's patch what we can with
good design decisions.
TL;DR - the path f
> > user land.
>
> If it would be so easy to implement this function, there would be no problems
> with weak passwords in PHP software.
> You can also implement fopen('/dev/urandom','rb') in userland without having
> random_int().
>
> Regards
> Thoma
.0 so, if there is any interest, I would respectfully put it off
until 7.1.
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 Tue, Aug 25, 2015 at 11:11 PM, Sherif Ramadan
wrote:
> That's exactly what isset() does. isset/empty never raise errors.
>
> On Tue, Aug 25, 2015 at 11:09 PM, Scott Arciszewski
> wrote:
>>
>> Hi everybody,
>>
>> Would anyone be interested in ad
Because $x exists.
https://3v4l.org/kUJtP
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises
On Tue, Aug 25, 2015 at 11:16 PM, Sherif Ramadan
wrote:
> Yes, because all undefined variables in PHP are implicitly null. As far as
> PHP is concerned, if it's nu
;
>> > A quick solution could be using the mutex functionality exported from
>> > TSRM
>> > (tsrm_mutex_*() functions) in the thread safe builds for affected
>> > functions.
>> >
>> >
>> >
>> Yeah I was thinking about that after I sent an email yesterday. I will check
>> if
>> there are more places where this can be an issue and try to put together a
>> patch.
>>
> TSRM is probably the best we have in the core right now. Mutex will sure have
> a performance impact, but probably no way around it as openssl is always
> external. After yet looking at the APIs, maybe one could setup the default
> rand in MINIT, or force it to be always RAND_SSLeay(), but not sure it is a
> better idea than locking.
>
> Regards
>
> Anatol
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
At the risk of sounding silly, can we just use random_bytes()? :)
Additionally, I'd like to (for example) be able to use ChaCha20
instead of RC4. Is that what the (currently undocumented) $method
parameter is for?
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
de that this variable should not be used below this point.
>>
>> There IS something wrong with any code which needs to distinguish which of
>> those two things happened, at run-time, because such code would be
>> incredibly fragile and hard to follow.
>>
>> Y
of this behavior.
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, Sep 3, 2015 at 2:33 AM, Ferenc Kovacs wrote:
>
> 2015. szept. 3. 6:14 ezt írta ("Scott Arciszewski" ):
>>
>> Inspired by http://stackoverflow.com/a/12202218/2224584
>>
>> Can we (in either PHP 7.0 or in PHP 7.1) turn emulated prepared
>&
On Thu, Sep 3, 2015 at 4:08 AM, Kalle Sommer Nielsen wrote:
> Hi Scott
>
> 2015-09-03 6:14 GMT+02:00 Scott Arciszewski :
>>
>> Inspired by http://stackoverflow.com/a/12202218/2224584
>>
>> Can we (in either PHP 7.0 or in PHP 7.1) turn emulated prepared
>&g
rpose, even commercial. If there's still a problem, let me
know if something else (WTFPL?) would work better for your needs.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
--
PHP Internals - PHP Runtime Development Mailing List
To un
ssues. And then if
we can get it merged by 7.0.0-RC4, I'd be estatic.
https://github.com/php/php-src/pull/1513
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
--
PHP Internals - PHP Runtime Development Mailing List
To uns
ction prototype:
> string random_str( int $length, string $charset)
Would return a string or throw an Error|Exception (e.g. invalid input
parameters, or the operating system's CSPRNG begins to melt).
I can write up an RFC for this, with a patch targeting 7.1, if anyone
is interested
On Fri, Oct 2, 2015 at 5:10 PM, Tom Worster wrote:
> I screwed up sending this earlier. Sorry if you get this twice.
>
> On 9/30/15 12:15 PM, Scott Arciszewski wrote:
>> I think random_bytes() and random_int() are great; they provide a
>> much-needed building block in PHP 7.0
_dotnet in php-src.
References:
http://stackoverflow.com/questions/6497670/calling-rngcrypto-from-coms-dotnet-class-from-php
https://github.com/paragonie/random_compat/issues/67
http://community.sitepoint.com/t/php-and-net-secure-rndnum-generation-using-dotnet-class/86511
Scott Arciszewski
Chief
inding at least one collision.
It should go without saying, but if users have weak/common password
choices and their salts collide, they will end up with duplicate
bcrypt hashes.
My conclusion is thus: Yes, we do need a CSPRNG here, especially if we
want to encourage the use of the password_* API
As much as I had been looking forward to it soon, haste does makes waste.
Making a more responsible choice for the users is commendable and outweighs
the inconvenience a mere two week delay.
+1 from me.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <ht
If nothing else, it will give us an excuse to avoid the Black Friday
madness ("Sorry hon, I need to update the server!").
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
On Sun, Nov 8, 2015 at 8:35 PM, Rasmus Lerdorf wrote:
&g
Hi internals,
Compare https://3v4l.org/JW5lp with https://3v4l.org/mdEkO
Why doesn't GCM work? Can it be fixed?
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
Hi,
It has been brought to my attention that my consistent use of \ prefixing
of global functions is an eyesore, but I've got a simple little PoC that
shows why I do it, and now I'm wondering if the behavior I'm working around
should qualify as a PHP bug?
https://3v4l.o
Stanislav, Anthony:
Okay, I just wanted to make sure I wasn't overlooking an unintended
behavior. I'm going to continue using \explicit_prefixing().
http://userjac.com/wp-content/uploads/2014/05/haters-gonna-hate-cool-dog.jpg
Scott Arciszewski
Chief Development Officer
Paragon
tribute
> whenever you want ;-)
>
> Bob
>
> P.s.: but I guess you can safely assume there won't be any release in the
> next 6 months.
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Pers
romotes negligence and makes it harder to ensure people are running the
latest security updates.
Giving everyone until the end of 2017 to update their servers is more than
sufficient.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>
don't care about you anymore".
Yes, given the lack of a sensible alternative, I think we need to do this.
And then the community needs to, collectively, invest serious effort in
finding a remotely exploitable vulnerability in any/all EOL'd versions of
PHP to give a strong incentive to stop running 5.2.x and 5.3.x in 2016.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>
>
Where did this 8 months figure come from?
PHP 7.0.0 available -> 2015-12-03
Today -> 2015-12-06
PHP 5.6.x EOL'd -> 2017-08
That's more than 8 months.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>
r reviewing it for any glaring
> omissions.
>
>
>
> Let the discussion continue…
>
>
>
> Zeev
>
I still have no idea how to vote, but I'd prefer option 2 the most, option
3 as a backup, and strongly advise against option 1.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>
ion/other/build_phar.php on line 37
If there's a reason this shouldn't allowed, could the documentation please
be updated to reflect this decision?
If this is a bug, it's breaking our ability to publish signed a .phar for
defuse/php-encryption
(And if I somehow overlooked so
inked CoC draft is one of the most fair ones I've read.
While I don't see any harm in requiring a larger majority (since I
can't foresee any rational argument against this cropping up), if
there are toxic people that feel threatened by these terms, they might
try to rally other
___
> |. \ \-3
> |_J_/ PHP |
> || | __ |
> || |m| |m|
>
> I LOVE PHP
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
Hi all,
Even if there are no incidencts where a CoC i
1 - 100 of 192 matches
Mail list logo
