[PHP-DEV] [PHP8.3] Feature freeze in 4 weeks

2023-06-20 Thread Eric Mann via internals

Good morning, all!

This is a friendly reminder from your RMs that the PHP 8.3 feature 
freeze is in ~4 weeks on July 18th [1]. Alpha1 is already out and Alpha2 
is scheduled this Thursday.


All new features and RFCs need to be discussed with voting polls closed 
on or before July 18th for inclusion in PHP 8.3.


Thanks everyone for the stellar work!

[1] https://wiki.php.net/todo/php83

--
PHP Cookbook 
*Eric Mann
* Tekton
*PGP:*0x63F15A9B715376CA 
*P:*503.925.6266
*E:*e...@eamann.com
eamann.com 
ttmm.io 
Twitter icon  LinkedIn icon 



[PHP-DEV] VCS Account Request: ericmann

2023-05-02 Thread Eric Mann via internals
PHP 8.3 release management

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



Re: [PHP-DEV] Release Managers for PHP 8.3

2023-03-01 Thread Eric Mann via internals
I had volunteered in a previous cycle but, sadly, lost in the voting 
round. That said, I'm still eager to be more heavily involved and up for 
the challenge (both for the immediate process and for any long-term 
support beyond the dates listed in the existing todo.


I've been working with PHP in userland since 2005 and dabbling in 
internals (mostly to understand FFI and interoperability) since 2016. 
I'm not a C guru as in I can't reliably _write_ greenfield C code. But I 
have worked with and on C/C++ teams and am well adept at groking 
existing code, hunting for bugs, and ensuring that submitted code does 
what it claims to do.


It would be an honor to even be considered for this role and I'd love to 
earn your support!


~Eric Mann

On 3/1/23 12:20 PM, Sergey Panteleev wrote:

Hi all,

It's time to start the process of finding and electing RMs for the next minor 
PHP release.

We are looking for three souls to take on this role. Whomsoever is elected will 
be guided and helped by the current, as well as previous RMs and the excellent 
documentation in release-process.md [1].

Candidates should have a reasonable knowledge of internals (without necessarily 
being a C guru), be confident about merging pull requests without breaking 
backward compatibility, doing triage for bugs, liaising with previous release 
managers, and generally getting the branch in good shape, as these are among 
the activities you will be undertaking as release manager.

Notably, at least one of the volunteers must be a "veteran" release manager, 
meaning they have participated in at least one release of PHP in the past. The other may 
be an additional veteran, or more ideally, someone new to the RM role (in order to 
increase our supply of veteran RMs).

Please put your name forward here if you wish to be considered a candidate. An 
initial TODO page has been added to the wiki and contains provisional dates for 
GA and pre-releases [2].

[1]https://github.com/php/php-src/blob/master/docs/release-process.md
[2]https://wiki.php.net/todo/php83

Let's all make PHP awesome!
Pierrick Charron, Sergey Panteleev & Ben Ramsey



--
Security Principles for PHP Applications 


*Eric Mann
* Tekton
*PGP:*0x63F15A9B715376CA 
*P:*503.925.6266
*E:*e...@eamann.com
eamann.com 
ttmm.io 
Twitter icon  LinkedIn icon 



Re: [PHP-DEV] base64url format

2023-01-09 Thread Eric Mann via internals
I'm in support of such a feature, but would strongly advocate for an 
additional parameter to flag whether or not to include the trailing `=` 
pad. The trailing pad is optional according to RFC 4648, so I think 
leaving it off by default would be the ideal use case, but an optional 
`include_padding` flag or something along those lines would be helpful.


On 1/9/23 10:49 AM, Sara Golemon wrote:

I've been working with JWTs lately and that means working with Base64URL
format. (Ref:https://www.rfc-editor.org/rfc/rfc4648#section-5  )
This is essentially the same thing as normal Base64, but instead of '+' and
'/', it uses '-' and '_', respectively. It also allows leaving off the
training '=' padding characters.

So far, I've just been including polyfills like this:

function base64url_decode(string $str): string {
 return base64_decode(str_pad(strtr($str, '-_', '+/'), (4 -
(strlen($str) % 4)) % 4, '='));
}

function base64_encode(string $str): string {
 return rtrim(strtr(base64_encode($str), '+/', '-_'), '=');
}

These work fine, but they create a LOT of string copies along the way which
shouldn't be necessary.
Would anyone mind if skipped RFC and just added `base64url_encode()` and
`base64url_decode()` to PHP 8.3?

Can hold a vote if anyone objects, but this seems fairly non-controversial.

-Sara



--
Security Principles for PHP Applications 


*Eric Mann
* Tekton
*PGP:*0x63F15A9B715376CA 
*P:*503.925.6266
*E:*e...@eamann.com
eamann.com 
ttmm.io 
Twitter icon  LinkedIn icon 



Re: [PHP-DEV] Early feedback on encrypted session PR

2022-05-18 Thread Eric Mann via internals
I'm not sure I'm a fan of the PR as it stands, but the idea of 
encrypting session data - definitely.


When sessions are stored on disk, that data is plainly visible by anyone 
(or any process) with read access to that disk. If they're cached 
instead in a DB or an in-memory system like Memcached, the same rules 
apply - anyone else who can read data from that system can read what's 
stored in the session. That being said, how much you care about this 
level of access depends very much on your threat model. If sessions are 
storing data like upvotes or view counts, this information likely isn't 
sensitive enough to worry about whether or not things are encrypted.


If you're storing customer PII in a session, though, then protecting 
this data "at rest" in your session store becomes critical.



It is already possible to write an own SessionHandler which
encrypts/decrypts the session payload.  That said, I'm not against
adding an encryption option.


This is 100% the route I've taken in the past. 
https://github.com/ericmann/sessionz (which I admit needs some updates) 
includes one example SessionHandler implementation that does just that. 
However, it would be fantastic to see this as part of the standard 
library. Session management in PHP can be tricky, particularly in larger 
applications with multiple entry/return points. A standard (read: 
simplified) implementation would go a long way.


--
Security Principles for PHP Applications 


*Eric Mann
* Tekton
*PGP:*0x63F15A9B715376CA 
*P:*503.925.6266
*E:*e...@eamann.com
eamann.com 
ttmm.io 
Twitter icon  LinkedIn icon 



Re: [PHP-DEV] [8.2] Release Manager Election

2022-05-11 Thread Eric Mann via internals

Best of luck to all of the volunteers in this election!

To add some color about why I threw my hat in the ring (and save you the 
trouble of trying to find the earlier thread):


I've been using PHP since the days of version 4 and our older/clunkier 
method of OO programming. I've bounced around to various other 
languages, spending a lot of time working in .Net as the sole web 
developer in an otherwise C-focused company, before landing firmly on 
PHP as my primary tool of choice. In my day job, I also support 
codebases in Python, JS (including React, Node, and even TypeScript), 
and Golang. I also manage system infrastructure along with my team and 
am enjoying a renewed professional focus on cybersecurity.


Prior to 2020, I spoke regularly on PHP in public 
(https://joind.in/user/EricMann) and have done my best to continue that 
during lockdown, albeit remotely. I maintain the monthly Security Corner 
column in php[architect] and also wrote a book on Security Principles 
for PHP through the same. Today, I'm continuing to seek out 
opportunities to speak while remaining focused on helping my team keep 
their codebase safe, secure, and performant. I'm also working on a new 
PHP Cookbook for O'Reilly 
(https://www.oreilly.com/library/view/php-cookbook/9781098121310/) with 
the intention of covering PHP 8.2 as well.


In terms of engineering, above all I value automation, scalability, 
security, and reliability. Regardless of whether or not you select me as 
an RM, I still plan to be fairly involved in and aware of goings on for 
this release. But I would very much appreciate you support :-)


~Eric

On 5/11/22 7:51 AM, Ben Ramsey wrote:

Happy middle of the week, everyone!

We’ve had another great turn-out for PHP Release Manager selection this year.

In the role of “Veteran” release manager, Ben Ramsey[0] (that’s me!) has 
volunteered to mentor two rookies, so there will be two seats up for grabs. As 
I mentioned in an earlier message, Joe and I discussed that it might be a good 
practice to have one of the rookie RMs from the current release serve as the 
veteran for the next release. In this way, any new advances or changes to the 
process will be carried forward to the “next generation” much more smoothly. 
So, we’re going to give that a try and see how well it works.

For those two rookie seats, we’ve got seven eager candidates for your 
consideration [1-7]. Some of these included a statement about their background 
in their initial email volunteering for the role, the rest I encourage to reply 
to this thread providing some background on why they’ll be awesome.

Voting is now open onhttps://wiki.php.net/todo/php82  using “Single 
Transferrable Vote” (STV). Those who participated in prior elections will 
recognize the format; for the rest, the TL;DR is that it allows each voter to 
state their preference order by voting multiple times. There are seven polls on 
the wiki for your seven preferences, in descending order. Using some math that 
I’ll leave to Wikipedia[8] to explain, we’ll start with the 1st preference and 
gradually remove candidates with the fewest votes, transferring votes that had 
previously gone to them to their voter’s 2nd preference, and so on. Once two 
candidates have a quorum (Droop quota), those will be officially selected as 
our RMs. Derick Rethans has volunteered to proctor the tabulation of the votes 
since he still has scripts from last year.

As you consider each candidate, please bear in mind that this is a 3.5 year 
commitment and is a position of trust.

Thank you in advance for your consideration.

Your 8.1 Release Managers,
Ben Ramsey, Patrick Allaert, & Joe Watkins

Vote Opens: 11 May 2022
Vote Closes: 18 May 2022

Refs:
0 - Ben Ramsey:https://news-web.php.net/php.internals/117664
1 - Sergey Panteleev:https://news-web.php.net/php.internals/117596
2 - Evan Sims:https://news-web.php.net/php.internals/117621
3 - Aaron Junker:https://news-web.php.net/php.internals/117623
4 - Calvin Buckley:https://news-web.php.net/php.internals/117627
5 - Eric Mann:https://news-web.php.net/php.internals/117629
6 - Pierrick Charron:https://news-web.php.net/php.internals/117650
7 - Saif Eddin Gmati:https://news-web.php.net/php.internals/117702
8 -https://en.wikipedia.org/wiki/Single_transferable_vote



--
Security Principles for PHP Applications 


*Eric Mann
* Tekton
*PGP:*0x63F15A9B715376CA 
*P:*503.925.6266
*E:*e...@eamann.com
eamann.com 
ttmm.io 
Twitter icon  LinkedIn icon 



Re: [PHP-DEV] PHP 8.2 Release Manager Selection

2022-04-26 Thread Eric Mann via internals
I'm new to this mailing list as I'd previously (and very mistakenly) 
assumed it was meant for existing contributors. So I've always consumed 
conversations via web-based aggregators rather than directly.


My mistake.

That being said, I am very interested in being a part of this release. 
I've been using PHP since ~2005 and cut my teeth on PHP4. Since then, 
I've covered everything from Fortran to VB.net and C# to Ruby to Python 
to Golang. Today I write a mix of Python and PHP primarily (with a 
smattering of Go and a curiosity about Rust). I'm not a C guru, but in 
previous roles worked with several of them and can follow my way around 
a C codebase. I've frequently gone spelunking through PHP's system to 
help document various methods or interfaces exposed by the standard 
library as well.


I am in no way a veteran PHP RM, but I am a fairly experienced RM with 
private codebases. I live and breathe in Git, love automation, and have 
been accused of more than a passing fancy in security as well. Somewhere 
along the line I managed to coax php[architect] into publishing my book 
on the OWASP Top Ten, and they still put up with my monthly security 
column as well.


In other words, I'd love to be a part of this and am more than happy to 
answer any and all questions y'all want to throw my way.


~Eric Mann

On 4/26/22 11:27 PM, Sergey Panteleev wrote:

From: *Sergey Panteleev* 
Date: Tue, Apr 26, 2022 at 11:27 AM
Subject: [PHP-DEV] PHP 8.2 Release Manager Selection
To: Christoph M. Becker , PHP internals 




Hey Christoph,

Do we choose one rookie for this release or two (as for 8.1)?

Also, maybe define some kind of deadline for submitting applications 
and the voting phase, thoughts?


—
wbr,
Sergey Panteleev


--
Security Principles for PHP Applications 


*Eric Mann
* Tekton
*PGP:*0x63F15A9B715376CA 
*P:*503.925.6266
*E:*e...@eamann.com
eamann.com 
ttmm.io 
Twitter icon  LinkedIn icon