I recently learned that Nextcloud 23's new profile feature — basically a
way for users to share personal contact details — has a problematic
default setting, profile data is shared with **everyone** by default.
This means that an unauthenticated user can access personal information
by accessing `nextcloud.tld/u/user.name`.
The announcement of v23 states[1]:
> We go a step further and introduce a profile page. Here you can put a
> description of yourself, show links to, for example, social media, what
> department you are in and information on how to contact you. All these
> are of course entirely optional and you can choose what is visible to who!
> The profile and user status are accessible also from our mobile and desktop clients.
It's not mentioned that by default you share personal information[3] with
everyone and personally I think that's somewhat problematic.
To work around that, I decided to add an option for the recently added[2]
and even set it to `false` by default to make an explicit opt-in for
that feature.
[1] https://nextcloud.com/blog/nextcloud-hub-2-brings-major-overhaul-introducing-nextcloud-office-p2p-backup-and-more/
[2] https://github.com/nextcloud/server/pull/31624/files
[3] By default, this affects the following properties:
* About
* Full name
* Headline
* Organisation
* Profile picture
* Role
* Twitter
* Website
Phone, Address and Email are not affected and only shown to
authenticated users by default.
There is no need to install them when they will not be picked up
by the Appearance panel of GNOME Control Center without
a XML metadata file anyway.
They will be pulled into the closure via overrides
so that is not a concern either.
This reverts commit 7f3bc5b8fa.
This reverts commit fa607bc939.
Without this fix, setting the shellopts in `machine.execute` is
inconsitent. When no timeout is used, shellopts `set -euo pipefail` are
applied to the command as expected. When a timeout is specified, the
shellopts are not applied to the command itself (which is called inside
a `sh -c` that doesn't inherit the shellopts) but rather to the
`timeout` command, leading to the following full command:
```bash
(set -euo pipefail; timeout 900 sh -c 'cmd') | (base64 --wrap 0; echo)\n
```
With this fix, this is the command we get:
```bash
timeout 900 sh -c 'set -euo pipefail; false | true') | (base64 --wrap 0; echo)\n
```
- Clarify that shellopts are set in every `execute` call (rather than
only `succeed`).
- Add documentation for the `timeout` parameter and its default values.
On first run, Postfix will refuse to start if it's started before
Mailman is up, because it'll try to read the map files generated
Mailman the first time it's started, and they won't exist yet. To fix
this, make sure Postfix isn't started until after Mailman is up if
they're both activated at the same time.
