Those who were impacted were individually contacted by the team. Will check if any follow-up technical analysis post on this is to be released.
BTW, the GitLab issue does not look updated because a separate confidential issue was created to handle it as the issue had user specific inputs.
as Manoj said we contacted the affected users directly as soon as we had the list and later in 24h with their affected files.
I have added a summary to the GitLab issue and closed it, but due to the nature of the event the investigation and detailed findings needed to be dealt with in a private incident ticket.
Kind regards,
Arnau - Engineering Manager Cloud & Infra
These forum posts seem to indicate, that those affected users either didn’t read their mail (or however else you contacted them) or you missed them and there are more.
And it can’t hurt to contact helpdesk@e.email so that they are aware that there might be users outside of their current assessment of the scope of this.
@AnotherElk this user is in our list of receivers. Given the nature of the bug and our investigation, we’re quite confident we’ve covered all the cases.
@pehbeh can you look in your p******um@e.email address, if not on your e-mail client it may be on the webmail in spam? It is unlikely as coming from another e.email address but it may be. It’s a message from security@e.email .
In this case we may need to re-send some of the communications and include recovery addresses.
@arnauvp
Regarding the case of end-to-end encryption, which could have prevented this issue, as you stated yourself in the original thread, I was wondering
a) Do you use full disk encryption on your servers? If no, why not? Last year NCP added the nc-encrypt module, which integrates Nextcloud with full disk encryption, maybe that’s a point to start, even though this targets Raspberry Pi users.
b) Did you initially consider Seafile as a candidate for your /e/ cloud services? It’s also a mature open source cloud project like Nextcloud and it provides client-side / E2E encryption out of the box for a long time already. In terms of security it seems it is also less affected by vulnerabilities as it is C/Python based, in contrast to Nextcloud which is PHP based.
That’s weird… I got a few replies from the users and also added my own internal and external address at the end of all bcc and got the message in both mailboxes.
I will try to check delivery logs and/or resend the communication.
a ) full-disk encryption is needed when the information is on a single disk. We used this in the original ecloud.global (LUKS). It offers no extra protection in this kind of incident in regards to the current server-side encryption (since once the disk is mounted, the files are unencrypted to the application).
b ) we are always open to exploring alternate base platforms for our Murena Cloud but the choice of Nextcloud was taken long time ago and it wouldn’t be an easy move.
Just consider this comment on Seafile:
The client side encryption does currently NOT work while using the web browser and the cloud file explorer of the desktop client.
Users want E2EE but they rarely want to give up any functionality like sharing, collaborative real-time editing of office docs, web access… nothing of which is technically impossible but it’s just not available out-of-the-box and bug-free as of now. So we will continue exploring the possibilities knowing it also needs to be integrated into eOS and with a seamless transition for existing users.