Re: [PHP-DEV] [RFC DISCUSSION] typeof

[Stanislav Malyshev]

Hi!

> You can choose your point of view - I choose the point of view where we
> replace a broken function with a function that does what developers
> would actually *expect*.

Show me developer that expects core engine functions to go away and be
replaced with functions with almost the same, but slightly different
output - and I show you a developer that has way too much free time on
their hands. Most developers don't have time for such things. Yes, if we
designed this function from scratch, knowing all we know now, we'd take
different decisions. But we don't have this luxury, we are where we are
now, and it's not from scratch.
-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Libsodium - Discussion

[Stanislav Malyshev]

Hi!

> This would entail a BC break against all software currently written
> using libsodium.
> Are you certain that deeper namespacing would be worth that trade-off?

This is certainly a concern. But this is solvable - we can have aliases,
for example, that would be compiled only in PECL build.

> Libsodium offers few primitives. For AEAD, you have:
> 
> - ChaCha20-Poly1305
> - AES-256-GCM (but only with modern hardware)
> - ChaCha20-Poly1305 (IETF version with a bigger nonce)
> 
> These are distinct functions in the C API to discourage "Hey, I'll add
> another algorithm and users can access it by changing the string
> that's passed".

I think somehow separating primitives from recommended API would be
useful. Or maybe it's just documenting...

> When all is said and done, crypto_aead_encrypt() and
> crypto_aead_decrypt() will be the CAESAR winner.
> https://competitions.cr.yp.to/caesar.html

That seems to be 1.5 years from now, so what the user would do now?

> To be honest, most of these aren't necessary in PHP anymore. They were
> mostly useful in PHP 5.x before we had random_bytes() and
> random_int().

OK, then I assume we can mark those as something like "use
random_bytes/random_int in PHP 7.x"?

> Alternatively, if we can make bin2hex() and hex2bin() always
> constant-time in PHP

I think you mean time not dependent on argument content, but only on
length?

> These are the facts:
> 
> 1. Index lookups based on the contents cryptographic secrets is a
> recipe for microarchitecture side-channels (e.g. FLUSH+RELOAD).

That's the theory, and even that part of theory only applies to bin2hex,
as far as I can see. It also assumes lookups within 16 bytes are
distinguishable - and not just distinguishable but distinguishable
enough so that you can see them through layers of overhead of PHP, PHP
code, server infrastructure, etc., which sounds doubtful for me on a
modern architecture.
For hex2bin, even that doubtful theory seems to be not applicable.

> 2. The current implementation of all RFC 4648 encoding functions that
> PHP has (which, strangely, doesn't include base32) violates rule 1.
> 
> https://cryptocoding.net/index.php/Coding_rules#Avoid_table_look-ups_indexed_by_secret_data

That again is theory, as above. It says it depends on cache hit/miss.
Line size in most common Intel processor is 64 bytes, on ARM IIRC it's
32 bytes, while hexconvtab is 16 bytes long. So I'm not sure how would
you get any cache hit/miss sensitivity here. Am I missing something?

> Right, it has to be used with care. But the existence of a
> well-written cross-platform memory-zeroing function is almost reason
> enough to vote in favor of libsodium.

The problem is that no amount of care would actually help in a common
scenario. Due to PHP's copy-on-write semantics, it just wouldn't do what
you think it would do, in most cases. The only way it would work if you
ensure no reference to this variable ever exists throughout the code
except for one passed to memzero. And this is usually not easy to
achieve. So I think you overestimate the usefulness of it,
unfortunately. It _might_ work for temporary keys that are created and
destroyed in the same function without storing them anywhere, but in
most scenarios these keys are derived from stored keys anyway.

> That's a good question:
> http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html

"Insufficient" is kind of misleading there - it's not merely
"insufficient", it is not adding practically anything, the level of
compromise is the same before and after.

> It's used for incrementing a nonce for, e.g. CTR mode. In little-endian.

You mean treat the whole string as little-endian representation of the
arbitrary-sized integer and increment that integer and return the
result? What if the size of the resulting integer is larger - does it
reallocate or overflow? Should be documented.

> See http://nacl.cr.yp.to

Are we bound by naming decisions of this project? Maybe, then we need
some good explanation of what they actually mean.

>> - crypto_box_keypair_from_secretkey_and_publickey seems to use secret
>> and public key from different people, so the result is not what is
>> usually called a key pair (set of public+private keys belonging to one
>> user) - in fact, I don't know what the result is. Could you explain?
> 
> A keypair is used in some APIs (crypto_box_seal_open comes to mind).
> All that function does is concatenate the two.
> 
> It has nothing to do with key exchange.

That is rather unfortunate reuse of the terminology. Can we use some
other term in PHP API or docs? Also, why concatenating two keys is
useful - are they then used as a single key? Or they are de-concatenated
internally? If the latter, it would be better to pass them as separate
parameters.

> Libsodium is an opinionated cryptography library that doesn't give you
> a lot of levers to pull -- only secure defaults you can't change,
> consisting of carefully-selected cryptography 

Re: [PHP-DEV] can't reflection on DateTime properties?

[Stanislav Malyshev]

Hi!

> It's also impossible to write a PHP class with "internal state" - state
> that I can't find at run-time with reflection. That's what makes the
> language reflective. Internal state in this sense is something foreign
> to PHP as well, the only exception being things like resources, but
> those aren't really types in the first place, but handles to file-system
> objects, representing state outside of the program.

It's not foreign to PHP, it's unavailable to userspace, yes. Internal
functions have access to more capabilities than userspace ones, it has
always been the case in PHP.

> We're talking about a simple object representing an integer timestamp
> and a timezone ID. There is no logical reason those should be hidden -
> it's just an implementation detail showing up as an artifact.

There is a reason, or rather reasons, one of them is that internal
representation of the data and user-visible one are different. What is
inside the object is not what you see on the outside.

> You're describing implementation details - these are features of C, not
> features of the PHP language, they happen to leak into the into the PHP
> language where they present themselves as inconsistencies.

You can call it whatever name you like, I'm just explaining how it
actually works :) Calling everything you don't understand
"inconsistencies" seems to be new fashion, but the fact is internal API
has more capabilities than user-space API in PHP. It is a deliberate and
very old decision stemming from the fact that it is very hard -
impossible, really - to give user-space access to engine features safely
to PHP code. OTOH, some interesting things only possible if you have
access to these features.

> The fact is that DateTime does not behave like a PHP class in terms of
> reflection.

It behaves like internal PHP class. You can't really expose state of
internal classes via reflection, since in general case this state does
not have proper representation in PHP terms besides that very class itself.
-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Libsodium - Discussion

[Stanislav Malyshev]

Hi!

> My position on the low level nature of libsodium's APIs is as follows: ​
> That sounds like a call to action for
> https://wiki.php.net/rfc/php71-crypto rather than a point of concern for
> adopting libsodium.​

I think there's a bit of misunderstanding here. The low-level nature of
the API is not a problem per se - it is a problem that it is both very
high level (such as giving functions names like "box" and "securebox"
which hardly allow to understand what's going on) and very low level
(like functions spelling out specific algorithm used - I can't even
remember or type their name :). Even that might be not a problem if
there was a clear segregation between them - i.e. there would be low
level API space, which is "don't try this at home" part, and higher
level API space which is "newbies welcome" part.

So maybe it is just namespacing/docs problem. But right now the
situation is like this: I am not a crypto expert, but I have dealt with
crypto for years, I have taken multiple courses on both theoretical and
practical cryptography, if I'm definitely not Ph.D. I can say I am at
least B.Sc. and somewhere in the middle of M.Sc. curriculum :) I still
am not completely sure how the whole thing works.

I understand enough to say the overall goal is admirable and the
infrastructure for it in there, but it seems to need some finish. Some
better namespacing, more friendly/consistent names, more friendly
arguments/defaults, this sort of thing.

> ​Can you count the foot-bullets in that snippet that you'd need to be a
> cryptography engineer to successfully avoid?

That would be a nice exercise :)

> Demo: https://3v4l.org/nYVPf
> 
> Here's a congruent implementation in libsodium:​

I notice however the recipes in the doc are a bit more verbose...

> ​ /**
>  * Libsodium
>  */
> 
> ## ENCRYPTION ##
> 
> $message = 'Prime Numbers Rock!';
> $bob_public_key = "... populate here ...";

Here's one of the unclear parts - where this key comes from? Do we even
have key infrastructure covered? Do we plan to?

> paragonie/halite-- I wholeheartedly endorse that discussion. But I don't
> think we should try to solve that problem with this particular RFC.

That is fine, but then we need a more clear scope definition - what are
the goal we try to achieve here? If we add it, what would we tell the
users we have and why it is awesome?

> In closing, I don't disagree that a simple crypto API is a good goal to
> have. I just think the ideal you're discussing is:
> 
> A. Out of scope, and
> B. Kind of belittling to how much of an improvement libsodium is to what
> we already have.

I don't think belittling libsodium was ever the intent. It is certainly
admirable work towards an important goal. The question is just is it
already ready for PHP core or it needs a little more work.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC DISCUSSION] typeof

[Stanislav Malyshev]

Hi!

> You can choose your point of view - I choose the point of view where we
> replace a broken function with a function that does what developers
> would actually *expect*.

It's not just a point of view. If it is implemented, it will have
consequences for millions of people using PHP. Adding them extra work
and having them to deal with all the consequences that follow from that
decision. With this ecosystem, each change has a cost. It's not just "I
think this way, it's my opinion". That is true for a personal project.
PHP is not a personal project, so proposing change to it is not a matter
of personal opinion - it is much broader. That is why I am and will
continue to argue against changes that have minimal benefit - like this
one - because they are not worth the cost of change imposed on the
ecosystem. There's no such thing as free change, so it should be worth it.

> You know what, all this rhetoric in favor of inconsistency, against a

It's not in favor of inconsistency. It is in favor of not creating a
mess of having two basic functions doing almost, but not quite the same.
The cost of having imperfect, but widely used function is much less than
the cost of switching to another function, learning to distinguish them
in the code, having transition period with two functions and then trying
to eliminate old function from all code that had absolutely no problem
with it. And the benefit is mostly vague "consistency". I mean,
consistency is important design consideration. But in no way "it makes
me sad to see people complain on Reddit about PHP being inconsistent"
is worth more than "people having to change tons of code everywhere to
accommodate change made so that people won't complain on Reddit".

> solution that has already been implemented?

That fact that is has been implemented does not mean it should be part
of PHP core. You can implement a lot of things, being implementable is a
necessary condition, but in no way sufficient. Yes, you take the risk by
implementing feature that is not accepted. But it's not an argument for
acceptance.
-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC DISCUSSION] typeof

[Stanislav Malyshev]

Hi!

> You are completely ignoring the fact that the deprecation and removal of
> gettype() is actually part of my proposal. Anyone who continues to use
> gettype() should be informed that this is not the idiomatic way of
> performing this action and to use the new function instead.

That makes it much worse, not better. Having two functions is bad.
Having to pass through heaps of old of code, change it, re-test it,
re-release it, re-deploy it, all because a basic engine function is
being removed - and not because it didn't work for you, but because
somebody didn't like NULL being in uppercase - is much, much worse than
just having the annoyance of two similar functions. Having two functions
would be bad, but tolerable - adding this huge disruption for no reason
but slightly changing the output is completely unacceptable.

> It might be a /slight inconsistency/ but it is at the same time a very
> shameful and sad one. Our language is not able to tell us the type of a
> variable!

I don't know which language you are talking about, but it's certainly
not PHP.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC DISCUSSION] typeof

[Marco Pivetta]

Hey Richard,

On 4 June 2016 at 18:41, Fleshgrinder  wrote:

> On 6/4/2016 6:17 PM, Marco Pivetta wrote:
> > It would be beneficial to not reduce this to stringly-typed programmer
> > (again), as Dan mentioned.
> >
> > Returning something like a ReflectionType instance (which then implements
> > __toString) would be much simpler, efficient and easy to use.
> >
> > Marco Pivetta
> >
>
> Hey Marco,
>
> not sure if I like that approach for a procedural function. If we would
> want that than it would be better to implement it as a named constructor
> of the actual class.
>
>   class ReflectionType {
>
> public static function from(mixed $var): ReflectionType;
>
>   }
>
> But anyways, it would result in changing the purpose of that class:
>

Good point, probably not something you'd want to happen to pre-existing
code.


> > The ReflectionType class reports information about a function's
> > return type.
>
> I'd argue that we would need a completely new reflection class to handle
> this use case, e.g. ReflectionVariable. However, I cannot see that this
> is actually required while looking at the usage patterns of the existing
> gettype() function. The goal here is to continue supporting the existing
> mode of operation and its usage in userland while updating it to reflect
> the current state of the type system. Additionally, pretty much nobody
> uses it to determine the type of a variable but merely to include the
> resulting string in debug/error messages.
>
> The reflection class approach would mean that even more reflection code
> ends up in production code, another thing I consider questionable.
>

I may have misunderstood the feature at first. By thinking about other
languages with typeof support, I assumed this RFC was about a
machine-friendly representation of a variable.
I'd be "okay" with this if it was documented as "human friendly string
representation of a variable's content", or something similar. It should be
made 100% crystal clear that it is not for machine-consumption though.
Returning a string will cause developers to rely on it for other things
(besides meaningful exception messages), and that should be discouraged
behavior.

I also back Sara's concern, which is that a function like this one can be
implemented, tested, improved and upgraded in userland, without the need
for it to exist in core.
I'd rather do a `composer require some-debug-utils-orga/type-of` than
relying on another core function, which (and this will happen anyway), if
bugged, cannot get fixes without a complete php installation upgrade.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] [RFC] Libsodium - Discussion

[Jakub Zelenka]

On Sun, Jun 5, 2016 at 9:35 AM, Scott Arciszewski 
wrote:

> 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 conflate the two. (Even worse: I wouldn't want the mere
> >> thought of an abstract high-level API to block libsodium from getting
> >> accepted.)
> >>
> >> Instead of /completely redesigning/ the libsodium API, what are some
> >> changes that need to be made to alleviate the majority of concerns
> >> ("it's not the pluggable crypto API" notwithstanding)?
> >>
> >> Two things to keep in mind:
> >>
> >> 1. If it breaks existing code that uses libsodium-php in a nontrivial
> >> way, I'm going to resist the change unless it can be proven necessary
> >> for the sake of everyone's sanity.
> >> 2. If it greatly deviates from the experience of using libsodium in
> >> other programming languages (e.g. renaming crypto_box), you no longer
> >> have libsodium and thus I will resist it.
> >>
> >> Getting rid of redundant features (by improving existing ones, not
> >> just cutting them!) is fine. Dropping scrypt, etc. is fine.
> >>
> >
> > Keeping sodium as an extension solves all your problems. You can keep
> > evolving it in any way you like without having to argue with others. No
> > breaking changes, nothing. It can even be used after another API is
> > introduced in core.
>
> All my problems? How do I get non-root users to install it?
>

I don't really get this point. All main distros have separate packages for
the core extensions as well as for PECL extensions. You still need a root
access to install the extension and it doesn't matter if it's a core ext or
PECL ext. There are lots of extensions that do really well outside the core
(e.g. mongo). So why do we really need it in the core?

Personally I find libsodiam a nice extension that provides some cool stuff.
However I don't see a big benefit of adding that to the core. We already
struggle to maintain the current extensions and even if you said that you
would maintain it, we should also take into account the fact that it can
change and we might end up with another unmaintained ext.

Cheers

Jakub

Re: [PHP-DEV] [RFC] [DISCUSSION] More precise float value

[Jakub Zelenka]

On Mon, May 30, 2016 at 8:01 PM, Jakub Zelenka  wrote:

> On Mon, May 30, 2016 at 7:28 PM, Nikita Popov 
> wrote:
>
>> On Mon, May 30, 2016 at 6:34 PM, Jakub Zelenka  wrote:
>>
>>> On Fri, Sep 4, 2015 at 1:41 AM, Yasuo Ohgaki  wrote:
>>>
>>> > Hi all,
>>> >
>>> > IEEE 754 double cannot express exact float values. That said,
>>> > float values expressed by json/serialize/var_export/echo/print
>>> > are not precise enough in many cases.
>>> >
>>> > Issues:
>>> >  - json_encode() uses EG(precision)=14 that truncates float values.
>>> > echo()/print()
>>> >does this as well.
>>> >  - large EG(precision)/PG(serialize_precision) prints meaningless
>>> values.
>>> >
>>> > This RFC proposes zend_dtoa()'s 0 mode support which rounds float value
>>> > to nearest value.
>>> >
>>> > https://wiki.php.net/rfc/precise_float_value
>>> > https://github.com/php/php-src/pull/1455
>>> >
>>> > This change is simple enough for PHP 7.0. IMO.
>>> > Comments/suggestions are appreciated!
>>> >
>>> >
>>> Hi,
>>>
>>> After asking Yasuo, I'm putting forward this RFC to have more precise
>>> float
>>> to string decoding at least in PHP 7.1. I cleaned the RFC up a little bit
>>> and it's targeting just 7.1.
>>>
>>> It has been some time since this was announced so I will keep it open
>>> for a
>>> week or two and then plan to start vote.
>>>
>>
>> Thanks for taking over this proposal!
>>
>> I've already mentioned this on the PR when this was originally proposed,
>> but bringing it up here as well:
>>
>> This proposal adds a new json.precision setting. Why? I've been told that
>> this is more flexible, which is fair enough, but imho we should have very
>> strong reasons for introducing new ini settings. Reasons that go beyond "it
>> might be useful to someone ... maybe?" So what's the particular use-case
>> here? Where is it necessary to export inaccurate floating point numbers in
>> JSON? And should such a use-case indeed exist, why is this a global setting
>> rather than an option of json_encode? Furthermore, note that even without
>> this new ini option, you always have the option of temporarily changing
>> serialize_precision for a json_encode call, if you *really* need it.
>>
>> Please also take a look at this comment on the implementation:
>> https://github.com/php/php-src/pull/1455#discussion_r53933480
>>
>>
> To be honest I have been thinking again about it before posting it. I
> thought that it might be good to have at least a voting option or keep it
> there for discussion but I don't really mind to drop it and just use just
> serialize_precision by default. I know that it was me who suggested
> json.precision initialy but it wasn't probably the best idea and it might
> be a bit confusing for users. If no one thinks that it's useful and we
> should have a vote about it, I will remove it in the next couple of days.
>
>
I have updated the RFC and dropped the json.precision part. Instead of
that, there will be a voting option only whether to use serialize_precision
for json_encode.

If there are no other issues, I would like to open voting sometimes next
week.

Cheers

Jakub

Re: [PHP-DEV] [RFC DISCUSSION] typeof

[Fleshgrinder]

On 6/5/2016 3:21 PM, Zeev Suraski wrote:
> We're weighing a certain level of inconsistency that exists with
> gettype(), with a different kind of inconsistency - having typeof()
> and gettype() both be members of the language, and behave subtly
> inconsistently with each other.  So this is not consistency vs.
> non-consistency, we're choosing between two non-ideal options.
> 
> IMHO, we're better off sticking with the devil everyone knows;  The
> inconsistency is there but it's not a very strong one with few
> practical issues.  IMHO, we're better off having this compared to
> having two similar-but-different options.  People for whom gettype()
> is inadequate can obtain typeof() (or whatever it will be called)
> using Composer.  For people for whom this is a non-issue (vast
> majority I would believe), don't have to be confused by two
> similar-but-different options.
> 

You are completely ignoring the fact that the deprecation and removal of
gettype() is actually part of my proposal. Anyone who continues to use
gettype() should be informed that this is not the idiomatic way of
performing this action and to use the new function instead.

It might be a /slight inconsistency/ but it is at the same time a very
shameful and sad one. Our language is not able to tell us the type of a
variable!

On 6/5/2016 3:21 PM, Zeev Suraski wrote:
> As a side note, the fact we happen to have an implementation for this
> should play no role in whether we accept a proposal like this or not;
> This holds true for most RFCs - unless the implementation manages to
> achieve some remarkably complex feat, and even then - it should stand
> at its own merit.
> 

That is true, yes.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Libsodium - Discussion

[Tom Worster]

On 6/5/16 4:31 AM, Scott Arciszewski wrote:

> - memzero, memcmp, hex2bin
>
> I am not totally convinced that memzero and maybe memcmp names are
> good nor they should be there. Both would be very useful as operator
> on variables. Given the simplicity of the implementations, it could be
> very useful in many other areas in case this ext is not installed

>

IMO: memzero is fine; memcmp isn't that great.


memzero() stands out as unusual and interesting because PHP scripts 
don't usually get to manipulate memory, only variables. From the "Using" 
guide


void \Sodium\memzero( $secret);

it looks like it's for zeroing strings.

What arg types does memzero() work with?

Does it check argument type?

Is it safe to use with opcache? Interned strings is an interesting case 
but there might be others.


Tom


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [RFC DISCUSSION] typeof

[Zeev Suraski]

> -Original Message-
> From: Rasmus Schultz [mailto:ras...@mindplay.dk]
> Sent: Sunday, June 05, 2016 2:51 PM
> To: Stanislav Malyshev 
> Cc: Sara Golemon ; PHP internals 
> Subject: Re: [PHP-DEV] [RFC DISCUSSION] typeof
> 
> > So let's add more of it by having multiple functions that do exactly
> > the same
> thing but name null and float differently.
> 
> It's a point of view, that's all.
> 
> You can choose your point of view - I choose the point of view where we
> replace a broken function with a function that does what developers would
> actually *expect*.
> 
> You know what, all this rhetoric in favor of inconsistency, against a solution
> that has already been implemented?

We're weighing a certain level of inconsistency that exists with gettype(), 
with a different kind of inconsistency - having typeof() and gettype() both be 
members of the language, and behave subtly inconsistently with each other.  So 
this is not consistency vs. non-consistency, we're choosing between two 
non-ideal options.

IMHO, we're better off sticking with the devil everyone knows;  The 
inconsistency is there but it's not a very strong one with few practical 
issues.  IMHO, we're better off having this compared to having two 
similar-but-different options.  People for whom gettype() is inadequate can 
obtain typeof() (or whatever it will be called) using Composer.  For people for 
whom this is a non-issue (vast majority I would believe), don't have to be 
confused by two similar-but-different options.

As a side note, the fact we happen to have an implementation for this should 
play no role in whether we accept a proposal like this or not;  This holds true 
for most RFCs - unless the implementation manages to achieve some remarkably 
complex feat, and even then - it should stand at its own merit.

Zeev

Re: [PHP-DEV] [RFC] Libsodium - Discussion

[Björn Larsson]

Hi,
Den 2016-06-01 kl. 09:49, skrev Scott Arciszewski:

Hi PHP Internals Team,

Let's begin discussing the prospect of adding libsodium as a core extension
in PHP 7.1. I've updated the RFC to explain why this would be a good idea
and the benefits it offers.

https://wiki.php.net/rfc/libsodium

If the subsequent discussion goes smoothly, I would 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 


Given the lively discussion I suggest that the RFC has an "Discussion Point"
subject where the "Current postion" is clarified for important topics, 
like in

https://wiki.php.net/rfc/scalar_type_hints_v5 RFC. I think it would help in
moving things forward.

I also wonder what is the minimum amount of changes needed for making
libsodium fly and what is unrealistic (needs to be handled outside 
libsodium)

even if we talk about 7.x perspective?

Regards //Björn Larsson

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC DISCUSSION] typeof

[Lester Caine]

On 05/06/16 11:56, Fleshgrinder wrote:
> Quick sketch of a ReflectionVariable class:
> 
> https://gist.github.com/Fleshgrinder/40d256a4bf44a0e2579b41d6e92e976e
> 
> What do you think?
> 
> PS: This would definitely be a different RFC!

The one thing that sticks out from this is 'why do I need all this?'

This may be because I don't understand just what happens under the hood
when you create a $var and in my naive way I have ALWAYS assumed that a
variable was a set of data elements with a pointer which 'a single
compiled and optimized set of code' operated each of to provide either
the raw value, or transformed version of that data essentially in a
different type. but if the value was provided as a string, that string
was maintained.

I've never viewed a $var as a single data element, so 'typing' it as int
does not mean that it only exists as a fixed length register - probably
64bit - with no other versions stored. If it was provided as a hex
string then I would anticipate that both the hex string type will exist
in parallel with the binary value. At least a $var has a name field,
flags for access restrictions, and yes null fields where they have not
be defined.

I would expect ALL of the extras listed in 'ReflectionVariable' simply
to be core code handling any $var value be that as an element of an
enclosing array, a property in a class, or a parameter in a function
call. This is why I don't understand the 'strict' mode at all. Or rather
I do in relation to a compiled language that does not have the
flexibility to pass data from one domain to another and where the typing
is directed to specific hardware restrictions which then make optimizing
code appropriate, but PHP specifically avoids that problem. It was the
major plus when I started using it! I understand that type checking has
a place, but NOT as it is currently structured, which is why I think all
the current round robins on typing/null/strict are simply going to carry
on in that manor.

When I create 100 person objects how many copies of the class and
related code are created? Is each property then it's own full copy of
the var code, which is why you want to 'optimise' for each different
type, rather than improving the caching of the objects data to only run
a type conversion when it is needed.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

AW: [PHP-DEV] Re: [RFC] [PRE-VOTE] Union types

[Robert Stoll]

> -Ursprüngliche Nachricht-
> Von: Ryan Pallas [mailto:derokor...@gmail.com]
> Gesendet: Sonntag, 5. Juni 2016 14:22
> An: Robert Stoll
> Cc: Bob Weinand; Andrea Faulds; internals@lists.php.net
> Betreff: Re: [PHP-DEV] Re: [RFC] [PRE-VOTE] Union types
> 
> 
> 
> On Sun, Jun 5, 2016 at 6:09 AM, Robert Stoll  wrote:
> 
> 
>   Hi Andrea, Bob
> 
>   > -Ursprüngliche Nachricht-
>   > Von: Bob Weinand [mailto:bobw...@hotmail.com]
>   > Gesendet: Sonntag, 5. Juni 2016 01:00
>   > An: Andrea Faulds
>   > Cc: internals@lists.php.net
>   > Betreff: Re: [PHP-DEV] Re: [RFC] [PRE-VOTE] Union types
> 
>   >
>   >
>   > > Am 05.06.2016 um 00:55 schrieb Andrea Faulds :
>   > >
>   > > Hi again,
>   > >
>   > > In an attempt to be constructive, I have implemented an alternative 
> approach to weak scalar type selection
> here:
>   > >
>   > > 
> https://github.com/krakjoe/php-src/compare/multi-types...TazeTSchnitzel:multi-types-roulette
>   > >
>   > > Where there is no exact scalar type match, this patch uses an 
> algorithm originally suggested by Nikita, wherein
> we
>   use
>   > rand() to pick which type to cast to.
>   > >
>   > > This is much simpler than having a type precedence matrix, and thus 
> is easier to remember and reason about.
> The
>   choice
>   > of selection function means that no particular use-case is 
> privileged. Given PHP's scalar types are roughly
> equivalent
>   (after
>   > all, PHP juggles them freely), this apparently unorthodox selection 
> process should nonetheless produce sensible
>   results in
>   > most cases.
>   > >
>   > > Please tell me your thoughts!
>   > >
>   > > --
>   > > Andrea Faulds
>   > > https://ajf.me/ 
>   > This is the holy grail I was hunting for so long!
>   >
>   > All my computational problems can be solved by a simple rand()!
>   >
>   > In case nobody objects I'm going to merge that straight ahead into 
> php-src 7.0 (no need for master-only, after all
>   it's no real
>   > BC break!).
>   >
>   > Thanks a very much!!!
>   >
>   > Bob
> 
> 
>   Not sure if this is a clever idea. I haven't read all emails so bear 
> with me if this is more than clear. What happens
>   with the following?
> 
>   function foo(int | string $a) {
> if ($a == "") {
>   //a
> } else {
>   //b
> }
>   }
> 
>   foo(false);
> 
>   What branch is taken? Is it taken randomly?
> 
> 
> 
> In this case, A will always be taken, because of the loose comparison (==). 
> Basically:
> 
> var_dump("" == ""); // bool(true)
> var_dump(0 == ""); // bool(true)
> var_dump(false == ""); // bool(true)
> 

My fault, so what about 

if ($a === "") {

}


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] [PRE-VOTE] Union types

[Ryan Pallas]

On Sun, Jun 5, 2016 at 6:09 AM, Robert Stoll  wrote:

> Hi Andrea, Bob
>
> > -Ursprüngliche Nachricht-
> > Von: Bob Weinand [mailto:bobw...@hotmail.com]
> > Gesendet: Sonntag, 5. Juni 2016 01:00
> > An: Andrea Faulds
> > Cc: internals@lists.php.net
> > Betreff: Re: [PHP-DEV] Re: [RFC] [PRE-VOTE] Union types
> >
> >
> > > Am 05.06.2016 um 00:55 schrieb Andrea Faulds :
> > >
> > > Hi again,
> > >
> > > In an attempt to be constructive, I have implemented an alternative
> approach to weak scalar type selection here:
> > >
> > >
> https://github.com/krakjoe/php-src/compare/multi-types...TazeTSchnitzel:multi-types-roulette
> > >
> > > Where there is no exact scalar type match, this patch uses an
> algorithm originally suggested by Nikita, wherein we
> use
> > rand() to pick which type to cast to.
> > >
> > > This is much simpler than having a type precedence matrix, and thus is
> easier to remember and reason about. The
> choice
> > of selection function means that no particular use-case is privileged.
> Given PHP's scalar types are roughly equivalent
> (after
> > all, PHP juggles them freely), this apparently unorthodox selection
> process should nonetheless produce sensible
> results in
> > most cases.
> > >
> > > Please tell me your thoughts!
> > >
> > > --
> > > Andrea Faulds
> > > https://ajf.me/ 
> > This is the holy grail I was hunting for so long!
> >
> > All my computational problems can be solved by a simple rand()!
> >
> > In case nobody objects I'm going to merge that straight ahead into
> php-src 7.0 (no need for master-only, after all
> it's no real
> > BC break!).
> >
> > Thanks a very much!!!
> >
> > Bob
>
> Not sure if this is a clever idea. I haven't read all emails so bear with
> me if this is more than clear. What happens
> with the following?
>
> function foo(int | string $a) {
>   if ($a == "") {
> //a
>   } else {
> //b
>   }
> }
>
> foo(false);
>
> What branch is taken? Is it taken randomly?
>

In this case, A will always be taken, because of the loose comparison (==).
Basically:

var_dump("" == ""); // bool(true)
var_dump(0 == ""); // bool(true)
var_dump(false == ""); // bool(true)

>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

AW: [PHP-DEV] Re: [RFC] [PRE-VOTE] Union types

[Robert Stoll]

Hi Andrea, Bob

> -Ursprüngliche Nachricht-
> Von: Bob Weinand [mailto:bobw...@hotmail.com]
> Gesendet: Sonntag, 5. Juni 2016 01:00
> An: Andrea Faulds
> Cc: internals@lists.php.net
> Betreff: Re: [PHP-DEV] Re: [RFC] [PRE-VOTE] Union types
> 
> 
> > Am 05.06.2016 um 00:55 schrieb Andrea Faulds :
> >
> > Hi again,
> >
> > In an attempt to be constructive, I have implemented an alternative 
> > approach to weak scalar type selection here:
> >
> > https://github.com/krakjoe/php-src/compare/multi-types...TazeTSchnitzel:multi-types-roulette
> >
> > Where there is no exact scalar type match, this patch uses an algorithm 
> > originally suggested by Nikita, wherein we
use
> rand() to pick which type to cast to.
> >
> > This is much simpler than having a type precedence matrix, and thus is 
> > easier to remember and reason about. The
choice
> of selection function means that no particular use-case is privileged. Given 
> PHP's scalar types are roughly equivalent
(after
> all, PHP juggles them freely), this apparently unorthodox selection process 
> should nonetheless produce sensible
results in
> most cases.
> >
> > Please tell me your thoughts!
> >
> > --
> > Andrea Faulds
> > https://ajf.me/ 
> This is the holy grail I was hunting for so long!
> 
> All my computational problems can be solved by a simple rand()!
> 
> In case nobody objects I'm going to merge that straight ahead into php-src 
> 7.0 (no need for master-only, after all
it's no real
> BC break!).
> 
> Thanks a very much!!!
> 
> Bob

Not sure if this is a clever idea. I haven't read all emails so bear with me if 
this is more than clear. What happens
with the following?

function foo(int | string $a) {
  if ($a == "") {
//a 
  } else {
//b
  }
}

foo(false); 

What branch is taken? Is it taken randomly?



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC DISCUSSION] typeof

[Rasmus Schultz]

> So let's add more of it by having multiple functions that do exactly the same
thing but name null and float differently.

It's a point of view, that's all.

You can choose your point of view - I choose the point of view where we
replace a broken function with a function that does what developers would
actually *expect*.

You know what, all this rhetoric in favor of inconsistency, against a
solution that has already been implemented?

I don't know how to participate in this.


On Sun, Jun 5, 2016 at 12:36 AM, Stanislav Malyshev 
wrote:

> Hi!
>
> > The old function is actively causing confusion - the reported type-names
> > aren't even inconsistent with scalar type-hints, and then you have to go
> > and read the manual with some explanation about historical reasons why
> > the function doesn't work like you'd expect.
>
> Why it should match scalar types? You can't use output of this function
> in a scalar type in any way.
>
> > PHP is infamous for these surprise moments.
>
> So let's add more of it by having multiple functions that do exactly the
> same thing but name null and float differently.
>
> > I think that gettype() should be deprecated in favor of a new function
> > that actually makes sense.
>
> If you think people would want to edit gigabytes of existing code
> because you want NULL to be lowercase, you are very seriously mistaken
> about the order of priority of an average PHP developer. I am sure
> 99.% of people care about all this pedantry infinitely less than
> they care about their code keeping working and their development not be
> impeded by things like having to read the manual each time to choose
> which two of almost identical functions they need now and which of them
> has null in which case.
>
> > I think that deprecating and fixing things is long-term less confusing
> > than documenting your way around legacy functions that produce
> > surprising and confusing results.
>
> I think constantly disrupting the language environment by pedantic
> tweaks that add BC and cognitive load but do not actually enable
> anything new, just move things around - is not only confusing, but
> harmful for the whole ecosystem.
>
> And if "NULL" really confuses you to the point you have no idea what it
> means - well, really, I don't know what to say.
>
> --
> Stas Malyshev
> smalys...@gmail.com
>

Re: [PHP-DEV] [RFC DISCUSSION] typeof

[Fleshgrinder]

Quick sketch of a ReflectionVariable class:

https://gist.github.com/Fleshgrinder/40d256a4bf44a0e2579b41d6e92e976e

What do you think?

PS: This would definitely be a different RFC!

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Libsodium - Discussion

[Niklas Keller]

Scott Arciszewski  schrieb am So., 5. Juni 2016 10:13:

> On Sat, Jun 4, 2016 at 6:15 PM, Stanislav Malyshev 
> wrote:
> >
> > Hi!
> >
> > > Let's begin discussing the prospect of adding libsodium as a core
> extension
> > > in PHP 7.1. I've updated the RFC to explain why this would be a good
> idea
> > > and the benefits it offers.
> > >
> > > https://wiki.php.net/rfc/libsodium
> > >
> > > If the subsequent discussion goes smoothly, I would like to open
> voting on
> > > June 15.
> >
> > Some notes based on the docs in
> https://paragonie.com/book/pecl-libsodium:
> > TLDR: I think the idea of having something like this in core is very
> > nice, but I think it needs some tweaks in order to be a solution we can
> > recommend as core module.
> >
> > - I would appreciate deeper namespacing. It is rarely that you would use
> > all sub-modules (such as encryption, both symmetric and asymmetric,
> > password hashing, decryption, random, etc.) in the same piece of code.
> > So if I could just "use Sodium\Crypto;" and then use short names it
> > would be much nicer than having to spell out the whole story.
>
> This would entail a BC break against all software currently written
> using libsodium.
> Are you certain that deeper namespacing would be worth that trade-off?
>
> > - Also, I'm not sure why functions like
> > crypto_aead_chacha20poly1305_encrypt() exist. Shouldn't algorythm be a
> > parameter to encryption function and not function name? Putting
> > parameter into function names makes it much harder to be flexible and
> > configurable. Or, if there's only one, then why not just call it
> > encrypt() and state the fixed algorithm in the docs?
>
> Libsodium offers few primitives. For AEAD, you have:
>
> - ChaCha20-Poly1305
> - AES-256-GCM (but only with modern hardware)
> - ChaCha20-Poly1305 (IETF version with a bigger nonce)
>
> These are distinct functions in the C API to discourage "Hey, I'll add
> another algorithm and users can access it by changing the string
> that's passed".
>
> When all is said and done, crypto_aead_encrypt() and
> crypto_aead_decrypt() will be the CAESAR winner.
> https://competitions.cr.yp.to/caesar.html
>
> > - The function names in general are kind of all over the place. I.e., to
> > get a random, you get:
> > - for string: _buf
> > - for ranged (I assume unsigned?) integer: _uniform
> > - for 16-bit unsigned integer: _random16
> > If you can notice a pattern here, I can't. Also, I don't see why you
> > have a function for 16-bit int but not for 8-bit or 32-bit. Additionally
> > weird that _uniform gets int, but has limit different from PHP int.
>
> To be honest, most of these aren't necessary in PHP anymore. They were
> mostly useful in PHP 5.x before we had random_bytes() and
> random_int().
>
> > - Naming/namespacing of constant-time function should make it clear they
> > are there because they are constant time, not just because somebody
> > wanted to reimplement bin2hex. It's also unclear why we need memcmp as
> > separate function from hash_equals().
>
> Alternatively, if we can make bin2hex() and hex2bin() always
> constant-time in PHP, we can eschew exposing these libsodium
> functions. (Just make an alias for BC purposes.) I'd actually prefer
> that.
>

Can't we have the aliases in userland for BC? I don't see a reason to
introduce aliases that are automatically deprecated.

Same for all other functions. If they're namespaced, a wrapper can be
created for BC. And we can have nice names in PHP.

> Also, I'm still not convinced bin2hex in PHP even has a timing problem.
> > I haven't seen anything but vague generic theoretising in this regard.
> > Same with hex2bin (in fact, even more since hex2bin doesn't even have
> > index lookups).
>
> These are the facts:
>
> 1. Index lookups based on the contents cryptographic secrets is a
> recipe for microarchitecture side-channels (e.g. FLUSH+RELOAD).
> 2. The current implementation of all RFC 4648 encoding functions that
> PHP has (which, strangely, doesn't include base32) violates rule 1.
>
>
> https://cryptocoding.net/index.php/Coding_rules#Avoid_table_look-ups_indexed_by_secret_data
>
> See how Halite stores keys for an example of "Yes, this does get used
> for crypto secrets":
>
> https://github.com/paragonie/halite/blob/6c026f7dc6a57ecd6c65e5944057acdefa8c9d67/src/KeyFactory.php#L604-L627
>
> > - What exactly memzero does in PHP? Looks like it accepts argument
> > by-ref, which means if you do something like:
>
> It overwrites every byte in a string with NUL characters.
>
> > function foo($secret_key) {
> > // do stuff with key
> > memzero($secret_key);
> > }
> >
> > and then:
> >
> > $key = get_key(); foo($key);
> >
> > then $key still has the key. So I'm not sure how that all memory wiping
> > is still working in practice. I mean, it may work with random keys that
> > you generate, use once and immediately destroy, but in any other
> > scenario it's just wasting time. Even with 

Re: [PHP-DEV] [RFC] Libsodium - Discussion

[Pierre Joye]

On Sun, Jun 5, 2016 at 2:46 PM, Scott Arciszewski  wrote:
>
> On Sun, Jun 5, 2016 at 2:20 AM, Pierre Joye  wrote:
>>
>>
>> On Jun 5, 2016 5:15 AM, "Stanislav Malyshev"  wrote:
>> >
>>
>> > The stated goal is "You shouldn't need a Ph.D in Applied Cryptography to
>> > build a secure web application." I fully agree with this goal. I however
>> > feel that current implementation, while making admirable progress
>> > towards this goal, still needs some work to actually achieve it.
>>
>> I fully agree with you. As much as I think we need something 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 nature of libsodium's APIs is as follows: That
> 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).
>
>  /**
>  * OpenSSL -- since the Diffie Hellman features in ext/openssl kind
>  * of suck, I'm going to use RSA to encrypt the AES key using the
>  * recipient's public key.
>  */
>
> ## ENCRYPTION ##
>
> $message = 'Prime Numbers Rock!';
> $publicKey = openssl_pkey_get_public('file://path/to/public_key.pem');
>
> $aesKey = random_bytes(32);
> // Basically a poor-man's HKDF by just using HMAC
> $keyE = hash_hmac('sha256', 'Encryption Key', $aesKey, true);
> $keyA = hash_hmac('sha256', 'Authentication Key', $aesKey, true);
>
> $iv = random_bytes(16);
> $ciphertext = openssl_encrypt($message, 'aes-256-ctr', $keyE,
> OPENSSL_RAW_DATA, $iv);
> $mac = hash_hmac('sha256', $iv . $ciphertext, $keyA, true);
>
> $combined = $mac . $iv . $ciphertext;
> $rsaCipher = '';
> openssl_public_encrypt($aesKey, $rsaCipher, $publicKey,
> OPENSSL_PKCS1_OAEP_PADDING);
> $sendMe = $rsaCipher . $combined;
>
> ## DECRYPTION ##
>
> $privateKey = openssl_pkey_get_public('file://path/to/private_key.pem');
> $rsaPart = mb_substr($sendMe, 0, 256, '8bit'); // Assuming 2048-bit RSA
> $aesPart = mb_substr($sendMe, 256, null, '8bit');
> $mac = mb_substr($aesPart, 0, 32, '8bit');
> $iv = mb_substr($aesPart, 32, 16, '8bit');
> $cipher = mb_substr($aesPart, 48, null, '8bit');
>
> openssl_private_decrypt($rsaPart, $aesKey, $privateKey,
> OPENSSL_PKCS1_OAEP_PADDING);
> $keyE = hash_hmac('sha256', 'Encryption Key', $aesKey, true);
> $keyA = hash_hmac('sha256', 'Authentication Key', $aesKey, true);
>
> $calc = hash_hmac('sha256', $iv . $cipher, $keyA, true);
> if (!hash_equals($calc, $mac)) {
> throw new Exception('MAC validation failure');
> }
>
> $decrypted = openssl_decrypt($cipher, 'aes-256-ctr', $keyE,
> OPENSSL_RAW_DATA, $iv);
> var_dump($decrypted); // string(19) "Prime Numbers Rock!"
>
> Can you count the foot-bullets in that snippet that you'd need to be a
> cryptography engineer to successfully avoid?
>
> Demo: https://3v4l.org/nYVPf
>
> Here's a congruent implementation in libsodium:
>
> /**
>  * Libsodium
>  */
>
> ## ENCRYPTION ##
>
> $message = 'Prime Numbers Rock!';
> $bob_public_key = "... populate here ...";
>
> $nonce = random_bytes(24);
> $sendMe = \Sodium\crypto_box_seal($message, $bob_public_key);
>
>## DECRYPTION ##
>
>$bob_kp = "... populate here ...";
> $decrypted = \Sodium\crypto_box_seal_open($sendMe, $bob_kp);
> var_dump($decrypted); // string(19) "Prime Numbers Rock!"
>
> (No demo available, as 3v4l doesn't have ext/sodium installed.)
>
> 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 paragonie/EasyRSA + defuse/php-encryption or paragonie/halite--
> I wholeheartedly endorse that discussion. But I don't think we should try to
> solve that problem with this particular RFC.
>
> In closing, I don't disagree that a simple crypto API is a good goal to
> have. I just think the ideal you're discussing is:
>
> A. Out of scope, and
> B. Kind of belittling to how much of an improvement libsodium is to what we
> already have.
>
> Further reading: http://framework.zend.com/security/advisory/ZF2015-10

Also the questions about the naming, namespaces and other conventions
remain unanswered. That would be a good step forward.

And indeed this API, while still not ideal, is by far better than
openssl for what matters.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] can't reflection on DateTime properties?

[Rasmus Schultz]

> Of course they are possible. See __get/__set

Not the same thing at all - PDOStatement::$queryString is a read-only
property, which cannot be overridden, not even with __get() as you would be
able to for regular __get() in a regular PHP class.

It's also impossible to write a PHP class with "internal state" - state
that I can't find at run-time with reflection. That's what makes the
language reflective. Internal state in this sense is something foreign to
PHP as well, the only exception being things like resources, but those
aren't really types in the first place, but handles to file-system objects,
representing state outside of the program.

We're talking about a simple object representing an integer timestamp and a
timezone ID. There is no logical reason those should be hidden - it's just
an implementation detail showing up as an artifact.

> It does. It's just PHP classes can behave in more ways than you think :)
> And to some of the ways there's no good access from PHP space.

You're describing implementation details - these are features of C, not
features of the PHP language, they happen to leak into the into the PHP
language where they present themselves as inconsistencies.

The fact is that DateTime does not behave like a PHP class in terms of
reflection.

PHP being a reflective language, that's a language inconsistency. What else
would you call it?


On Sun, Jun 5, 2016 at 12:59 AM, Stanislav Malyshev 
wrote:

> Hi!
>
> > I know that things like internal state and read-only properties are
> > possible for classes written in C, but those features aren't possible in
> > PHP code - classes that behave this way are inconsistent with classes
>
> Of course they are possible. See __get/__set. But yes, internal classes
> work a bit differently, which is no wonder since they can use internal
> handlers which are not available to PHP code.
>
> > That is no help at all, when you're implementing a JSON serializer.
>
> Right, DateTime does not implement Serializable. Probably might be a
> good idea to make it do that.
>
> Otherwise - though in general it is not a very good idea to serialize
> objects which didn't declare they are serializeable, especially internal
> ones. But if one feels adventurous the handler to use would be
> get_properties, and converting to array uses this handler, so you could
> do that. It's the same handler serializers use to get properties, unless
> Serializable is implemented or __sleep is defined.
>
> > Because DateTime does not behave like other classes, the only
> > work-around is to explicitly handle DateTime with an
> > if/instanceof-statement and handle that particular class explicitly.
> >
> > There are plenty of work-arounds - the point is that this class doesn't
> > behave consistently with any other PHP class.
>
> It does. It's just PHP classes can behave in more ways than you think :)
> And to some of the ways there's no good access from PHP space.
> --
> Stas Malyshev
> smalys...@gmail.com
>

Re: [PHP-DEV] [RFC] Libsodium - Discussion

[Fleshgrinder]

On 6/5/2016 10:35 AM, Scott Arciszewski wrote:
> All my problems? How do I get non-root users to install it?
> 

How is it possible for them to use it now? You mentioned breaking
changes for existing library users. ;) :P

PHP is not meant to support you extending your user base, no offense!
Our goal is to design an effective and easy to use dynamic high level
language for web development.

On 6/5/2016 10:35 AM, Scott Arciszewski wrote:
> That's the pluggable crypto API RFC, which I probably won't be able to
> propose until 7.2. Feel free to pick it up if you'd rather advocate
> for that.
> 

I already offered you my full support but I doubt that I can do this on
my own. I like crypto and I know a few things but this is a really hard
topic.

Additionally I already said that moving sodium from PECL to core just to
have it there is super bad for many reasons. Let's concentrate on the
nice API, even if that means that it will not land in core before 7.2.
You are effectively introducing more PHP sadness with the proposed API.

PHP sadness reminds me, all the OpenSSL and mcrypt crap should be
deprecated and removed too once we have better replacements. That should
directly be part of the RFC or people will forget and it stays forever.

On 6/5/2016 10:35 AM, Scott Arciszewski wrote:
> Put yourself in the shoes of, say, a Python developer who uses
> libsodium all the time who comes to PHP. If they don't find crypto_box
> and crypto_secretbox, they're going to get confused.
> 

It is not readily available in most other language, there are mostly
libraries for it. Hence, the Python users are facing this problem every day.

https://download.libsodium.org/doc/bindings_for_other_languages/

Everyone who knows crypto know asymmetric and symmetric and they can
find them on Wikipedia, whereas a search for "secret box wikipedia"
leads us to: https://en.wikipedia.org/wiki/Puzzle_box :P

PHP is a higher programming language, we want to make it easy for the
beginner and average user. Professionals find their own ways and
eventually end up here if they are really unsatisfied. ;)

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Libsodium - Discussion

[Scott Arciszewski]

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 conflate the two. (Even worse: I wouldn't want the mere
>> thought of an abstract high-level API to block libsodium from getting
>> accepted.)
>>
>> Instead of /completely redesigning/ the libsodium API, what are some
>> changes that need to be made to alleviate the majority of concerns
>> ("it's not the pluggable crypto API" notwithstanding)?
>>
>> Two things to keep in mind:
>>
>> 1. If it breaks existing code that uses libsodium-php in a nontrivial
>> way, I'm going to resist the change unless it can be proven necessary
>> for the sake of everyone's sanity.
>> 2. If it greatly deviates from the experience of using libsodium in
>> other programming languages (e.g. renaming crypto_box), you no longer
>> have libsodium and thus I will resist it.
>>
>> Getting rid of redundant features (by improving existing ones, not
>> just cutting them!) is fine. Dropping scrypt, etc. is fine.
>>
>
> Keeping sodium as an extension solves all your problems. You can keep
> evolving it in any way you like without having to argue with others. No
> breaking changes, nothing. It can even be used after another API is
> introduced in core.

All my problems? How do I get non-root users to install it?

> We can achieve this by introducing a different API in core that uses
> sodium in the background. This also allows us to exchange it without any
> interruptions in userland in the future.

That's the pluggable crypto API RFC, which I probably won't be able to
propose until 7.2. Feel free to pick it up if you'd rather advocate
for that.

> If existing functions like bin2hex or hex2bin are really not good enough
> than let us patch them. No need to introduce another function that does
> exactly the same. Whether the two are consistent in time or not does not
> change anything for userland. The resulting string is always the same. I
> think that the patch for aforementioned functions would even be possible
> without an RFC.

Okay, that's fine by me.

> The usage of names like secret box and box is simply not known to the
> average user and that makes them really bad. People will have to search
> the manual and dig deep until they find out that it is just about
> asymmetric and symmetric encryption. We already have enough stuff that
> makes no sense to the general public but to some.

Put yourself in the shoes of, say, a Python developer who uses
libsodium all the time who comes to PHP. If they don't find crypto_box
and crypto_secretbox, they're going to get confused.

> --
> Richard "Fleshgrinder" Fussenegger
>

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Libsodium - Discussion

[Fleshgrinder]

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 conflate the two. (Even worse: I wouldn't want the mere
> thought of an abstract high-level API to block libsodium from getting
> accepted.)
> 
> Instead of /completely redesigning/ the libsodium API, what are some
> changes that need to be made to alleviate the majority of concerns
> ("it's not the pluggable crypto API" notwithstanding)?
> 
> Two things to keep in mind:
> 
> 1. If it breaks existing code that uses libsodium-php in a nontrivial
> way, I'm going to resist the change unless it can be proven necessary
> for the sake of everyone's sanity.
> 2. If it greatly deviates from the experience of using libsodium in
> other programming languages (e.g. renaming crypto_box), you no longer
> have libsodium and thus I will resist it.
> 
> Getting rid of redundant features (by improving existing ones, not
> just cutting them!) is fine. Dropping scrypt, etc. is fine.
> 

Keeping sodium as an extension solves all your problems. You can keep
evolving it in any way you like without having to argue with others. No
breaking changes, nothing. It can even be used after another API is
introduced in core.

We can achieve this by introducing a different API in core that uses
sodium in the background. This also allows us to exchange it without any
interruptions in userland in the future.

If existing functions like bin2hex or hex2bin are really not good enough
than let us patch them. No need to introduce another function that does
exactly the same. Whether the two are consistent in time or not does not
change anything for userland. The resulting string is always the same. I
think that the patch for aforementioned functions would even be possible
without an RFC.

The usage of names like secret box and box is simply not known to the
average user and that makes them really bad. People will have to search
the manual and dig deep until they find out that it is just about
asymmetric and symmetric encryption. We already have enough stuff that
makes no sense to the general public but to some.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Libsodium - Discussion

[Scott Arciszewski]

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.1. I've updated the RFC to explain why this would be a good idea
>> and the benefits it offers.
>>
>> https://wiki.php.net/rfc/libsodium
>>
>> If the subsequent discussion goes smoothly, I would like to open voting on
>> June 15.
>>
>> Together, let's make PHP cryptography so safe that it becomes boring.
>
> Good work and very good choice for the backend library.
>
> I am overall in favor of having this extension in the core. However a
> couple of things are sub optimal or not ideal (in no special order):
>
>
> - \Sodium\library_version_major() \Sodium\library_version_minor() and
> \Sodium\version_string() should be constants

I agree.

> For  \Sodium\version_string(), the name is not consistent as it refers
> to the library version not the extension version ("Returns a string
> identifier of the current version of the sodium library installed.")
> (edit: used would better represent what is actually happening)
>
>
> - memzero, memcmp, hex2bin
>
> I am not totally convinced that memzero and maybe memcmp names are
> good nor they should be there. Both would be very useful as operator
> on variables. Given the simplicity of the implementations, it could be
> very useful in many other areas in case this ext is not installed

IMO: memzero is fine; memcmp isn't that great.

For what it's worth, we have hash_equals() already.

> For hex2bin, the optional parameter could be added to the existing
> functions. As this function does not require crypto safe
> implementation (and does not need from an implementation), we should
> have them as part of the engine instead.

We should seriously just make bin2hex, hex2bin, base64_encode, and
base64_decode constant-time now so we don't have to worry later when
some clever CS post-doc find a way to exfiltrate crypto keys through
cache misses. That calls for a separate RFC, but there's no salient
argument against this change.

> - buf and other abbreviations should be better. I think we had a
> discussion some time ago about how to provide interfaces for non C
> developers.

No argument there.

> - compare should be string_compare, or it could be confusing about
> what it can compare, especially in code review while checking crypt
> code, where many other types come into the game

This is an excellent point.

>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Libsodium - Discussion

[Scott Arciszewski]

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 paragonie/EasyRSA + defuse/php-encryption or
>> paragonie/halite-- I wholeheartedly endorse that discussion. But I don't
>> think we should try to solve that problem with this particular RFC.
>>
>> In closing, I don't disagree that a simple crypto API is a good goal to
>> have. I just think the ideal you're discussing is:
>>
>> A. Out of scope, and
>> B. Kind of belittling to how much of an improvement libsodium is to what we
>> already have.
>>
>
> You are completely ignoring that once this is out the door there is no
> way back. We already see many problems in the current API and we should
> address them until we reach a point where the majority does not see
> major problems anymore.
>
> Doing anything else is just irresponsible!
>
> --
> Richard "Fleshgrinder" Fussenegger
>

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 conflate the two. (Even worse: I wouldn't want the mere
thought of an abstract high-level API to block libsodium from getting
accepted.)

Instead of /completely redesigning/ the libsodium API, what are some
changes that need to be made to alleviate the majority of concerns
("it's not the pluggable crypto API" notwithstanding)?

Two things to keep in mind:

1. If it breaks existing code that uses libsodium-php in a nontrivial
way, I'm going to resist the change unless it can be proven necessary
for the sake of everyone's sanity.
2. If it greatly deviates from the experience of using libsodium in
other programming languages (e.g. renaming crypto_box), you no longer
have libsodium and thus I will resist it.

Getting rid of redundant features (by improving existing ones, not
just cutting them!) is fine. Dropping scrypt, etc. is fine.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [PRE-VOTE] Union types

[Thomas Bley]

maybe you can add a few examples to the type table in the rfc, so everybody 
knows how it actually works:

function test(int | float | string $a) {var_dump($a);}
test(42.0); // float(42)
test('42'); // string(2) "42"

function test2(int $a) {var_dump($a);}
test2(42.0); // int(42)
test2('42'); // int(42)

function test3(int|bool $a) {var_dump($a);}
test3('foo'); // true

Regards
Thomas


Bob Weinand wrote on 03.06.2016 14:30:

> 
>> Am 3.6.2016 um 14:18 schrieb Rowan Collins :
>> 
>> On 03/06/2016 12:59, Bob Weinand wrote:
 function l(string | float $x) { echo gettype($x); }
 l("1.5a"); // I would expect string, but float would succeed if attempted
>>> 
>>> Exact matches *ALWAYS* match without coercion.
>> 
>> Gah, I keep making that mistake in my examples. I did say I was struggling to
>> get my head around things! ;)
>> 
>> I'm still missing an explanation of exactly where you derived the current
>> proposed rules from, though. The RFC just states "these rules are not an
>> invention of this proposal", but goes on to say "applies PHP casting rules in
>> a sane way", which implies some decisions were involved in drawing up these
>> rules.
>> 
>> I think you may be right that the rules are as simple as they can be, and I
>> don't want to waste too much of your time, but a basic summary of the
>> reasoning used would be much appreciated.
>> 
>> Regards,
>> -- 
>> Rowan Collins
>> [IMSoP]
> 
> The *weak casting* rules (i.e. what gets converted how and what can be
> converted to the other type) are not an invention of the proposal.
> 
> The proposal however defines the specific order.
> 
> I’ve added a reasoning why not left-to-right now. As this seemed to be asked
> multiple times.
> 
> Also, the specific reasoning why I propose that specific order the rules are
> in:
>> Otherwise PHP's casting rules are applied in an order to be as lossless as
>> possible.
> 
> That’s really the only motivation behind that.
> 
> Bob
> 
> 
> 
> 
> 


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Libsodium - Discussion

[Scott Arciszewski]

On Sat, Jun 4, 2016 at 6:15 PM, Stanislav Malyshev  wrote:
>
> Hi!
>
> > Let's begin discussing the prospect of adding libsodium as a core extension
> > in PHP 7.1. I've updated the RFC to explain why this would be a good idea
> > and the benefits it offers.
> >
> > https://wiki.php.net/rfc/libsodium
> >
> > If the subsequent discussion goes smoothly, I would like to open voting on
> > June 15.
>
> Some notes based on the docs in https://paragonie.com/book/pecl-libsodium:
> TLDR: I think the idea of having something like this in core is very
> nice, but I think it needs some tweaks in order to be a solution we can
> recommend as core module.
>
> - I would appreciate deeper namespacing. It is rarely that you would use
> all sub-modules (such as encryption, both symmetric and asymmetric,
> password hashing, decryption, random, etc.) in the same piece of code.
> So if I could just "use Sodium\Crypto;" and then use short names it
> would be much nicer than having to spell out the whole story.

This would entail a BC break against all software currently written
using libsodium.
Are you certain that deeper namespacing would be worth that trade-off?

> - Also, I'm not sure why functions like
> crypto_aead_chacha20poly1305_encrypt() exist. Shouldn't algorythm be a
> parameter to encryption function and not function name? Putting
> parameter into function names makes it much harder to be flexible and
> configurable. Or, if there's only one, then why not just call it
> encrypt() and state the fixed algorithm in the docs?

Libsodium offers few primitives. For AEAD, you have:

- ChaCha20-Poly1305
- AES-256-GCM (but only with modern hardware)
- ChaCha20-Poly1305 (IETF version with a bigger nonce)

These are distinct functions in the C API to discourage "Hey, I'll add
another algorithm and users can access it by changing the string
that's passed".

When all is said and done, crypto_aead_encrypt() and
crypto_aead_decrypt() will be the CAESAR winner.
https://competitions.cr.yp.to/caesar.html

> - The function names in general are kind of all over the place. I.e., to
> get a random, you get:
> - for string: _buf
> - for ranged (I assume unsigned?) integer: _uniform
> - for 16-bit unsigned integer: _random16
> If you can notice a pattern here, I can't. Also, I don't see why you
> have a function for 16-bit int but not for 8-bit or 32-bit. Additionally
> weird that _uniform gets int, but has limit different from PHP int.

To be honest, most of these aren't necessary in PHP anymore. They were
mostly useful in PHP 5.x before we had random_bytes() and
random_int().

> - Naming/namespacing of constant-time function should make it clear they
> are there because they are constant time, not just because somebody
> wanted to reimplement bin2hex. It's also unclear why we need memcmp as
> separate function from hash_equals().

Alternatively, if we can make bin2hex() and hex2bin() always
constant-time in PHP, we can eschew exposing these libsodium
functions. (Just make an alias for BC purposes.) I'd actually prefer
that.

> Also, I'm still not convinced bin2hex in PHP even has a timing problem.
> I haven't seen anything but vague generic theoretising in this regard.
> Same with hex2bin (in fact, even more since hex2bin doesn't even have
> index lookups).

These are the facts:

1. Index lookups based on the contents cryptographic secrets is a
recipe for microarchitecture side-channels (e.g. FLUSH+RELOAD).
2. The current implementation of all RFC 4648 encoding functions that
PHP has (which, strangely, doesn't include base32) violates rule 1.

https://cryptocoding.net/index.php/Coding_rules#Avoid_table_look-ups_indexed_by_secret_data

See how Halite stores keys for an example of "Yes, this does get used
for crypto secrets":
https://github.com/paragonie/halite/blob/6c026f7dc6a57ecd6c65e5944057acdefa8c9d67/src/KeyFactory.php#L604-L627

> - What exactly memzero does in PHP? Looks like it accepts argument
> by-ref, which means if you do something like:

It overwrites every byte in a string with NUL characters.

> function foo($secret_key) {
> // do stuff with key
> memzero($secret_key);
> }
>
> and then:
>
> $key = get_key(); foo($key);
>
> then $key still has the key. So I'm not sure how that all memory wiping
> is still working in practice. I mean, it may work with random keys that
> you generate, use once and immediately destroy, but in any other
> scenario it's just wasting time. Even with random keys it's iffy since
> it assumes your RNG state is either not in memory or is protected.

Right, it has to be used with care. But the existence of a
well-written cross-platform memory-zeroing function is almost reason
enough to vote in favor of libsodium.

See also: https://stackoverflow.com/a/29331937/2224584

> E.g. in the example at
> https://paragonie.com/book/pecl-libsodium/read/09-recipes.md#encrypted-cookies
> keys are meticulously erased, but since they are all deterministically
> derived from $this->key (and cookie 

Re: [PHP-DEV] [RFC] Libsodium - Discussion

[Fleshgrinder]

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 paragonie/EasyRSA + defuse/php-encryption or
> paragonie/halite-- I wholeheartedly endorse that discussion. But I don't
> think we should try to solve that problem with this particular RFC.
> 
> In closing, I don't disagree that a simple crypto API is a good goal to
> have. I just think the ideal you're discussing is:
> 
> A. Out of scope, and
> B. Kind of belittling to how much of an improvement libsodium is to what we
> already have.
> 

You are completely ignoring that once this is out the door there is no
way back. We already see many problems in the current API and we should
address them until we reach a point where the majority does not see
major problems anymore.

Doing anything else is just irresponsible!

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Libsodium - Discussion

[Fleshgrinder]

On 6/5/2016 12:25 AM, Stanislav Malyshev wrote:
> We don't really need the uniform part if we don't have the non-uniform
> one. If the only one we get is uniform, and it's the one we actually
> want, we should not spell it out in the name - we should name it
> something like random_int or random_range or random_between and explain
> in the docs that yes, it's the  uniform one and it's the only you get
> because uniform is awesome.
> 

https://secure.php.net/function.random-int

Is it uniform? That shouldn't be too hard to find out and the result
might be again that we actually don't need this new function at all.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Libsodium - Discussion

[Scott Arciszewski]

On Sun, Jun 5, 2016 at 2:20 AM, Pierre Joye  wrote:

>
> On Jun 5, 2016 5:15 AM, "Stanislav Malyshev"  wrote:
> >
>
> > The stated goal is "You shouldn't need a Ph.D in Applied Cryptography to
> > build a secure web application." I fully agree with this goal. I however
> > feel that current implementation, while making admirable progress
> > towards this goal, still needs some work to actually achieve it.
>
> I fully agree with you. As much as I think we need something 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 nature of libsodium's APIs is as follows:
​That 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 congruent implementation in libsodium:​

​http://framework.zend.com/security/advisory/ZF2015-10

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises 
​

Re: [PHP-DEV] [RFC DISCUSSION] typeof

[Fleshgrinder]

On 6/5/2016 12:36 AM, Stanislav Malyshev wrote:
> Why it should match scalar types? You can't use output of this function
> in a scalar type in any way.
> 

To avoid those WTF moments and make it easier for newcomers.

On 6/5/2016 12:36 AM, Stanislav Malyshev wrote:
> So let's add more of it by having multiple functions that do exactly the
> same thing but name null and float differently.
> 

The RFC contains the deprecation and removal of gettype as a non
optional vote. You are completely right that introducing new stuff and
more new stuff is the wrong way to go. We need to clean up too.

On 6/5/2016 12:36 AM, Stanislav Malyshev wrote:
> If you think people would want to edit gigabytes of existing code
> because you want NULL to be lowercase, you are very seriously mistaken
> about the order of priority of an average PHP developer. I am sure
> 99.% of people care about all this pedantry infinitely less than
> they care about their code keeping working and their development not be
> impeded by things like having to read the manual each time to choose
> which two of almost identical functions they need now and which of them
> has null in which case.
> 

I doubt that anybody relies on gettype to determine such things. They
use is_null($x) and $x == null or $x === null. Anyone who relies on a
function that had for years a warning in the manual that one should not
rely on the returned string value or debugging/error output to stay
consistent is doing something EXTREMELY wrong.

On 6/5/2016 12:36 AM, Stanislav Malyshev wrote:
> I think constantly disrupting the language environment by pedantic
> tweaks that add BC and cognitive load but do not actually enable
> anything new, just move things around - is not only confusing, but
> harmful for the whole ecosystem.
> 

This is the very nature of refactoring. Make things better without
changing its functionality. However, in this case we even have a change
of functionality.

On 6/5/2016 12:36 AM, Stanislav Malyshev wrote:
> And if "NULL" really confuses you to the point you have no idea what it
> means - well, really, I don't know what to say.
> 

Thanks for reducing my first contribution to this single tiny change
that is part of it. I am sure it will attract more people to contribute
to php-internals. :P (No worries, you don't scare me away, harharhar.)

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Libsodium - Discussion

[Pierre Joye]

On Jun 5, 2016 5:15 AM, "Stanislav Malyshev"  wrote:
>

> The stated goal is "You shouldn't need a Ph.D in Applied Cryptography to
> build a secure web application." I fully agree with this goal. I however
> feel that current implementation, while making admirable progress
> towards this goal, still needs some work to actually achieve it.

I fully agree with you. As much as I think we need something 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