Disclosure of Additional Security Fix in WordPress 4.7.2

WordPress 4.7.2 was released last Thursday, January 26th. If you have not already updated, please do so immediately.

In addition to the three security vulnerabilities mentioned in the original release post, WordPress 4.7 and 4.7.1 had one additional vulnerability for which disclosure was delayed. There was an Unauthenticated Privilege Escalation Vulnerability in a REST API Endpoint. Previous versions of WordPress, even with the REST API Plugin, were never vulnerable to this.

We believe transparency is in the public’s best interest. It is our stance that security issues should always be disclosed. In this case, we intentionally delayed disclosing this issue by one week to ensure the safety of millions of additional WordPress sites.

On January 20th, Sucuri alerted us to a vulnerability discovered by one of their security researchers, Marc-Alexandre Montpas. The security team began assessing the issue and working on solutions. While a first iteration of a fix was created early on, the team felt that more testing was needed.

Meanwhile, Sucuri added rules to their Web Application Firewall (WAF) to block exploit attempts against their clients. This issue was found internally and no outside attempts were discovered by Sucuri.

Over the weekend, we reached out to several other companies with WAFs including SiteLock, Cloudflare, and Incapsula and worked with them to create a set of rules that could protect more users. By Monday, they had put rules in place and were regularly checking for exploit attempts in the wild.

On Monday, while we continued to test and refine the fix, our focus shifted to WordPress hosts. We contacted them privately with information on the vulnerability and ways to protect users. Hosts worked closely with the security team to implement protections and regularly checked for exploit attempts against their users.

By Wednesday afternoon, most of the hosts we worked with had protections in place. Data from all four WAFs and WordPress hosts showed no indication that the vulnerability had been exploited in the wild. As a result, we made the decision to delay disclosure of this particular issue to give time for automatic updates to run and ensure as many users as possible were protected before the issue was made public.

On Thursday, January 26, we released WordPress 4.7.2 to the world. The release went out over our autoupdate system and, over a couple of hours, millions of WordPress 4.7.x users were protected without knowing about the issue or taking any action at all.

We’d like to thank Sucuri for their responsible disclosure, as well as working with us to delay disclosure until we were confident that as many WordPress sites were updated to 4.7.2 as possible. We’d also like to thank the WAFs and hosts who worked closely with us to add additional protections and monitored their systems for attempts to use this exploit in the wild. As of today, to our knowledge, there have been no attempts to exploit this vulnerability in the wild.

#4-7, #release, #security

Dev Chat Summary: January 25th (4.7.2 week 2)

This post summarizes the dev chat meeting from January 25th (agendaSlack archive).

4.7.2 Schedule

  • Reminder that no release date has been scheduled for 4.7.2 yet, we will assess tickets milestoned in Trac next week and begin planning for timing then.

Customizer team update

  • Please read two most recent posts: Customization in 2017 and Meeting Notes from January 23
  • Began scrubbing 198 tickets in customize component backlog to evaluate their priorities against the goals for the year, closing the ones that are no longer valid
  • We’re assigning tickets to the next minor release when they are defects or small enhancements that can be tackled in the next month
  • Larger enhancements that are aligned with the year’s goals which are not suitable for the next few weeks will be assigned to 4.8
  • The Future Release milestone is for tickets that should be done but which aren’t a priority for the goals of customizer this year
  • Looking for input on #39692 (Fix missing assignment of menus on theme switch), #39693 (Fix missing assignment of widgets on theme switch), and #35243 (Extending the text widget to also allow visual mode)
  • Big effort around #35760 (Provide API for TinyMCE editor to be dynamically instantiated via JS), so if you’re well-versed in TinyMCE please help
    • In summary, this will provide basic text formatting, links, and media embedding capabilities
  • If you’re looking for patches to contribute, please look at the defects milestoned for 4.7.2 that need patches
  • Continuing big picture design discussions about what the customizer should look like in light of conversations also happening with the editor

Editor team update

  • Please review the What Are Little Blocks Made Of? post and subsequent comments to get some insight into their approach on “blocks” as the focus this year

Trac Ticket(s)

  • #39256: REST API: Multiple issues with setting dates of posts
    • Not really possible to use the REST API to manipulate dates in a reasonable fashion
    • This is something we should fix ASAP before people start relying on the current, broken behavior
    • Please take a look, especially if you have experience with date handling in other parts of WP
  • #39466: Get list of post API request missing status
    • Should be a pretty easy win in 4.7.2
  • #39264: Add WP-API JS Client unit tests to core
    • Could use a review
    • Would love help automating the generation of the mocked data, ideally as a grunt task
  • #39072: Add gmt_offset as a REST API setting
    • Sort of related to date handling, a bit involved, doing it later isn’t so bad because it’s an addition rather than a change
  • #36574: Redesign term pages
    • Patch needs testing from Taxonomy team

#4-7, #4-7-2, #dev-chat, #summary

Providing a REST API sites endpoint for multisite

One of the objectives for multisite is to determine how sites can be managed with the REST API. This has been an agenda item for the last two weeks and quite a bit has been processed. This will continue to be a topic, so please stop in for #core-multisite office hours on Tuesday 17:00 UTC and please leave your feedback in the comments on this post.

January 17 chat log and January 24 chat log in #core-multisite

Attendees: @kenshino, @vizkr, @danhgilmore, @iamfriendly, @flixos90, @schlessera, @sergeybiryukov, @pbearne, @paaljoachim, @streetlamp, @jnylen0, @loreleiaurora, @maximeculea

The requirements for the /sites/ endpoint can be summed up with these assertions:

  • The /sites/ endpoint should provide a useful set of data for each site without requiring the use of switch_to_blog().
  • It should be possible to query /sites/ for something other than ID, domain, and path.

In its current state, any /sites/ endpoint is limited to the fields in the wp_blogs table. Data such as a site’s name and description are stored in each individual site’s wp_#_options table.

Given a list of 20 sites, switch_to_blog() will be used 20 times so that get_option() can be used to retrieve things like home, siteurl, blogname, and blogdescription. An example of how inefficient this is can be found in the generation of the My Sites menu. Caching has gotten better with the introduction of WP_Site and WP_Site_Query, but there is an opportunity to change how the information is stored.

In #37923, @johnjamesjacoby suggests the introduction of a wp_blogmeta table that provides access to some site information in a common table. After discussing this in the January 17 chat, @iamfriendly and @flixos90 agreed to each take a look at core’s default options stored in wp_options and determine which made sense in a shared wp_blogmeta table. Richard’s results can be found in a comment on the ticket and Felix’s in the Slack discussion.

After some discussion in the January 24 chat, that list can be pared down a bit more.

  • home
  • siteurl
  • blogname
  • blogdescription
  • admin_email

The creation of a new table, wp_blogmeta, and migration of data for each site from wp_#_options is something that needs feedback. Without this change, a /sites/ endpoint is still possible, but may be limited. With the change, a /sites/ endpoint is much more useful, but requires a careful migration process.

#multisite, #networks-sites, #rest-api

Dev Chat Agenda for January 25th (4.7.2 week 2)

This is the agenda for the weekly dev meeting on January 25, 2017 at 15:00 CST:

  • Schedule reminder: no release date scheduled for 4.7.2, will assess tickets next week and begin planning for timing then
  • Customizer team update
  • Editor chat summary / visuals update
  • Review on #39256 (REST API: Multiple issues with setting dates of posts)
  • General announcements

If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

#4-7, #4-7-2, #agenda, #dev-chat

Customization Meeting Notes: January 23, 2017

From today’s #core-customize meeting:

Thanks @iandstewart for help with notes. Drop by #core-customize next week on Monday at 1:00pm EST for the next full meeting, or join us at the same time tomorrow for ticket triaging.

Improving the Settings API for accessibility and ease-of-use

On January 2nd the first meeting to discuss improvements of the well-known, but not well-loved Settings API took place in #accessibility. After a healthy discussion the next meeting was set to take place last Monday. Since the suggested improvements are not solely related to accessibility, the location for the meeting was moved to #core. This post is a recap of what was decided during these two meetings.

Archives of the full conversations:

Attendees: @afercia, @flixos90, @helen@joedolson, @johnbillion, @rianrietveld, @sc0ttkclark

First Meeting

The original reason for calling these meetings were several accessibility problems on WordPress settings pages. To quite some extent, these are related to the table markup that is automatically printed by the current Settings API. On a related note, it was mentioned that being required to write callback functions for rendering each and every field is a major drawback. Providing default callbacks would thus not only make it easier to work with the API, but also further improve accessibility as these callbacks would all be reviewed by the team. So the two main goals that were figured out were:

  • Add some basic support to automatically render fields so that plugin developers no longer need to write their own callback functions for basic fields.
  • Get rid of the table structure to improve accessibility. Furthermore the accessibility team should also ensure that the markup generated as the core field output is accessible.

The first meeting was also centered on whether these improvements should be tackled through means of the Fields API project, a new “Settings API v2” or improving the existing Settings API. In the end it was decided to continue working with the existing API, mainly for the following reasons:

  • The Fields API project is a huge effort that will still take a while until it can possibly be merged into core. Still, it will follow up with the changes that will be introduced in the Settings API, as @sc0ttkclark pointed out. While printing fields is certainly the focus of the Fields API, introducing a few technically simple callbacks in core at this point will not be a problem as these can be migrated to the Fields API ones at any time.
  • While the existing Settings API has its problems, it appears to be possible to handle the necessary improvements without running into backward-compatibility issues. A completely new Settings API could have further benefits, but it would leave many users behind that would need to manually migrate, and furthermore would take much longer to scaffold and implement.

After the meeting, a general ticket for the task was opened at #39441. The ticket description provides more information on how the two identified goals should be accomplished. In addition to the technical details, the first part of the accessibility measures will be to create an HTML-only prototype of what a better settings page would look like. It should be created without the limitations of the Settings API, so that the result can be the best possible example for what the enhanced Settings API should produce.

Second Meeting

@rianrietveld had four items on the agenda for the second meeting.

  • At first, everyone was asked to review the patch that @flixos90 provided on the above ticket. The patch only applies to introducing default field callbacks, so it still lacks adjustment of the table markup and a proper accessibility review, but it shows a possible technical approach.
  • Related to the patch, a tiny plugin was created and uploaded to the ticket as well. This plugin allows for easy testing of the functionality. For easier collaboration and possible iterations, that plugin has now been moved to GitHub. Feel free to try it out with the patch applied.
  • Some results of an accessibility test for form elements that was conducted by the accessibility team were revealed as a preparation for the prototype settings page in HTML. A few major issues to consider were discussed, for example the requirement of IDs on every field, the proper usage of fieldset and legend elements and the problematic usage of <input type="number"> for Dragon NaturallySpeaking speech recognition software. For creating the HTML prototype, it was decided to focus on replicating the core settings pages “General” and “Discussion”.
  • For the next step of the efforts, @afercia volunteered for creating the prototypes. As of now, the field markup he created for the two replicated settings pages can be inspected on GitHub (last two items in the list). These will probably be discussed in the next meeting.

If you are interested in helping out, there are several ways for you to do so: Please review the suggested improvements, the HTML prototypes and/or the technical approach. Feedback can be provided on the ticket, this post or by participating in the upcoming meeting/s. The Settings API meeting takes place biweekly on Monday at 17:00 UTC, so feel free to drop by. The next meeting will be on Monday, January 30.

#accessibility, #settings

Customization in 2017

The editor will endeavour to create a new page and post building experience that makes writing rich posts effortless, and has “blocks” to make it easy what today might take shortcodes, custom HTML, or “mystery meat” embed discovery.

The customizer will help out the editor at first, then shift to bring those fundamental building blocks into something that could allow customization “outside of the box” of post_content, including sidebars and possibly even an entire theme.

Matt

One expectation I want to start with is, customization isn’t just improving the Customizer — our goal is to improve the entire process of setting up a site, from initial installation to something you’re comfortable launching, to making changes to an existing site that has been live for some time. To that end, our goal is to help people accomplish the following:

  • “I want to make a site that I’m proud of that helps me succeed.”
  • “I want to make a site my clients are proud of that helps them succeed.”

The current customization flow in WordPress doesn’t generally facilitate either of those goals without a great amount of work, prior knowledge, and often a lot of additional development. That’s fine if you’ve hired an agency, or you’re a developer building yourself a website — but not fine if you’re a freelance site builder/implementer (a market I see every day in my local community) or are trying to build something for yourself with limited time and budget. If you can install WordPress, either manually or through a host, we should provide you with the tools to build out a website that accomplishes your personal and business goals.

With these goals in mind, what can we accomplish in the first couple months of the year?

  • Demo content on theme switch for an existing site. [#38624]
  • Pain points with lost widgets and menus when switching themes. [#19912]
  • Exploring a better customization-focused onboarding experience.
  • Adding an media widget. [#32417]
  • Adding formatting options to the text widget. [#35243]
  • Adding a code editor to the Custom CSS control, and make additional enhancements. [#12423, #38707]
  • REST API endpoints. [#39634, #38900]
  • Improving Custom Logos. [#38329, #36191]
  • Some more minor Customizer improvements [#37471, #38953, #39389] and continued bug fixing.
  • What else? Please comment.

Throughout the rest of the year, there’s a lot of larger projects that we’ll collaborate with the editor team on:

  • Content blocks, so we can build a better layout editor that helps people build a site that fits their individual needs. [Post]
  • Revisions, so you can visually see the changes you’ve made to your site and revert if you mess up. [#31089, #21666]
  • Drafting, reviewing, publishing, and scheduling changes, so you can get your site looking just right before you push your changes live. [#31089, #28721]

Some of these, like revisions in the Customizer, we can prioritize sooner.

By the end of 2017, we hope you’ll be able to:

  • Have an onboarding experience with smart defaults that guides you towards building the site you want, faster.
  • Build complex, dynamic layouts for your WordPress sites, regardless of your theme.
  • Move any piece of content on your site to a different part of your site, just by dragging and dropping it where you want.
  • Allow you to preview and select page layouts before you create your page.
  • Edit every piece of content where you see it, instead of needing to hunt for it.
  • Set up a basic website without having to jump in and out of multiple admin screens.
  • Live preview any settings that affect how your site looks.
  • Revert changes and see your revision history.
  • Maybe even build your whole site from your phone?

What other customization flows do you think we need to improve? We need your input to help make a better way to build sites with WordPress.

We’ll be doing weekly meetings every Monday. The next meeting is Monday at 1:00PM EST. Join us in #core-customize in Slack to get involved!

Dev Chat Summary: January 18th (4.7.2 week 1)

This post summarizes the dev chat meeting from January 18th (agendaSlack archive).

4.7.x Releases

  • Moving to monthly checkins for 4.7.x releases
  • A few people stepped up to lead a future 4.7.x releases, a great way to get involved in the release process. If you’re interested in leading a future minor release, ping @samuelsidler anytime.
  • For 4.7.2, we haven’t set a schedule yet, but we’ll be checking tickets and commits in early February to decide if we should release. @jnylen0 will be the release lead.
  • Reminder for those who helped get 4.7.1 out, please check the handbook to see if updates are needed to help @jnylen0 on 4.7.2.
  • @jnylen0: some API stuff I want to get into a potential 4.7.2, but let me know about other tickets you’d like to milestone
  • Outside pressure on MIME issues not as horrific as one might have expected (ticket #39550: Some Non-image files fail to upload after 4.7.1)
  • Potential that since people using special MIME types (which are the most likely to get caught by this bug) are already aware of having to add in custom mimes, adding in the “unbreak” plugin to fix the problem right now isn’t seen as insurmountable.

REST API team update

  • kicking off the new year by defining the scope of our activities, and prioritizing what is most critical to do first
  • @kadamwhite, @jnylen0, @tharsheblows, @kenshino, & others working on expanding the documentation
  • As we’ve moved the support for the REST API from the “WP-API” github repo, we’re seeing a few repeat questions that can be clarified with better docs & docs organization
  • Today we finished grouping existing docs from the old wp-api.org site into “Using” and “extending” buckets, which are reflected in the left nav; next up, we’ll be adding more docs for using the basics of what’s there
  • @rmccue leading the technical investigations into what to prioritize from an implementation standpoint (see: January 9th 4.8 kickoff meeting notes)
  • a lot that could be converted to use the API within WP-Admin, but change for the sake of change has never been a core value of this project
  • Whereas for something like list table actions, there’s a lot of inconsistency within the admin and converting some of those areas of functionality to use the REST API endpoints would be a clear win
  • We’re using a Trello board to track the areas of investigation
  • the Multisite and BuddyPress teams are both investigating how best to improve or create API endpoints tailored to those use cases
  • @flixos90 did an excellent writeup of our users endpoint discussion
  • We are sorting out how user and site membership management and display should work for the users endpoint.
  • master ticket #39544: REST API: Improve users endpoint in multisite
  • the REST API team intends to continue using the feature projects model to structure proposed API enhancements (such as menu support), with the added requirements of starting from a design document, and checking in with a core committer for periodic review to avoid the feature project from becoming silo’d
  • Multi-site is the first such feature project that’s officially under way.
  • For 4.7.2 we should be looking for related bugs around the existing functionality
  • @jnylen0: propose that we continually evaluate test and documentation coverage for new additions, as an excellent way to find bugs before they ship and we are stuck with them
  • Regarding bugs, to all: when (not if) you find a documentation issue or omission, or find an area where the API does not behave as expected, you are all welcome in #core-restapi at any time and we welcome the feedback.
  • We’re glad to see that the support questions so far tend to fall in a few specific buckets, but this is a new thing and the more eyes on it, the more likely that we’ll be able to identify the key areas where improvement will really drive admin or customizer improvements.
  • REST API team meeting is weekly at Monday 14:00 UTC in #core-restapi, and we welcome one and all to come chime in about how you’d like to see this used

Customizer team update

  • Please read and contribute to the discussion happening on the “What makes a great customization experience?” post
  • Also recommend reading through the meeting that happened earlier today in #core-editor. There’s going to be a lot of overlap, especially as the editor team starts working on content blocks. Lots of discussions have been happening there and in #core-customize related to what we focus on for customizer in the immediate term.
  • We’re identifying some smaller, quick wins we can do to improve the customization experience while content blocks are being built.
  • Update coming on Make/Core soon for more ways to get involved and a separate post from @karmatosed on Make/Design for some ways to help us test the existing customization flow
  • Customize team meeting is weekly at Monday 17:00 UTC in #core-customize, please do join us for general brainstorming and ticket triage (see also: prior meeting notes)

Editor team update

  • Please read and comment on the “Editor Technical Overview” post
  • Recap of #core-editor meeting on a target of a prototype plugin for exploring these concepts from @matveb: Yes, target could be:
    • Data structure.
    • Parsing mechanism.
    • General UI for block display / controls.

Trac Ticket(s)

  • #39535: Canonical redirects disallow tag named comments
    • @asalce: looking to get owner on the ticket and review of patch
    • will ping @markjaquith or @dd32 as maintainers of Canonical component

#4-7, #4-7-2, #dev-chat, #summary

Week in Core, January 11th – 17th, 2017

Welcome back the latest issue of Week in Core, covering changes [39759-39923]. Here are the highlights:

  • 165 commits
  • 44 contributors
  • 87 tickets created
  • 9 tickets reopened
  • 83 tickets closed

Ticket numbers based on trac timeline for the period above. The following is a summary of commits, organized by component.

Code Changes

Administration

  • List Tables: Pass the $which parameter to restrict_manage_posts filter instance in WP_Media_List_Table, missed in [37422]. [39917] #38772
  • Improve tab character width in Plugins and Themes editor. [39897] #38684

Build/Test Tools

  • Add assertNotFalse() method to WP_UnitTestCase and use it where appropriate. [39919] #39219
  • Correctly reference function names in @covers entries. [39918] #39235
  • After [29858], update .jsintrc to use spaces, not tabs. [39898] #39359

Bundled Theme

  • Twenty Seventeen: Remove duplicate global $post declaration in twentyseventeen_front_page_section(). [39909] #39590
  • Twenty Seventeen: Correct @param entries for twentyseventeen_custom_colors_css filter. [39901] #39575
  • Twenty Seventeen: Remove extra asterisk from a translator comment so the comment could be parsed correctly. [39894] #39116

Cache API

  • Docs: Add missing @param type for wp_cache_get_last_changed(). [39900] #39571

Database

  • dbDelta: Ignore index subparts when checking for duplicate indices. [39921] #34870

Editor

External Libraries

Formatting

  • Tests: wpautop() should not add extra before. [39914] #39307
  • Fix wpautop() to stop adding paragraph tags around “. [39912] #39307

I18N

  • Move “Site Language” setting above “Timezone”. [39885] #38562

Media

  • Use a consistent error message for file type errors on uploading. [39891] #33242

Misc

  • Post-4.7.1 version bump for 4.7 branch. [39883]
  • Only show major version in readme.html for 4.7 branch [39871]
  • Media: Fix exif_imagetype check in wp_get_image_mime [39851-39861]
  • Tests: Replace broken codeispoetry.png file. [39848-39849]
  • Use plural string ‘Maintenance and Security Releases’ since we have two now [39847]
  • REST API: Change which users are shown in the users endpoint. [39844]
  • Media: Improve image filetype checking. [39832-39842]
  • Updates: Translate plugin data on the Updates screen. [39808]
  • Themes: Fix markup for theme name fallbacks. [39807]
  • Multisite: Use wp_rand() in signup key creation. [39795-39806]
  • Mail: Disable wp-mail.php when mailserver_url is mail.example.com. [39772-39782][39784]

Plugins

  • Docs: Use a consistent description for $plugin parameter in various plugin API functions. [39890] #36333
  • Docs: Improve the DocBlock for validate_plugin(). [39889] #36333

Posts, Post Types

  • Increase the height of post slug input to prevent certain characters from being cut in Firefox on Windows. [39905] #28084

REST API

Taxonomy

  • Docs: In wp_set_object_terms(), add a note that passing an empty value as $terms argument will remove all related terms. [39893] #36690

Text Changes

  • Taxonomy: Add an explanation for “Parent” dropdown for hierarchical custom taxonomies. [39895] #23447

Themes

  • Add a unit test for get_theme_feature_list() to make sure that the list of theme features pulled from the WordPress.org API returns the expected data structure. [39906] #28121
  • Docs: After [37083], change “HEX format” to “3- or 6-digit hexadecimal form” for clarity. [39888] #36336
  • Use curly braces for variables inside strings in `get_page_template() to explicitly specify the end of the variable name. [39884] #38625

TinyMCE

  • Strip browser inserted <u> and <font> tags from inside links when copying and pasting in IE and Edge. [39916] #39570
  • Ensure the inline toolbar is shown and properly positioned when there are several wpview blocks in the editor and the user selects one after the other. [39910] #38849
  • Prevent the inline toolbar from appearing on partially selected wpview nodes. This can happen when HTML is initially loaded in the editor and wpview is the first node, or sometimes on repeatedly pasting the same wpview. [39904] #38849
  • When inserting a wpview, place the caret after is so the user can continue typing without interruption. [39903] #39337
  • Improve removal of spaces from empty paragraphs when loading HTML in the editor. [39902] #39437

Upload

Users

  • Introduce signup_site_meta and signup_user_meta for filtering signup metadata in wpmu_signup_blog() and wpmu_signup_user(), respectively. [39920] #39223
  • User Query: Cast $user_total as an int. [39915] #39297
  • I18N: Reference correct placeholder in a translator comment added in [30333]. [39908] #30264
  • Display the name of user being edited on Edit User screen. [39907] #28182
  • Docs: Make $meta parameter description in multisite signup and registration functions more consistent. [39887] #38781
  • In wpmu_signup_blog() and wpmu_signup_user(), pass unserialized signup meta data to after_signup_site and after_signup_user filters introduced in [34112], to match the documented value. [39886] #38781

Widgets

  • In unregister_sidebar(), rename the $name parameter to $sidebar_id for consistency with is_registered_sidebar(). [39892] #35147
  • Add nonce for widget accessibility mode. [39760-39771] #23328

Thanks to @aaroncampbell, @afercia, @afzalmultani, @Ankit K Gupta, @azaozz, @barryceelen, @ccprog, @dd32, @diddledan, @DrewAPicture, @dspilka, @F J Kaiser, @gitlost, @iandunn, @iseulde, @ixkaito, @jackreichert, @jblz, @jeremyfelt, @jnylen0, @joemcgill, @johnjamesjacoby, @kuck1u, @MaximeCulea, @Mista-Flo, @netweb, @ocean90, @pavelevap, @pbearne, @pento, @peterwilsoncc, @Presskopp, @rachelbaker, @raggedrobins, @rmccue, @runciters, @seanchayes, @SergeyBiryukov, @Soean, @swissspidy, @theMikeD, @tmatsuur, @vortfu, and @wpsmith for their contributions!

#4-8, #week-in-core

Dev Chat Agenda for January 18th (4.7.2 week 1)

This is the agenda for the weekly dev meeting on January 18, 2017 at 15:00 CST:

If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

#4-7, #4-7-2, #agenda, #dev-chat