Dear ILIAS-Admins,
on Nov 4th a new release for ILIAS 8 (8.25) was published. The ILIAS 8 branch
is a security-fixes only branch as announced in:
https://github.com/ILIAS-eLearning/ILIAS/blob/trunk/docs/development/suppor…
In this ILIAS 8 release, however, a security bug introduced a severe new
usability bug in the SCORM component. Thus, a fix for this bug
(https://mantis.ilias.de/view.php?id=46165) was also introduced today in this
branch after the release 8.25 tag in order to solve the regression. You can
find the release_8 branch here:
https://github.com/ILIAS-eLearning/ILIAS/tree/release_8. Please make sure to
checkout the latest commit of the release_8 branch in order to have a secure
and stable ILIAS 8 release.
Best regards
Rob Falkenstein
For the Technical Board of the ILIAS society
Dear all,
after consultation with the product manager I would like to inform you
about the following problem, in order to prevent you from loosing data.
In ILIAS 9.15, a bug was fixed that corrects the online status in
learning sequences, as these were stored ambiguously:
https://mantis.ilias.de/view.php?id=45670
Unfortunately, the deletion of the “lso_activation” table resulted in
the loss of some online statuses (NO LEARNING DATA IS AFFECTED, only
whether objects are online or not). This affects all learning sequences
that were copied with a container (course, category, folder, etc.) and
were not opened before the update.
To restore the data, a DB backup must be used in which the affected
table is still available. From this, you can restore the lso_activation
table (temporarily) and use SQL to transfer the data to the new
location, namely to object_data. My colleague Ingmar wrote a SQL
statement, which you are able to restore the online-status and which
worked for our clients. Of course, use is without guarantee - the
statement should be used as a template and checked for each individual case.
UPDATE object_data
INNER JOIN object_reference ON object_data.obj_id = object_reference.obj_id
INNER JOIN lso_activation ON lso_activation.ref_id = object_reference.ref_id
SET object_data.offline = 0, lso_activation.effective_online = 1
WHERE
object_data.offline = 1 AND
lso_activation.online = 1 AND
lso_activation.activation_start_ts IS NULL AND
lso_activation.activation_end_ts IS NULL;
Important notice: The affected Learning Sequences can also be set online
manually, so this especially relevant if your platform contains a high
number of those objects.
Many thanks to Ingmar for investigating this.
Best regards
Simon
--
Databay AG Logo
*Simon Lowe
*
fon: +49 2405 40837-0
mail: slowe(a)databay.de
web: www.databay.de <https://www.databay.de>
Databay AG
Jens-Otto-Krag-Str. 11
52146 Würselen
Sitz/Amtsgericht Aachen • HRB: 8437 • USt-IdNr.: DE 210844202
Vorstand: Dipl.-Ing. Jens Conze, Aresch Yavari, Dipl.-Kfm. Philipp Hermanns
Aufsichtsratsvorsitzender: Dr. Jan Scholzen
Datenschutzhinweise für Kunden: Hier nachlesen
<https://www.databay.de/datenschutzhinweise-fuer-kunden>
Dear colleagues!
---
TL/DR: Please use `npm clean-install` to install npm-dependencies and be careful when updating packages.
---
A little longer: Please be aware of the current supply-chain-attack on the npm-ecosystem:
* https://socket.dev/blog/npm-author-qix-compromised-in-major-supply-chain-at…
* https://socket.dev/blog/ongoing-supply-chain-attack-targets-crowdstrike-npm…
* https://www.paloaltonetworks.com/blog/cloud-security/npm-supply-chain-attac…
* https://www.heise.de/news/Neuer-NPM-Grossangriff-Selbst-vermehrende-Malware…
As far as we understand the situation, the attack is ongoing and additional packages might be affected in the course of future events.
On the bright side, we are safe if everyone uses `npm clean-install`, as this will always pull the exact versions that we have pinned in `package-lock.json`. These are (to the best of our knowledge...) not affected. Also, existing versions of npm-Packages won't be replaced with other code (again, to the best of our knowledge). If this is not true and you can indeed identify malicious packages in our npm-dependencies, please don't hesitate to report them to security(a)ilias.de.
On the other hand, every operation that might update pinned packages (be it `npm install` or `npm update`) might pull versions of libraries that are indeed affected. Please make sure to understand the risk involved here and consider to postpone any update of npm-dependencies until the attack and its consequences are mitigated. If you indeed need to update npm-dependencies now, please make sure to check the implied changes in the package-lock.json thoroughly against an up-to-date list of affected packages.
It currently looks as if we are safe and can weather this situation just fine, which is a direct consequence of our tightened procedures around our dependencies, especially the centralized handling and the Dependency Jour Fixe. Good job everyone!
If there are any questions or ideas, feel warmly welcome to reach out to us via tb(a)ilias.de or Discord.
Kind regards!
Richard Klees
for the Technical Board of the ILIAS Society
--
Richard Klees
Geschäftsführung
Fon: +49 (0)221 / 46 75 76 - 56
Fax: +49 (0)221 / 46 75 76 - 09
---------------------------------------------
CaT Concepts and Training GmbH
Subbelrather Str. 15 B
50823 Köln
Fon: +49 (0) 221 / 46 75 76 - 00
Fax: +49 (0) 221 / 46 75 76 - 09
Web:
https://www.concepts-and-training.dehttps://www.cate-lms.de
---------------------------------------------
Geschäftsführung:
Claudia Glander, Gerald Konrad, Richard Klees
Amtsgericht Köln HRB 57804
Ust-ID-Nr.: DE 814694228
Sitz: Köln
---------------------------------------------
Sollten Sie weitere Informationen zu der Verarbeitung Ihrer Daten (Art. 12 ff., DSGVO) wünschen, informieren Sie sich unter:
https://concepts-and-training.de/datenschutz-kunden.html
