Discourse normally overrides the default notification email setting,
which makes the `notificationEmailAddress` setting ineffective. Add a
patch to remove this override.
Fixes#140114.
(cherry picked from commit 917a0cfe47bad420a894fe8ca35d7dd95ebb5a7c)
When restoring a backup, discourse decompresses the backup archive in
the /share/discourse/tmp dir. Before this change, it is linked to /run
which is typically backed by memory, so the backup will fail to
restore if you do not have enough memory on your system to contain the
backup. This has already happened to me on two small forums.
This moves tmp to the StateDirectory /var/lib/discourse/tmp which is
typically backed by disk.
(cherry picked from commit f933c68374b9c6195dc74d26c95fc9bf240fead8)
ChangeLog: https://github.com/hedgedoc/hedgedoc/releases/tag/1.9.0
As documented in the Nix expression, I unfortunately had to patch
`yarn.lock` manually (the `yarn.nix` result isn't affected by this). By
adding a `git+https`-prefix to
`midi "https://github.com/paulrosen/MIDI.js.git#abcjs"` in the lock-file
I ensured that `yarn` actually uses the `MIDI.js` from the offline-cache
from `yarn2nix` rather than trying to download a tarball from GitHub.
Also, this release contains a fix for CVE-2021-39175 which doesn't seem
to be backported to 1.8. To quote NVD[1]:
> In versions prior to 1.9.0, an unauthenticated attacker can inject
> arbitrary JavaScript into the speaker-notes of the slide-mode feature
> by embedding an iframe hosting the malicious code into the slides or by
> embedding the HedgeDoc instance into another page.
Even though it "only" has a medium rating by NVD (6.1), this seems
rather problematic to me (also, GitHub rates this as "High"), so it's
actually a candidate for a backport.
[1] https://nvd.nist.gov/vuln/detail/CVE-2021-39175
(cherry picked from commit 0a10c17c8d01e5f9fefa3d6dbb7802a3cbce7e23)
Some plugin repos already have a `gems` directory. This lets the
packager choose whether it should be kept and the nix packaged ruby
gems should be copied into it or if it should be removed in favor of
our ruby gems.
(cherry picked from commit 04e6b03fa91603c7f1961cfcdcf5880c91fe6b05)
Let the update.py script handle the initial, repetitive task of
packaging new plugins. With this in place, the plugin only needs to be
added to the list in `update-plugins` and most of the work will be
done automatically when the script is run. Metadata still needs to be
filled in manually and some packages may of course require additional
work/patching.
(cherry picked from commit f8096460bd15d4f13a01cfddf0a30798921fdb42)
Change the path to the auto generated plugin assets, which defaults to
the plugin's directory and isn't writable at the time of asset
generation.
(cherry picked from commit 443b318ee9c614d480a2ecb0120b52806d6fbb3b)
Perform the tests on the package that the `tests` attribute is a child
of, i.e. if `discourseAllPlugins.tests` is built, the tests will run
with the `discourseAllPlugins` package, not the `discourse` package as
previously.
(cherry picked from commit 6fd5a40ccaf0b4da1362803a387bf46d381dd66a)
Maybe bundix doesn't handle them properly? They cause runtime issues
and don't seem necessary when the binary gems are built from scratch
anyway.
(cherry picked from commit a2dbc3af1d50edb8d646817e7abe799bcf369f20)
Some discourse plugins have Ruby dependencies and require a
specialized builder. This introduces a generic builder that can be
used whether the plugin has Ruby dependencies or not. It also adds a
set of pre-packaged plugins available through `discourse.plugins` and
provides an easy way to add more.
(cherry picked from commit 7671b90919af8271bdf7e07bb86d63216a2145d6)
For plugins to work properly, their assets need to be precompiled
along with the rest of Discourse's assets. This means we need to build
new packages when the list of plugins change.
(cherry picked from commit 9af3672f4faaafba0ce0129a87fc7925c14eeb61)
Moritz Hedtke
talyz
Ryan Mulligan
Maximilian Bosch
R. RyanTM
Felix Buehler
illustris
Maciej Krüger