In a post to his site Matthew Weier O'Phinney shares some notes about GraphQL usage that he's gathered over the last week or so of working with it.

The last week has been my first foray into GraphQL, using the GitHub GraphQL API endpoints. I now have OpinionsTM.

The promise is fantastic: query for everything you need, but nothing more. Get it all in one go. But the reality is somewhat... different.

He talks about his experience working with the results and the amount of data manipulation that was required to actually get at what he wanted. He shares the query he used, the result the API provided and what he ultimately wanted. He also mentions the less than useful documentation, issues with pagination and an update based on comments of pulling data from the GraphSQL API versus the REST API.

Geoff Wozniak has written up a post on the "Curried lambda" site sharing his opinion on ORMs (object relational mappers) for working with databases and how, after using them in his own development work, that they're a good side benefit but shouldn't replace knowing SQL.

I've come to the conclusion that, for me, ORMs are more detriment than benefit. In short, they can be used to nicely augment working with SQL in a program, but they should not replace it.

[...] Neward, in his well known essay, lays out many cogent reasons why ORMs turn into quagmires. In my experience, I've had to deal directly with a fair number of them: entity identity issues, dual-schema problem, data retrieval mechanism concern, and the partial-object problem. I want to talk briefly about my experiences with these issues and add one of my own.

He breaks the rest of the article up into several sections, for each sharing some of his own experiences with the feature and how it could be resolved using other query methods:

• Partial objects, attribute creep, and foreign keys
• Data retrieval
• Dual schema dangers
• Identities
• Transactions

He ends the post with a look forward, thinking about where he'll end up, mentioning stored procedures, queries as APIs and how "easy" isn't always best when it comes to ORMs.

The RIPSTech group has a post to their site with the announcement of the return of their security-related advent calendar. This year, however, it comes in the form of the PHP Security Advent Calendar with more of a "common security problems in PHP" approach than a list of vulnerabilities.

The end of the year is coming closer and the cheery advent time begins. We are looking back at a spectacular year and it is time to thank and give back to the great PHP, infosec, and RIPS community. Thank you for developing, auditing, and securing your PHP applications with us in 2017!

Similar to last years advent of PHP application vulnerabilities where we released a new application vulnerability each day, we will release a new calendar gift from December 1st to 24th this year again. This time, we will focus on nifty PHP pitfalls and release a daily code challenge for you to solve. Can you spot the daily security bug?

As today is December 1st, the first item has been posted to the calendar covering the use of whitelists versus blacklists. Keep checking back daily for new updates to the calendar and the daily code challenges.

In a new post to his site Christian Weiske shares his interaction with the Open Source group at Apple concerning his Structures_Graph PEAR package. While they were interested in the package and its functionality but with one issue.

Fact is that Structures_Graph is used in the PEAR installer, which is shipped as part of OSX's PHP packages. Apple simply wanted to continue their current setup without changing anything

Unfortunately, Apple had issues with the package being under the LGPLv3 license. They had a concern that, in certain circumstances, the license could allow the owner access to other potentially sensitive information from the user. He lists out his options - bascially either changing the license, asking Apple for compensation or just tell them "no". Unfortunately, if they decide that having it under that license isn't acecptable, they may drop PEAR all together (as the package is a part of the installer itself).

On the SenseDeep Security site Michael O'Brien has posted a web developer security checklist you can use as a starting place towards securing your application (and developing secure applications from the start).

Developing secure, robust web applications in the cloud is hard, very hard. If you think it is easy, you are either a higher form of life or you have a painful awakening ahead of you.

[...] After you review the checklist below, acknowledge that you are skipping many of these critical security issues. At the very minimum, be honest with your potential users and let them know that you don’t have a complete product yet and are offering a prototype without full security. This checklist is simple, and by no means complete. It is a list of some of the more important issues you should consider when creating a web application.

He breaks it down into different sections with items to check off for each:

• Database integration and data storage
• Development environments and security scanning
• Authentication
• Denial of Service protection
• Securing the Web Traffic
• APIs
• Validation (input and whitelisting)
• Cloud service and Infrastructure configurations
• General Operations and Testing

He ends with two points that are easy to forget when developing any application: determining what you're protecting against (threat modeling) and having a practiced security plan in place. Remember, checklists are a good place to start but by checking off each item it doesn't mean you're 100% secure.

In a new post to the Liip blog Lennart Jegge shares a "quick look" at the current state of the Drupal 8 project and some of the issues some people are having making the transition.

Eight months ago Drupal 8.0.0 was released. Exciting news for drupalists. Since then comparing D8’s features to its predecessor is a topic in daily business. "Can drupal 8 do what we can do now with 7 today?". After playing around with D8 i get the feeling some crucial features are missing.

He shares some of the features he sees as still missing (a Top 10 wishlist) and how it seems difficult to get a good overview of the Drupal 8 ecosystem. Some modules have yet to be updated and rewrites can be difficult given the major "under the covers" changes to Drupal itself.

In the end the importance of a variety of mature modules that play together nicely is crucial when it comes to efficiency, maintainability and stability of a project

On the Zend Framework blog there's an update from Gary Hockin about some GitHub project-level changes that will be happening soon. He'll be doing some housekeeping on the current list of open issues in the main zf2 repository.

I want to make you aware of some upcoming changes to the issues that are currently logged in GitHub. We currently have 426 open issues that are logged against the (now) meta zf2 repository. The vast majority of these are now in the wrong place, as we've split our once monolithic single repository into the many single component repositories. These issues should be moved from the zf2 repository to the correct component that the issue relates to.

He's closed some issues in preparation and tagged others with a "To Be Closed" tag for later handling. By early May all issues tagged "To Be Closed" will be finished out and/or moved to the correct locations. This will leave the project with around 100 issues to manage and to move to the right locations.

The Laravel project has traditionally held discussions about the internals of the framework in an IRC channel on the Freenode.net network. The decision was made recently, however, to move the development over to GitHub (most likely to make it more accessible).

There's already several issues that have been posted on the Issues list in the GitHub repository including things around:

• improving typecasting
• decoupling Carbon (the date handling library)
• a fluent interface for validation
• enhancing the localization functionality

You can give feedback or start your own discussions by adding an issue to the list or just sharing your thoughts on current topics.

As is mentioned in this post to the PEAR blog the server hosting the packages and website has been fully restored as of December 11th and should be 100% functional again.

Our server sponsor eUKhost quickly provided us with a new machine after we told them the old had failed, and the last two weeks were spent setting it up to provide the same functionality as before.

This includes not only the pear.php.net site but also the bug tracker, manual and downloads handling. They share a bit about why it took so long to correct (mostly having to do with technological difficulties with the server provided by the host). While backups did exist, they were only for the packages themselves and XML file structure. Unfortunately this did not include the website and blog database or patch files in the bug tracker. The remainder of the post lists several other smaller things that went wrong in the process, all adding up to plenty of difficulties for Christian as he battled to get the server (and services) back up and running.

The Paragon Initiative has posted an article to their blog talking about how to build secure applications in PHP. Rather than try to get into the specifics of specific vulnerabilities, they stay relatively high level and stick with concepts to keep in mind and steps you can follow to ensure your development practices are secure.

Whether you're planning the development of a brand new application or trying to prevent legacy code from causing a costly data breach, if you're going to be writing PHP, where should you begin? That is the question we will attempt to answer, in detail.

The article starts with an "easy way out" for those that don't feel like they know enough or just don't have the resources they need: hire consultants. With that out of the way, the article mentions two root causes for insecure apps: lack of knowledge about security and bad development habits. They then get into some suggestions about how you can learn to understand and prevent vulnerabilities in your own applications. They focus in on a few key places for PHP developers to pay attention to, complete with some charts showing the parts of the flow. The post ends with some advice on what do to if your site is compromised anyway and how to move forward.