hmt
13. November 2024 um 10:02
61
man kann bbb aktivieren, es funktioniert auch mit v30
1 „Gefällt mir“
Hallo,
das ist ja schon seit x Versionen so. Ich befürchte aber, irgendwann wird sie wirklich inkompatibel werden, wenn es weiterhin keine Weiterentwicklung der App gibt.
Viele Grüße
Steffen
hmt
4. Dezember 2024 um 10:58
63
also es gibt schon regelmäßige Updates der Erweiterung, gestern gab es z.B. mal wieder ein neues, ist jetzt auch mit v30 offiziell kompatibel.
Tobias
5. Dezember 2024 um 09:31
64
bei mir ist in einer 30.0.3 jetzt collabora office zu sehen, wenn ich ein pdf anlicke. der pdf-viewer kommt da bei mir nicht.
??
sucher
5. Dezember 2024 um 22:06
65
und die app pdfviewer 3.0.0 ist aktiviert? evtl collabora nochmal deaktivieren / aktivieren?
bin noch au 30.02 weil das läuft super.
hätte eigentlich erwartet dass die nächste Version genauso gut läuft…
Tobias
6. Dezember 2024 um 03:47
66
tut wieder.
Aber 29.0.10 ist jetzt auch raus (zumindest zum Download angeboten, docker container update lässt noch auf sich warten). Dort soll der pdfviewer auch wieder funktionieren
sucher
7. Dezember 2024 um 14:02
67
und so wie es aussieht wurde nc 30.03 zurückgezogen, weil es mir heute gar net angeboten wurde und 28.0.13 and 30.0.3 withdrawn - 🎁 Releases - Nextcloud community
Hallo,
Update auf 30.0.6 Enterprise war heute erfolgreich. Lediglich zwei Konsolenbefehle zwecks Mimetype Migration und Ergänzung fehlender DB-indizies waren nötig. Werden aber nach dem Update im Systemstatus angezeigt.
Viele Grüße
Michael
Buster
8. März 2025 um 15:53
69
Hi,
ein Update auf Version 31 sollte man vorerst vermeiden:
opened 10:36PM - 07 Mar 25 UTC
bug
high
0. Needs triage
31-feedback
### ⚠️ This issue respects the following points: ⚠️
- [x] This is a **bug**, no… t a question or a configuration/webserver/proxy issue.
- [x] This issue is **not** already reported on [Github](https://github.com/nextcloud/server/issues?q=is%3Aopen+is%3Aissue+label%3Abug) OR [Nextcloud Community Forum](https://help.nextcloud.com/) _(I've searched it)_.
- [x] Nextcloud Server **is** up to date. See [Maintenance and Release Schedule](https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule) for supported versions.
- [x] I agree to follow Nextcloud's [Code of Conduct](https://nextcloud.com/contribute/code-of-conduct/).
### Bug description
After the release of Nextcloud 31.0.0, a user reported suspicious activity on their Nextcloud instance after installing the update: https://bsd.network/@niels/114106538216130985
These request contain the usernames of the instance's users and target:
```
65.21.231.50 - - [07/Mar/2025:20:20:00 +0000] "GET /ocs/v2.php/identityproof/key/<USERID> HTTP/1.1" 301 169 "-" "GuzzleHttp/7"
```
All requests originate from 65.21.231.50. This indicates that PII was transmitted to a third party--in this case Nextcloud--without sufficient user consent. Depending on the selected userId, this data included full names and email addresses.
Being pointed to the issue, I was able to identify jobs named `OCA\LookupServerConnector\BackgroundJobs\RetryJob` as the root cause of these requests.
On all affected nextcloud instances I operate this behavior started exactly after the upgrade to 31.0.0. From the codebase it remains unclear what triggered the behavior. However, several functions around lookupServerUpload handling were refactored or altered in the meantime.
Auditing the configuration did not clarify which user settings may relate to exposure, as affected accounts also included dedicated accounts for, e.g., presentation machines at a conference not used by humans.
By instrumenting related source files, it was established that the configuration setting `'files_sharing', 'lookupServerUploadEnabled'` ultimately enabling the datasharing triggering external requests is found under the Path:
```
Admin Settings -> Sharing -> Federated Cloud Sharing -> Allow people to publish their data to a global and public address book
```
Given that the implication of this setting is that the data of several users who had certainly not given explicit consent to the data transfer was shared with a third party (Nextcloud), the labeling of this configuration setting is, at best, dangerously misleading and at worst hiding its actual implications.
### Steps to reproduce
1. Upgrade from Nextcloud v30.0.6 to v31.0.0
2. Wait for the regular cronjob to run
3. Within seconds of the first `OCA\LookupServerConnector\BackgroundJobs\RetryJob` job for a user, a request from `65.21.231.50` will be made to `/ocs/v2.php/identityproof/key/<USERID>`, demonstrating that data was shared with a third party.
### Expected behavior
- The global `"lookupServerUploadEnabled"` setting should remain `NO` after an upgrade, and **NO** user data should be shared with third parties without users' or operators' consent.
- The setting for `"lookupServerUploadEnabled"` should be descriptively labeled, require confirmation, and make the implications of being enabled clear
### Nextcloud Server version
31
### Operating system
Debian/Ubuntu
### PHP engine version
None
### Web server
None
### Database engine version
None
### Is this bug present after an update or on a fresh install?
None
### Are you using the Nextcloud Server Encryption module?
None
### What user-backends are you using?
- [x] Default user-backend _(database)_
- [x] LDAP/ Active Directory
- [ ] SSO - SAML
- [ ] Other
### Configuration report
```json
```
### List of activated Apps
```shell
```
### Nextcloud Signing status
```shell
```
### Nextcloud Logs
```json
```
### Additional info
Please understand that the turn of events is extremely unfortunate. I will have to evaluate over the next 72h whether this event falls under Art. 33 III DSGVO.
I expect Nextcloud GmbH to perform due diligence in this matter as well. This includes:
- Ensuring that all potentially unintentionally leaked data is deleted
- Ensuring that this data is not re-shared to third parties or made publicly available
- Sharing documentation on the above two steps and a post-mortem with the Nextcloud community and the responsible DPA
**Note on HackerOne Submission:** On Mattermost and in Nextcloud's security reporting information on GitHub, a submission of security sensitive events is requested via HackerOne. I decided to not follow this recommendation for the following reasons:
- I do not consent to the terms and conditions of HackerOne, but believe that this issue is critically important for the community
- The leak/"vulnerability" (or rather: 'unintentional feature') can be mitigated by operators, if they set the aforementioned config setting to off; Delaying publication would, hence, expose users further.
- Technically, in this case, the not necessarily authorized collector of data is Nextcloud GmbH
VG
Buster
2 „Gefällt mir“