Re: [PHP-DEV] Adding the OpenSSF Scorecards GitHub Action
On Thu, Oct 20, 2022 at 2:26 PM Pedro Nacht via internals < internals@lists.php.net> wrote: > I've made this suggestion as issue #9778 ( > https://github.com/php/php-src/issues/9778) and PR # 9789 ( > https://github.com/php/php-src/pull/9789), but have been invited by > @damianwadley to bring it to the mailing list. > > The Scorecards GitHub Action basically keeps an eye on a repo's security > posture and makes simple, objective suggestions for possible improvements. > > For PHP's current Scorecard results, see here: > https://api.securityscorecards.dev/projects/github.com/php/php-src. At the > moment it's a raw json dump, but it contains information on the results of > all the individual checks as well as comments on how to improve the scores. > When the Action is installed, this is cleanly added to the project's GitHub > Security Panel with step-by-step instructions. > What actionable benefit could this provide the project? Letting contributors know that some issues weren't responded to within 24 hours or something? I mean... none of us are paid to do that. Of course Google OSS projects have that kind of response, there's a trillion dollar company paying people to do that. But it's not like seeing a notification about something like that would provide php-src with actionable information. If we miss a metric that it's concerned about... who is responsible for doing something about it? Obviously the project is very active, and we have a lot of people who contribute, and we often do have quick responses between all the volunteers for things that need to be done quickly. But metrics and guarantees? If Christoph goes on vacation and Nikita is busy with work and Dmitry hasn't checked for notifications for a few days and everyone else thinks that one of them should weigh in first, then what would such a score actually tell us about the project? That we don't have employees responsible for those tasks? We already know that. What would forcing maintainers to go through a PR and review process for the types of changes that normally get pushed directly to master provide? A way for third parties to weigh in? Can't they already do that through the mailing list, issues, and PRs? If Google wants to help the PHP project, helping the project is probably better than supplying a tool that makes volunteers feel obligated in ways that employees do. Joe, Christoph, Dmitry, Nikita, Dan, etc all of these people with deep knowledge of the project and its history are critical to the project, but none of them are beholden to it. We were all sad to hear that Nikita's focus would shift with his new professional opportunities, but that doesn't mean he was wrong to take those opportunities or that he owed anything more than he was willing to give to the project. I just don't see what tangible benefit or actionable information something like this could provide. It's neat, and interesting, and maybe a bit of a novelty. But as part of an organizational workflow for the PHP project... why? Jordan
Re: [PHP-DEV] Adding the OpenSSF Scorecards GitHub Action
Hello Pedro. On Thu, 20 Oct 2022 at 23:26, Pedro Nacht via internals wrote: > > I'm happy to answer any questions anyone might have What is the morality of open source? What is the morality of encouraging people to contribute to open source? When people see open source projects being abused by multi-billion dollar companies, should they stay quiet or should they ask really annoying questions on the mailing list? > First time contribution to the mailing-list, apologies > for any missteps! Apologies in advance for being difficult, but a lot of people who have contributed to Open Source for years have quite strong feeling about events that have occurred, and manipulation by large companies. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Microseconds to error log
On 21 October 2022 08:47:30 BST, Mikhail Galanin via internals wrote: >Basically, we have quite a high-loaded environment and we really want >to see timestamps containing milli-/microseconds in our logs. I'm not knowledgeable enough to comment on the implementation details, but from a user point of view I agree the feature would be useful. It would definitely need to be behind an ini setting, though, to avoid existing log parsers failing unexpectedly on the new format. Regards, Hi Mikhail, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Microseconds to error log
Description Hi there, I started this thread on GitHub but Christoph (cmb69) suggested this is the better place to discuss such a thing. (initial post: https://github.com/php/php-src/issues/9745) Basically, we have quite a high-loaded environment and we really want to see timestamps containing milli-/microseconds in our logs. It is easy to do for our custom logger but error messages from the PHP itself narrowed down to seconds (I'm talking about method php_log_err_with_severity() Link: https://github.com/php/php-src/blob/master/main/main.c#L799:~:text=php_log_err_with_severity In our repository, we have a hacky patch that adds microsecs in this log as well. Unfortunately, such a solution is not really a good approach to looking into the future. I wanted to adopt our patch to share it with the community and potentially merge it into upstream but stumbled upon the fact that it isn't really straightforward to format a date/time with microseconds using the standard API available for an extension. Basically, I found a couple of options: (1) We can instantiate a DateTime object and call DateTime::format(). It looks working but it makes the logging function way more complicated and potentially heavy (2) date_format works directly with timelib_time and can properly handle microsecs but it is hidden inside ext/date/php_date.c, Not really sure if it's a good idea to make it public (3) In theory, it is possible to add one more parameter to php_format_date but it'll break all the existing code. The change of signature doesn't look like a good option. However, we might be able to introduce another function if we want to encapsulate work with timelib_time within the ext/date. (4) Derrek Rethans suggested introducing a new function (e.g. php_format_date_ex) that takes care of usecs (see the thread on Github) Looking into the future, probably we would like to have this format configurable, if so it looks easy to do but still I can't see an easy way to handle the microseconds issue. Could you please help me to find the right way and share your thoughts about this topic (maybe there are strong objections against such a change)? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
