Planet Plone - Where Developers And Integrators Write

Configuring the ufw firewall to allow Cloudflare IP addresses

Posted by T. Kim Nguyen on January 03, 2018 01:56 AM

I have a Linode running Ubuntu 16.04, and I use the ufw firewall.

I have a web site running on that server, originally accessible via HTTPS on port 443 from anywhere on the internet.

The domain for that web site is managed via Cloudflare. I want the site to be available only through the domain, and not via the Linode's IP address.

Cloudflare publishes the IP addresses it uses to access your web site: https://www.cloudflare.com/ips/

Here is a page describing the overall idea of using ufw to allow access to your web site only from those Cloudflare IP addresses: https://www.ajsalkeld.com/blog/tutorial/2016/08/01/how-to-use-ufw-to-whitelist-cloudflare-ips-ubuntu-debian-digitalocean/

In this repo https://github.com/Paul-Reed/cloudflare-ufw there is a script that does this: https://github.com/Paul-Reed/cloudflare-ufw/blob/master/cloudflare-ufw.sh

I modified it a bit so that:

it uses the /tmp directory
it uses a unique filename (containing the current process ID) when retrieving the Cloudflare IP addresses
it specifically allows connections only on port 443 (you may want to allow connections on port 80 as well or instead)
it just outputs to the screen the commands that it would issue using ufw; If the commands look sane/good to you, copy and paste them into your terminal to run them

Here is my script:

#!/bin/sh
cd /tmp
wget https://www.cloudflare.com/ips-v4 -O ips-v4-$$.tmp
wget https://www.cloudflare.com/ips-v6 -O ips-v6-$$.tmp

for cfip in `cat ips-v4-$$.tmp`; do echo "ufw allow from $cfip to any port 443 proto tcp"; done
for cfip in `cat ips-v6-$$.tmp`; do echo "ufw allow from $cfip to any port 443 proto tcp"; done

Once I ran the script and copied and pasted its output into a terminal, ufw was configured as follows:

# ufw status numbered
Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22                         ALLOW IN    Anywhere
[ 2] 443/tcp                    ALLOW IN    103.21.244.0/22
[ 3] 443/tcp                    ALLOW IN    103.22.200.0/22
[ 4] 443/tcp                    ALLOW IN    103.31.4.0/22
[ 5] 443/tcp                    ALLOW IN    104.16.0.0/12
[ 6] 443/tcp                    ALLOW IN    108.162.192.0/18
[ 7] 443/tcp                    ALLOW IN    131.0.72.0/22
[ 8] 443/tcp                    ALLOW IN    141.101.64.0/18
[ 9] 443/tcp                    ALLOW IN    162.158.0.0/15
[10] 443/tcp                    ALLOW IN    172.64.0.0/13
[11] 443/tcp                    ALLOW IN    173.245.48.0/20
[12] 443/tcp                    ALLOW IN    188.114.96.0/20
[13] 443/tcp                    ALLOW IN    190.93.240.0/20
[14] 443/tcp                    ALLOW IN    197.234.240.0/22
[15] 443/tcp                    ALLOW IN    198.41.128.0/17
[16] 22 (v6)                    ALLOW IN    Anywhere (v6)
[17] 443/tcp                    ALLOW IN    2400:cb00::/32
[18] 443/tcp                    ALLOW IN    2405:8100::/32
[19] 443/tcp                    ALLOW IN    2405:b500::/32
[20] 443/tcp                    ALLOW IN    2606:4700::/32
[21] 443/tcp                    ALLOW IN    2803:f800::/32
[22] 443/tcp                    ALLOW IN    2c0f:f248::/32
[23] 443/tcp                    ALLOW IN    2a06:98c0::/29

I tested by browsing to my web site's domain (e.g. https://mysite.com) and it worked. Then I tried to browse to my server's IP address (e.g. https://123.45.67.89) and it did not work, as expected and as intended.

Update: January 3, 2018: Thank you to Florian Schulze who suggested the use of Cloudflare's authenticated origin pulls, described at https://support.cloudflare.com/hc/en-us/articles/204494148-Setting-up-NGINX-to-use-TLS-Authenticated-Origin-Pulls. With this method, you don't have to worry that Cloudflare may have changed its IP addresses (the reason why you would need to update your ufw rules periodically).

There is also TLS client side authentication, a feature described at https://support.cloudflare.com/hc/en-us/articles/115000088491-Cloudflare-TLS-Client-Auth. It is, however, available only to Enterprise Cloudflare customers.

Continuous Performance Analysis with Lighthouse and Jenkins

Posted by kitconcept GmbH on December 22, 2017 06:11 AM

Lighthouse is an open-source, automated tool for improving the quality of web pages by Google. It measures the performance of a website and provides metrics for accessibility, best practices for modern web apps, search engine optimization, and assess web applications for adherence to Progressive Web App standards.

Lighthouse Logo

Together with WebPageTest and Google Page Speed Insights it is an indispensable tool to optimize your website performance.

Installation

Lighthouse can be installed in any JavaScript-based project by just running ‘npm install’:

$ npm install lighthouse -g

If you don’t have a package.json in your project, just install npm and run ‘npm init’ before installing.

Running Lighthouse

You can check the performance of any website by calling the ‘lighthouse’ command with the URL of the website you want to test. Append the --view parameter to show the HTML report, right after the command has finished:

$ lighthouse https://kitconcept.com --view

The report will give you five different ratings about PWA, performance, accessibility, performance best practices, and SEO.

Lighthouse Results

Continuous Performance Measurements

If you run your performance test every now and then, you always risk to hurt your website performance without noticing. If a performance regression happens unnoticed, it is usually very hard and time consuming to figure out which change caused the performance regression.

You can easily fix this and save lots of time when you run your performance tests and analysis continuously.

Unfortunately Lighthouse does not allow you to set performance test specifications that your CI system can test against, like WebPageTest or Google Page Speed Insights do (we will cover those tools in later blog posts). Though, it is still very convenient to run the performance test on a regular basis for each commit and include them into your CI report.

Install Lighthouse locally for CI

When it comes to a Continuous Integration, a local installation is prefered over a global one, which is usually harder to manage and to maintain. Especially if you have multiple projects with different sets of package versions on your CI.

Therefore we install Lighthouse locally in our project directory:

$ npm install lighthouse --save-dev

This command will install Lighthouse to your local package.json file. We recommend to use yarn or npm package-lock.json to lock down the package version you are using for a repeatable and stable project build.

For convenience, we add a “lighthouse” script to our package.json:

"scripts": {
  "lighthouse:ci": "node_modules/lighthouse/lighthouse-cli/index.js \
  --output-path=./lighthouse-report.html --quiet \
  --chrome-flags='--headless' https://kitconcept.com"
}

We call the locally installed lighthouse binary and set a static output path (by default, Lighthouse creates a file with the current date/time in the filename which makes it harder to publish on your CI).

We also include the --quiet option and run it on headless chrome, so we don’t need to install and run an X server on our CI system.

At the end, we hard-code our project URL into the command so we do not have to type it manually each time we run this command.

Now we can just run:

$ npm run lighthouse:ci

and it will create a nice HTML report that we can publish in our CI.

Configure Lighthouse for your local development environment

For convenience, we also add a command that you can run locally:

"scripts": {
  "lighthouse": "node_modules/lighthouse/lighthouse-cli/index.js \
  --output-path=./lighthouse-report.html --quiet \
  --chrome-flags='--headless' https://kitconcept.com/blog"
}

The --view parameter will fire up a browser with the report at the end of the performance analysis. This is something we clearly don’t want on our CI system.

Publish Lighthouse Reports in Jenkins CI

Travis and other lightweight CI system usually lack the option to publish any reports except the command line output. Though, if you are using Jenkins CI, you can use the HTML publisher plugin to publish your Lighthouse report.

sh 'npm install'
sh 'npm run lighthouse'
publishHTML (target: [
  allowMissing: false,
  alwaysLinkToLastBuild: false,
  keepAll: true,
  reportDir: '.',
  reportFiles: 'lighthouse-report.html',
  reportName: "Lighthouse"
])

After adding publishHTML to your Jenkins pipeline, you will see a “Lighthouse” link under the ‘Artifacts’ tab:

Link to Lighthouse report in Jenkins

There is a caveat though. Jenkins 1.641 / 1652.3 introduce the Content-Security-Policy header to static files served by Jenkins. The default header is set to a very restrictive set of permissions to protect Jenkins users from malicious HTML/JS files in workspaces.

To allow Jenkins to display the Lighthouse reports, we have to add the following JAVA_ARGS to the Jenkins startup (for instance by adding the following line to your /etc/default/jenkins file):

JAVA_ARGS="-Dhudson.model.DirectoryBrowserSupport.CSP=\"sandbox
allow-scripts; default-src 'unsafe-inline'; img-src * data:\""

For more details see the Content Security Policy Reference and the Jenkins docs on configuring Content Security Policy.

After you fixed the Content Security Policy of your Jenkins you will see the full report when clicking on the ‘Lighthouse’ link on the ‘Artifacts’ tab on your Jenkins build:

Lighthouse Report in Jenkins

Jenkins Declarative Pipeline Stage for Performance Tests

A full declarative pipeline stage for lighthouse looks like this:

stage('Performance Tests') {
  agent {
    label 'master'
  }
  when {
    branch 'master'
  }
  steps {
    deleteDir()
    checkout scm
    sh 'npm install'
    sh 'npm run lighthouse'
  }
  post {
    always {
      publishHTML (target: [
        allowMissing: false,
        alwaysLinkToLastBuild: false,
        keepAll: true,
        reportDir: '.',
        reportFiles: 'lighthouse-report.html',
        reportName: "Lighthouse"
      ])
    }
  }
}

We run the performance test stage on ‘master’ agents and only on the master branch. The steps performed are a simple “npm install” to set up the project build and then we run ‘npm run lighthouse’ to produce the HTML report. If you already have an npm build from a previous step you can of course just unstash the build artifact.

Jenkins pipeline with Lighthouse performance tests stage

Summary

Lighthouse is a valuable and indispensable tool if you want to deliver a fast and user friendly website. Running the analysis on a continuous basis on your CI is a good idea if you take performance seriously. Setting it up is fast and easy. Maybe in the future Lighthouse will also provide a testspec feature that will allow us to fail a CI build (or mark it as unstable) on performance regressions. Though, if you run WebPageTest or Google Page Speed Insights additionally, this is not really needed.

Jazkarta Sponsors Northwest Youth Leadership Summit

Posted by Jazkarta Blog on December 07, 2017 08:21 PM

NWYLS Group Shot

Jazkarta is pleased to have recently sponsored the North Cascades Institute‘s Northwest Youth Leadership Summit. This event is intended to empower Cascadia’s future leaders in conservation by:

Enhancing their skills in preparation for job and college applications
Connecting with regional environmental organizations and businesses to learn about jobs and internships
Learning from like-minded peers about career options available in the conservation, outdoor and environmental fields

More than 220 students participated and are now better equipped to take action towards conservation. The Summit was free to all participants to ensure that underrepresented youth are given opportunities to get involved in the outdoor and environmental fields.

The sponsorship added another dimension to our existing partnership with North Cascades Institute. Just before the summit, we had given the non-profit’s Plone+Salesforce website a mobile refresh to make it work smoothly on phones and tablets. If we say so ourselves, the results are quite beautiful. Kudos to Neal Maher for the designs and to the Jazkarta team (Christine Winckler and David Glick) for a smooth implementation.

North Cascades Institute is not the only environmental non-profit organization that Jazkarta is working with – we created The Mountaineers‘s website and the Washington Trails Association ‘s volunteer management system. Both organizations were involved in the Summit. It was hosted at The Mountaineers’ Seattle Program Center, here is one of the students using the climbing wall.

NWYLS Student on The Mountaineers Climing Wall

Andrew Pringle of the Washington Trails Association led a breakout session titled “Trip Planning 101: An Introduction to Leading Backcountry Adventures”, and both organizations ran booths, talking with participants about activities, internships and employment options for young outdoor leaders. Here’s Andrew at the WTA booth.

WTA's Andrew Pringle at the NWYLS

We feel very lucky to be helping all of these organizations further their missions.

— Photos by North Cascades Institute staff

Tagged: conservation, environment, north cascades institute, pacific northwest, sponsorship, the mountaineers, wta, youth

20171128

Posted by PLONE.ORG on November 28, 2017 12:00 AM

Several XSS and redirect fixes, and a sandbox escape fix.

Security patch released 20171128

Posted by PLONE.ORG on November 28, 2017 12:00 AM

This is a routine patch with our standard 14 day notice period. There is no evidence that the issues fixed here are being used against any sites.

CVE numbers not yet issued.

Versions Affected: All supported Plone versions (4.x, 5.x). Previous versions could be affected but have not been tested.

Versions Not Affected: None.

Nature of vulnerability: Low severity, no data exposure or privilege escalation for anonymous users.

The patch was released at 2017-11-28 15:00 UTC.

Installation

Full installation instructions are available on the HotFix release page.

Standard security advice

Make sure that the Zope/Plone service is running with minimum privileges. Ideally, the Zope and ZEO services should be able to write only to log and data directories. Plone sites installed through our installers already do this.
Use an intrusion detection system that monitors key system resources for unauthorized changes.
Monitor your Zope, reverse-proxy request and system logs for unusual activity.
Make sure your administrator stays up to date, by following the special low-volume Plone Security Announcements list via email, RSS and/or Twitter

These are standard precautions that should be employed on any production system, and are not tied to this fix.

Extra Help

If you do not have in-house server administrators or a service agreement for supporting your website, you can find consulting companies at plone.com/providers

There is also free support available online via the Plone forum and the Plone chat channels.

Q: When will the patch be made available?A: The Plone Security Team will release the patch at 2017-11-28 15:00 UTC.

Q. What will be involved in applying the patch?A. Patches are made available as tarball-style archives that may be unpacked into the products folder of a buildout installation and as Python packages that may be installed by editing a buildout configuration file and running buildout. Patching is generally easy and quick to accomplish.

Q: How were these vulnerabilities found?A: The vulnerabilities were found by users submitting them to the security mailing list.

Q: My site is highly visible and mission-critical. I hear the patch has already been developed. Can I get the fix before the release date? A: No. The patch will be made available to all administrators at the same time. There are no exceptions.

Q: If the patch has been developed already, why isn't it made available to the public now? A: The Security Team is still testing the patch against a wide variety of configurations and running various scenarios thoroughly. The team is also making sure everybody has appropriate time to plan to patch their Plone installation(s). Some consultancy organizations have hundreds of sites to patch and need the extra time to coordinate their efforts with their clients.

Q: How does one exploit the vulnerability?A: This information will not be made public until after the patch is made available.

Q: Is my Plone site at risk for this vulnerability? How do I know if my site has been exploited? How can I confirm that the hotfix is installed correctly and my site is protected?

A: Details about the vulnerability will be revealed at the same time as the patch.

Q: How can I report other potential security vulnerabilities?

A: Please email the Plone Security Team at security@plone.org rather than publicly discussing potential security issues.

Q: How can I apply the patch without affecting my users?

A: Even though this patch does NOT require you to run buildout, you can run buildout without affecting your users. You can restart a multi-client Plone install without affecting your users; see http://docs.plone.org/manage/deploying/processes.html

Q: How do I get help patching my site?

A: Plone service providers are listed at plone.com/providers There is also free support available online via the Plone forum and the Plone chat channels

Q: Who is on the Plone Security Team and how is it funded?

A: The Plone Security Team is made up of volunteers who are experienced developers familiar with the Plone code base and with security exploits. The Plone Security Team is not funded; members and/or their employers have volunteered their time in the interests of the greater Plone community.

Q: How can I help the Plone Security Team?

A: The Plone Security Team is looking for help from security-minded developers and testers. Volunteers must be known to the Security Team and have been part of the Plone community for some time. To help the Security Team financially, your donations are most welcome at http://plone.org/sponsors

General questions about this announcement, Plone patching procedures, and availability of support may be addressed to the Plone support forums If you have specific questions about this vulnerability or its handling, contact the Plone Security Team at security@plone.org

To report potentially security-related issues, email the Plone Security Team at security@plone.org We are always happy to credit individuals and companies who make responsible disclosures.

Information for Vulnerability Database Maintainers

We will apply for CVE numbers for these issues. Further information on individual vulnerabilities (including CVSS scores, CWE identifiers and summaries) will be available at the full vulnerability list.

fail2ban configuration error fix

Posted by T. Kim Nguyen on November 26, 2017 04:09 PM

If you have this in your /etc/fail2ban/jail.local configuration file:

# "bantime" is the number of seconds that a host is banned.
bantime = 31536000 # 1 year

# A host is banned if it has generated "maxretry" during the last "findtime"
# seconds.
findtime = 604800 # 7 days

and you get these errors when you restart fail2ban (service fail2ban restart):

WARNING Wrong value for 'findtime' in 'ssh'. Using default one: '600'
WARNING Wrong value for 'bantime' in 'ssh'. Using default one: '600'

change it to this (put the comment on a separate line):

# "bantime" is the number of seconds that a host is banned.
# 1 year
bantime = 31536000

# A host is banned if it has generated "maxretry" during the last "findtime"
# seconds.
# 7 days
findtime = 604800

This is explained in the following bug report:

fail2ban: Incorrect parsing of commented text after reading a value from config file

If you want to set a permanent ban time, use a negative number.

# "bantime" is the number of seconds that a host is banned.
# permanent ban
bantime = -1

DDjpOUXXoAUDFIH.jpg

Posted by T. Kim Nguyen on November 25, 2017 06:52 PM

Pastanaga Sprint Bonn 2017

Posted by kitconcept GmbH on November 23, 2017 05:02 PM

Pastanaga is a new user experience framework for the web, designed by Albert Casado.

Pastanaga was first presented in March 2017, at the Plone Open Garden in Sorrento. In July, we started with an initial implementation during the Midsummer Sprint in Jyväskylä, Finnland.

Pastanaga was also present at the recently held Plone Conference in Barcelona, where Albert gave a presentation on it. In addition, Eric Steele, the Plone release manager, gave us the opportunity to present Pastanaga to the audience during his keynote on the first day of the conference.

With all the positive feedback and energy we took from the Plone Conference, we wanted to push things further and we just couldn’t wait until our “Beethoven Sprint”, which is planned for early 2018. Therefore we decided to organize a small and focused sprint at our office in Bonn to work on the implementation of Pastanaga.

The Pastanaga Minimal Viable Product

As an Open Source community (and software engineers) with many years of experience in designing and building complex Content Management System applications, we sometimes have the tendency to try to solve all problems at once.

Over the years we encountered and solved many complex problems and when we build something new, this can be both a source of wisdom as well as a baggage that you carry around.

This sometimes led to a situation where we were over-engineering solutions, to solve all the problems that we encountered over the years at once. Enhancements sometimes stayed around for years without really becoming production ready and usable in real-world projects.

To avoid this from happening when working on implementing Pastanaga, we decided in Jyväskylä to focus on a Minimal Viable Product.

A Minimum Viable Product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development. The Pastanaga MVP needs to provide what we consider the essentials of a Content Management System:

A site administrator can and add, edit, and delete a page
A user can view the created pages and navigate the site structure

In order to be usable for public facing website projects, we added two additional technical requirements:

The page should be fully rendered within 500 milliseconds
Google should be able to crawl the contents of the website

Those requirements might sound very simple, but they are actually not.

Pastanaga aims to leverage the editing experience and reduce the complexity that we took for granted over the years. We aim to simplify the user experience for the editors by getting rid of things that we got used to. For instance, adding an image to a page should be as simple as just dragging and dropping an image to the page and Plone will take care about the heavy lifting of automatically uploading and resizing the image.

You can find a list of all the user stories that we plan to implement as part of the MVP here:

https://github.com/plone/pastanaga#minimal-viable-product

Having the goals and scope for this set the only thing that was needed was a bunch of Plone devs and three days and nights of coding.

Sprint Day One

After the sprinters arrived, we started with our sprint planning session. We decided to focus on the implementation of the Pastanaga MVP and work on the other issues (e.g. plone.restapi) only if we need them for the MVP.

.@robgietema giving us an introduction to plone-react. #plone #sprint pic.twitter.com/Ga6Bsd3l2J
— kitconcept (@kitconcept_gmbh) November 15, 2017

After the planning meeting, Rob gave us an introduction to plone-react, a ReactJS-based implementation of the Plone UI that he and Roel worked on over the past months and that we decided to use as a basis for our MVP.

Pastanaga sprint planning meeting at our office in Bonn. #plone #Sprint pic.twitter.com/FDpjv5wx5t
— kitconcept (@kitconcept_gmbh) November 15, 2017

We went through all components, reducers, bells and whistles of the application and discussed best practices, developer environments and developer approachability.

After that session, Rob and Victor started with the implementation of Pastanaga. Davi created a pull request that adds an uninstall profile for plone.restapi and started to learn about React. Roel started to look into a way to turn the Plone site root into a Dexterity object, something that we would need to simplify the Plone editing experience. I worked on the basic Robot Framework acceptance test setup and updated the contents of the Pastanaga github repository, which is supposed to be just an entry point for all our initiatives around Pastanaga:

https://github.com/plone/pastanaga

Day Two

On the second day, Victor finished the login form and made the error messages work.

Rob implemented the document edit accordion menu, fixed the button styling, made plone-react use the Pastanaga icons and started to work on the toolbar.

Davi added a search widget to the header, implemented the breadcrumbs navigation and added styles for the document heading and description.

Right before the wrap-up meeting of day two, Roel showed us a Plone site with a “containerish” Dexterity-based site root. We did not really expect that much progress and went to bed (some of us a lot later) still very impressed by his accomplishment.

Day Three

On day three, Rob started to work on the new Pastanaga document edit view. He made the new edit view to show multiple content items (e.g text, image, video) and allowed to change the order of those content items via drag and drop.

Davi continued to work on the header and breadcrumbs styling. Victor looked into the mobile views of our responsive design, fixed some issues with the status messages and briefly started to look into GatsbyJS (which we plan to use to implement pastanaga.io).

Summary

After three days (and nights) of hacking, we had:

A fully functional login form with error messages and password forgotten functionality:

A fully functional Pastanaga Toolbar that can be collapsed or expanded. With all the menu items present and the personal toolbar functionality available:

A view to add and edit pages with all the existing functionality:

In three sprint days, we accomplished our main goals and were able to create the first iteration of a Minimal Viable Product that we can use to build things upon. We plan to continue to work on this, use it in our current and upcoming projects, and of course: contribute back as much as we can.

Stay tuned for more updates on this soon!

Successful Google Summer of Code 2017

Posted by PLONE.ORG on November 16, 2017 05:47 PM

Google Summer of Code ("GSoC") is an annual international program open to university students in which Google awards stipends to all students who successfully complete a free and open-source software project.

The Plone community is proud to announce four successful projects were completed for GSoC 2017.

Oshane Bailey (theme editor improvements presentation, GSoC project)
Mikko Hursti (Mosaic listing customization improvements GSoC project)
K C Pavithira Reddy (plone.org improvements GSoC project)
Noel Varghese (Plone progressive web application presentation / JavaScript client, GSoC project)

All five GSoC students were offered sponsorship by the Plone Foundation to travel to Barcelona for the Plone Digital Experience 2017 conference. Oshane, Mikko, Noel, and Shriyansh Agrawal (content import and export) were able to attend and present their work to enthusiastic audiences.

Cris Ewing was our new-for-2017 coordinator of the Plone community's GSoC involvement. The Plone Foundation Board expresses its gratitude to him on behalf of the entire Plone community for having managed this very important project.

We also truly appreciate the time and effort of our GSoC students and their mentors in continuing to move Plone forward.

On to 2018, for which we have already begun soliciting project ideas!

Plone Foundation Officers 2017-2018

Posted by PLONE.ORG on November 15, 2017 08:25 PM

All seven Plone Foundation Board members' nominations were accepted at the Annual General Meeting held in Barcelona on October 20, 2017:

Paul Roeland
Alexander Loechel
Carol Ganz
Chrissy Wainwright
Víctor Fernández de Alba
Philip Bauer
T. Kim Nguyen

At the first Board meeting of the new term on November 2, 2017, the officers of the Foundation were voted in. The officers are elected annually:

President: Paul Roeland
Vice President: Alexander Loechel
Secretary: Chrissy Wainwright
Treasurer (non-voting): Jen Myers

Apart from these official Foundation roles, there are further roles and tasks that the Board attends to:

Marketing lead: T. Kim Nguyen
Framework team liaison: Philip Bauer
Security team liaison & Higher Education liaison: Alexander Loechel
Communications/Marketing team lead: T. Kim Nguyen
Front End team lead: Víctor Fernández de Alba
Foundation Membership committee co-chairs: Érico Andrei, T. Kim Nguyen

For more information on the Plone Foundation or its board, visit plone.org/foundation, or drop an e-mail to board@plone.org.

Plone is an open source web content management system excelling in usability, accessibility, and versatility. The Plone Foundation is a US 501(c)3 tax-exempt organization that protects and promotes Plone.

Thank you, Barcelona!

Posted by PLONE.ORG on November 15, 2017 06:02 PM

The Plone Digital Experience Conference 2017 in Barcelona was an exhilarating success, bringing together the Plone, Python web, and modern JavaScript front end communities in the beautiful city of Barcelona.

Some statistics:

10 training classes
6 keynotes
52 presentations
180 attendees from 21 countries
2 organizing companies, 18 sponsors, 4 partners
70 sprinters
4 Google of Summer of Code 2017 students
1 truly memorable conference dinner
1 official Plone band
dozens of volunteers

Some artifacts:

Speakers' slides can be found for almost all the presentations (video recordings still to come).
Photos of the conference
Tweets during the conference

On behalf of the Plone community, thank you 2017 organizing team!

Victor Fernandez de Alba
Ramon Navarro Bosch
Agata Avalo
Albert Casado
Timo Stollenwerk
Philip Bauer
Paul Roeland
Kim Nguyen
Sally Kleinfeldt
Mikel Larreategi
Eric Bréhault

Security vulnerability pre-announcement: 20171128

Posted by PLONE.ORG on November 10, 2017 04:30 PM

This is a routine patch with our standard 14 day notice period. There is no evidence that the issues fixed here are being used against any sites.

CVE numbers not yet issued.

Versions Affected: All supported Plone versions (4.x, 5.x). Previous versions could be affected but have not been tested.

Versions Not Affected: None.

Nature of vulnerability: Low severity, no data exposure or privilege escalation for anonymous users.

The patch will be released at 2017-11-28 15:00 UTC.

Preparation

This is a pre-announcement of availability of this security fix.

The security fix egg will be named Products.PloneHotfix20171128 and its version will be 1.0. Further installation instructions will be made available when the fix is released.

Standard security advice

Make sure that the Zope/Plone service is running with minimum privileges. Ideally, the Zope and ZEO services should be able to write only to log and data directories. Plone sites installed through our installers already do this.
Use an intrusion detection system that monitors key system resources for unauthorized changes.
Monitor your Zope, reverse-proxy request and system logs for unusual activity.
Make sure your administrator stays up to date, by following the special low-volume Plone Security Announcements list via email, RSS and/or Twitter

These are standard precautions that should be employed on any production system, and are not tied to this fix.

Extra Help

Should you not have in-house server administrators or a service agreement for supporting your website, you can find consulting companies at plone.com/providers