I am aware its not an official Purism reddit page, but Purism staff have responded in the past. I know it is really only filled with posts talking bad about the company so it is understandable they stopped responding to posts there. All I am saying is that it could have been used to communicate
1 Like
That would be a bad PR, since that subreddit is full of hatred towards Purism.
A DoS attack + problems restoring backups? Hmm… Sorry, perhaps a silly question but I tend to be paranoid: are we absolutely sure that this DoS was not intended to distract while a real attack was targeting the servers.
In other words, will my next apt upgrade be safe ?
We certainly can’t be sure of anything, not having detailed or inside knowledge of the attack (either from Purism’s perspective or from the attacker’s perspective).
I would think it would be somewhat difficult to DDoS a server to hell but at the same time the hackers are accessing the server for nefarious purposes - unless there’s a spare network path.
Would it be possible for an earlier attack to have succeeded in placing malware on the server and then the malware is remotely or automatically activated at the same time as the DDoS commences? Yes. It is always a possibility and this kind of distraction attack does happen.
That engages an additional question though because repo content can be digitally signed so that the content has verifiable integrity no matter how badly the server is compromised - assuming of course that the private keys themselves don’t reside on that server. (In other words, you generate the package on another computer, you sign it, you upload it to the server(s).)
This overall signing architecture is essential in order to allow repo mirroring. So I can set up a local mirror for PureOS and you can use my mirror but you don’t have to trust me.
It is explained above why that particular problem arose.
But Purism doesn’t put ultimate trust in signing.
First, you could apt update and see what’s offered. That should be a small amount of packages.
Next, you could clone the sources of these packages, build the version you have installed and verify that they are identical. If that is the case, you can look at the commits that are newer and check if they look suspicious. And finally build that latest version that is available for update, again comparing them.
You have then established that
- the old source was not modified
- the latest commits are not fishy
- available updates correspond to the source
That’s the power of reproducible builds.
Disclaimer: I never did that and yes, it is quite some work. But it could be done. 
2 Likes
I like your level of paranoia. That is a genuine attack method.
1 Like