Our company PretaGov did an accreditation process. We have lots of government contracts, so this got important. It is a self assessment process.

What I want to do in this talk is talk about holistic security, the kinds of things we needed to do for the accreditation.

Organisational security

How do you manage your secrets? High quality, unique passwords. Not written down. We use a password manager across the organisation. This also finds compromised passwords.

Secure your devices: firewalls, antivirus, automatic updates, have a software policy (what software can you install, do you need approval for this), no out of date/legacy software. Last part is tricky when you still need to maintain Plone 4.3 sites. We worked around this by doing it on Docker, so at least our own development machines are not vulnerable.

Cloud/Saas: have an audited list of services, individual accounts where possible, don't give admin access to everybody, close unused accounts, use MFA if possible.

Infrastructure security

Define the scope: understand what you have, for example by creating an image with users, machines, internet boundaries, cloud services, networking equipment.

Secure servers and cloud infrastructure. Control the access to servers. A VPN with two factor can help here. Have a minimum required access. Keep servers up to date, firewall, antivirus where applicable. Backup and disaster recovery system: if your data is encrypted and held ransom, you want to be able to get back a recent version.

Web security

The browser goes to the proxy or load balancer and then your app (Plone). It is 2023, every site must be encrypted with https, this is free with lets encrypt, including auto-renewal.

Think about the Cipher suites. Older suites are insecure to for example the heartbleed or beast attacks. You should use TLSv3. You might need an older version if you need to support older browsers. Check the security with automated tools.

Setup https strict transport security. This tells the browser to remember that this site uses https. This makes the site harder to spoof when an attacker controls the wifi. Check https://hstspreload.org/

Click jacking: tricking users to click somewhere that they did not mean. Can be done with invisible iframes. Prevent this by setting X-Frame-Options header, either DENY or ALLOWORIGIN. Cookies should have the Secure setting so it will not be sent on http and in some cases the httpOnly setting so it can't be read from javascript.

XSS, Cross Site Scripting Attack. Plone protects you from this usually, and the security team looks at this. You can set a Content-Security-Policy header. It can be tricky as it can disable functionality that you rely on. You can set "report-to" to get browsers to send you a report about things it would have blocked, so you can try your policy for a while. Check https://www.uriports.com/

If you see security problems in plone, mail security@plone.org.

Plone security

Change the default admin password. Block access to the ZMI (manage, manage_*), you should normally not need this. Install hotfixes, see https://plone.org/security/hotfixes. Use Python 3. If you really still need Python 2, your OS vender may offer paid support.

Protect logins. collective.PasswordStrengthPlugin, there is a branch for Plone 5/6. collective.googleauthenticator, also here Plone 5/6 support coming. Products.LoginLockout: brute force protection, after some failed logins, block the user for a time. Or block all  users except a few specific ones. pas.plugins.authomatic hands off your authentication to Google or GitHub, etc.

Volto security

Content-Security-Policy gets tricky because Volto sets inline scripts and styles, so this requires "unsafe-inline" in the policy. @plone-collective/volto-csp and volto-middleware-helmet help here, they are coming soon.

CORS, Cross Origin Resource Sharing. A lot of browsers block javascript from accessing other domains. Volto needs to access data from the Plone api, so if you host this api on a different domain, you will need to set headers with Access-Control-Allow-Origin and Credentials. Configure this on the backend. Only use a single origin. You can use *.example.com, but then the Credentials will not be passed.

Security for the build stack. Use cookiecutter-plone-starter for a good base setup. Use dependandabot to warn you about vulnerabilities in packages that you use. Use a CI/CD setup to ease rolling out fixes.

Assorted security

Some more things that are worth doing.

Rate limiting, for example with haproxy, to prevent someone hammering your site. Fail2Ban, mostly just getting rid of traffic you do not want. See also Fail2Ban.WebExpoits for custom checks.

Email: SPF, DKIM, DMARC.

Feature Policy Header let's you control what javascript features are allowed on your site, for example disable microphone and camera.

With a Referrer Policy Header you can instruct the browser to not send a Referer header to the next site.

Audience:

• GSoc project: https://github.com/collective/plone.webauthn
• In Plone 6 you can use per-user keyring.

What do you need for CI, Continuous Integration?

• A correct automatic repeatable setup of your project.
• tests, so you can tell automatically if the project works
• configured up to date servers to run those tests
• testing triggered automatically after a change
• feedback flowing to the developers

Okay, that works, with cookiecutter-plone-starter, plone/meta, Ansible, Docker Swarm, GitHub Actions. Most of them open source.

Continuous Delivery:

• Only when CI is green, no test failures.
• You need servers for this
• a CD orchestrator
• persistent data management, including possibly copy of production to test or development

So you not only need to know 100% of the software code, but all on top, maybe 400% more knowledge. No wonder you are burned out! You need to specialise to get this back to having to know only 100%. I like knowing about a lot of things, but it is hard to maintain over years.

We use GitHub. Not open source, so I asked internally if we really want this, as you never now what will happen with commercial companies. But it is there and we use it. With GitLab you could be more open source, but then you would need to run it yourself preferably.

So code is on GitHub. commit to a branch or main: code analysis is run. When we merge to main in certain directories: automatically deploy to testing. Create a tag release: deploy to live environment.

Other implementations are possible, like chat based: add a comment in a PR to ask the CD to deploy to testing.

There are some organisation and security challenges. GitHub.com/plone is open and writeable for a few hundred people. You don't want all of them to be able to change something in the plone.org repo and automatically deploy it live. We can't be this open anymore. So there are restrictions in place.

If you are a sysadmin and are interested in this stuff, please help us, talk to the AI Team (Admin and Infrastructure).
Would be good to get "devcontainers" up and running.

We have this setup for plone.org now, but also for plone.de, 2023.ploneconf.org, plone.nl.

Another thing that we have setup, is for when there is a new Plone backend or Volto version. We update a few version numbers in the repos for the Docker images, and then they get created, tested, and pushed to Docker.

I work at Tekniker. We research and build modern industrial products for lots of sectors.

My talk is about robotics. What is a robot. You may think of a machine in a factory doing repetetive tasks. Or a human-like robot or insect-like cars moving over uneven terrain.

What can a robot learn? They can learn how to move, understand a scene, interact with humans, collaborate with humans and robots. Learn to manipulate objects. Learn to assemble objects, with kinaesthetic learning (you move the robot arm) or mimic learning (you move your arm, robot mimics you). We coordinate the HARTU project that researches this.

Innovate with an eye to the future, exploiting the intermediate results achieved.

[Sorry, hard to summarise, but cool to watch.]

Luistxo: The eibartarrak, gun toting ruffians

Eibartarrak are the people from Eibar. You probably expected to find some Spanish seaside resorts here, as in the propaganda on the conference site. Still, there is #PrettyEibar. Eibar in 1937: Francist soldiers destroyed the whole town, except for the church. So we had to build it all back. It is in progress. But it's the people that matter. Eibar in 1346 a Castilian king told us to build a town. What is the X that appears all over town? It is Saint Andrew's cross, which also comes back in the flag of Scotland. It is a poor geographical area, nothing grows on the slopes, we live in a hole. From the 15th century on, Eibar was making guns. For the government, not personal use. That was my dad's first job, making guns. If you can make guns, you can make bikes, they are tubes of metal after all. Also creating cork screws, staplers, other household materials. Helmholtz electronics. G93: realtime cycling tracking, comes from Eibar.

And CodeSyntax does Plone, fully i18n-ized thanks to Erral. It's the people that matter.

Reminder: at tonight's party, I am the DJ.

Julien Chandelle (jimbiscuit): shortcut pattern bookmark

Extension for Plone. Add shortcuts / bookmarks. Available on Chrome browser.

https://chrome.google.com/webstore/detail/shortcut-patern-bookmark/fneleejokehnmfkbnjfeahieblhaecho?hl=en-US

https://shortcut-pattern-bookmark.affinitic.be/

Philip Bauer: Plone Tagung 2024

March 4-6 2024, followed by community sprint. In Giessen. Most talks are in German, but happy to have English talks. See https://plonetagung.de/

Eric Steele: Unsung Hero

A person stepped up to fill a vital role for Plone. Largely doing so on their own. Who? There are several of you here. Single points of failure for Plone. We lean heavily on you. It is a Plone community problem. It happens everywhere. Cloning would be great, but two Freds would just debate each other to death. We had the 10% Plone Manifesto, where 10% of the time of Plone companies would be for Plone.

We again have Plone TuneUps. One day a month. You get an education and a warm glow. We need not just coders, also project managers, documentation writers, people who do not know Plone. Send me an email or register, link on plone.org.

David Glick: Ideas I don't have time to build

1. Easier input of smart quotes and EM dashes in Volto.
2. TUS uploads (progressive uploads)
3. Blocks import/export as markdown
4. Editor discussions: discuss revisions to documents.
5. ChatGPT: generative Plone text
6. Editor dashboard: show content that you edited recently, content that has not changed in a while.
7. Don't restrict ids. You can't name something 'image', or give it the name that is used as catalog index.
8. collective.exportimport: separate file for each item
9. docker image with unreleased changes from coredev (Erico: there is a nightly image)
10. consistent command line, whether you use docker or something else

Elisabeth and Martin: iMio and OSOR

iMio is finalist of the OSOR awards: Open Source Observatory of the European Commission. iMio serves 404 local initiatives. Please vote for us.

Erico and Kim: Board election

There is an election for the Plone Foundation board. You still have one hour to nominate yourself.

Foundation members will get an email on how they can vote.

See https://plone.org/foundation/meetings/membership/2023-membership-meeting/call-for-nominations-plone-foundation-board-of-directors-2023-2025

If you don't get voted in, please try again next year. It is not a popularity contest.

Kim: Plone Foundation sponsorship

We have a bunch of sponsors, listed on our sites. I did a poor job of updating the list this year. You can also sponsor individually via GitHub. We pay for all kinds of stuff with this money, like some servers.

We also have a Plone service provider list. We want to open up this list for everyone, without needing to pay anything. Contact us, email me.

Fred: Website Team

We have a Website Team in the Foundation? No, we don't. We have teams involved: AI team, Marketing team, PloneConf team, Release team, Volto team, Release managers, etc. But who actually maintains plone.org: Nobody does. Members from the other teams are standing in. plone.org is not a one-off project: worked on it, shipped it, done. No, it is ongoing.

We need a small pool of available developers to work on this, maybe 4-12 hours a month. I like to give training, but we need some experience on a Website Team first. We need a few hands to maintain this site.

Full CI/CD is already there, so that helps. Talk to me, Rikupekka, Erico.

I have created https://github.com/plone/plone.distribution which will end up in Plone 6.1.

With this you can create your own Plone CMS, or:how integrators use 20 years of collective work as the secret weapon to control a market / segment.

I talked about Plone distributions before. Maurits blogged about my talk. I talked about a distribution of Plone specifically meant for Brasil. And after a while I saw that some organisations were actually using it.

The idea is not new. You have Drupal distributions, Joomla templates, Typo3 distributions. For example CiviCRM is a distribution of Plone.

Plone was never very friendly for distributions. Newer Plone versions would come out that made it hard to upgrade the distribution.

The logic to create a new Plone site is currently distributed:

• browser view in CMFPlone
• content in plone.volto, plone.app.contenttypes
• translations in plone.app.locales

So there is no clear contract. How do you create a new site from Python code? No idea, I would copy some codes There is no RESTAPI service. Without such a service, how would you provide a SAAS for Plone?

Still, there are many examples of "distributions" in our family, for example: Quaive, SENAITE, Bika, Portal Modelo, Vindula, Volto, CastleCMS, io-Comune, Classic UI. Reality check: maybe we are not really selling Plone CMS. Plone CMS should not be targeted at the end user, but at integrators.

We need to define what a Plone Distribution is. It is a contract to create a new instance of a Plone Site. It follows conventions about how to create initial content. It provides a Python API and a RESTAPI. Use cases: starting point for a ne CMS project (website, intranet, headless backend, ...), basis for SAAS offering.

plone.distribution is the package that is the basis for this, the factory. Distributions should be first-class citizens in the Plone world. Convert the initial content from plone.volto and plone.app.contenttypes. Cleanup the codebase. It will sit above Products.CMFPlone, so we can use plone.api in the code to make things easier.

You can use it now as an add-on in Plone 6.0.  In 6.1 it will be a core package.

We are not yet another framework, Plone is a CMS. It is good to concentrate, be specific. But I can say: "Plone is a platform, not a CMS." We have solid foundations: permissions, workflow, basis for content types.

Marketing for Plone: focus on a market and segment, not on the common denominator. For some Plone companies Drupal is a competitor, for others Typo3. Plone marketing should target integrators.

By default you will see two distributions when you start the Plone instance: default (Volto) and ClassicUI. You can add your own, and optionally hide the default ones.

Example distributions:

• collective.ploneintranet
• We have portalbrasil.edu/leg/gov/jus as base for public websites in Brazil.
• kitconcept.voltolighttheme. Allows developers to showcase new blocks.
• A to-be-named distribution for personal site / blog. It is scratching my own itch, for ericof.com, and as additional target Maurits, who is blogging right now.

A distribution is not a "policy package". You do not need to have a GenericSetup profile. You can have complex forms, like with collective.plone.intranet.

Next steps.  How to create a front-page in 45 languages? We should think about that. Should we add features in a distribution package? We need to improve content export/import. It works, but I have questions.

We ship this with 6.1. With 6.2 I want to ship with 6 or 7 distributions. It is a seed we plant for integrators to think about.