If you downloaded Mint Cinnamon today (for versions of "today" that include February 20th, 2016) you should immediately check the MD5 checksum. Blog Entry here.
From Clem:
We were exposed to an intrusion today. It was brief and it shouldn't impact many people, but if it impacts you, it's very important you read the information below.
Hackers made a modified Linux Mint ISO, with a backdoor in it, and managed to hack our website to point to it.
As far as we know, the only compromised edition was Linux Mint 17.3 Cinnamon edition.
If you downloaded another release or another edition, this does not affect you. If you downloaded via torrents or via a direct HTTP link, this doesn't affect you either.
Finally, the situation happened today, so it should only impact people who downloaded this edition on February 20th.
Apparently the hacked ISOs are hosted on 5.104.175.212 and the backdoor connects to absentvodka.com. Both lead to Sofia, Bulgaria, and the name of 3 people over there.
The comment thread suggests that the ISOs are showing up in other places, and that the Mint site may still not be entirely secure.
Related Stories
Following closely upon the hacking of the Linux Mint website, the developers of the Transmission bittorrent client have announced that last week's 2.90 release was infected by a new form of OSX malware, OSX.keRanger.A (or "KeyRanger" as 9to5mac is calling it).
The payload appears to be the first OSX ransomware discovered in the wild. If it works, OSX.KeRanger.A should begin encrypting infected users' files on Monday, March 7. The malware seems to have been included only in downloads from the developers' website, while Transmission's internal update function (using the Sparkle framework) seems to have delivered clean updates. The developers have released two updates (2.91 and 2.92) in the past twenty-four hours to remove the infection.
Those who use Transmission on OSX should check for the following on their systems:
- a process called "kernel_service" running
- a file "Contents/Resources/General.rtf" inside the Transmission.app directory
- any of the following files in the "/Library/" directory: ".kernel_pid", ".kernel_time", ".kernel_complete" or "kernel_service"
[Update:] According to a report in ITWorld, Apple shuts down first-ever ransomware attack against Mac users.
With the help of security researchers, Apple over the weekend quickly blocked a cyberattack aimed at infecting Mac users with file-encrypting malware known as ransomware.
[...] The tainted Transmission version was signed with a legitimate Apple developer's certificate. If a Mac user's security settings are set to allow downloads from identified Apple developers, the person may not see a warning from Apple's GateKeeper that the application could be dangerous.
Apple revoked the certificate after being notified on Friday, [Security company] Palo Alto wrote. The company has also updated its XProtect antivirus engine.
After it is installed on a system, KeRanger waits three days before connecting to a remote command-and-control server using the Tor system. It is coded to encrypt more than 300 types of files.
Clem Lefebvre, the honcho at Linux Mint, has commented in some forum threads February 24 regarding what they were doing for several days while the site was offline.
You're now [behind] HTTPS [at the forum] (that doesn't protect against the kind of attacks we went through, but it helps if you're hacked locally)
[...] We're also behind a global [firewall] and we've got new friends at Sucuri.net who scan our server for malware.
This phpbb is also version 3.1, so you'll see a few differences and some new features compared to the previous forums.
...and later in the day
- The firewall filters a lot of bandwidth and saves a lot of processing dedicated to the constant pounding of DDOS, malware, poking, and all the bad stuff that bots send continuously over the internet. That means less work for the server [which is why it's faster for you now].
[...] The phpbb team reached out to us during the attacks to see how they could help. I asked about updates vs customizations. [Fancy theming is] not a priority right now,
It appears there were things they already had on their list and getting pwned kicked that stuff into gear.
Previous: Mint Cinnamon ISOs Hacked
(Score: 0, Informative) by Anonymous Coward on Sunday February 21 2016, @03:33PM
You're doing it wrong, bro. Read up:
http://www.mathstat.dal.ca/~selinger/md5collision/ [mathstat.dal.ca]
https://en.wikipedia.org/wiki/MD5#Security [wikipedia.org]
(Score: 0, Flamebait) by Anonymous Coward on Sunday February 21 2016, @03:52PM
1. sign all releases with GPG.
2. switch to sha512 & whirlpool checksums
(Score: 0, Troll) by Anonymous Coward on Sunday February 21 2016, @05:31PM
Granted I know next-to-nothing about crypto, but provided you use a decent signing key this seems sound advice.
Am I missing something?
(Score: 0) by Anonymous Coward on Sunday February 21 2016, @05:55PM
Granted I know next-to-nothing about Marty, but provided it is decent advice a silly forced-subject seems irrelevant.
Again, am I missing something? Is the advice intentionally wrong?
(Score: 2) by Pino P on Sunday February 21 2016, @05:56PM
But how does a user securely obtain the public key of the publisher? MIT's PGP key server does not support HTTPS [noncombatant.org], which is one of the factors making it easy for trojaned PuTTY [helpnetsecurity.com] to spread.
(Score: 0) by Anonymous Coward on Sunday February 21 2016, @06:45PM
Thanks, that was an interesting read.
It seems key signing parties really are worth the effort.
(Score: 2) by Pino P on Monday February 22 2016, @09:20PM
It seems key signing parties really are worth the effort.
With respect to the OpenPGP web of trust and key signing parties, I've always wondered about two things. The first is where users of OpenPGP applications are supposed to find the money for air travel in order to get their keys signed by people living in faraway cities. The second is how the trust implied by the binary relation "Alice signed Bob's key" can be transitive. Just because I can vouch for the identity of somebody I have met at a key signing party doesn't mean I can vouch for that person's ability to vouch for other people's identities. This is why X.509 certificates (RFC 5280 [ietf.org]) have the cA bit in the basic constraints to warn people relying on the certificate that its subject is not itself a certificate authority.
(Score: 2) by Fnord666 on Sunday February 21 2016, @07:10PM
You use some sort of "out of band" mechanism to validate the fingerprint of the associated public key. Now whether the publisher knows how to do that or is willing to give you the time of day is a different story.
(Score: 2) by Pino P on Monday February 22 2016, @09:10PM
some sort of "out of band" mechanism
And this is where the argument turns into a handwave. Can you recommend such an "out of band" mechanism that doesn't involve either the CA racket (X.509) or air travel (OpenPGP web of trust)?
(Score: 2) by Fnord666 on Thursday February 25 2016, @04:25PM
A good point. A phone call to the entity in question (not using a phone number you got from the same web page as the download!!) would be one way. A PGP signed email reply from the entity in question, where the public key has been published for a number of years on a public key database is another. My own efforts trying to get a valid fingerprint from someone has met with limited success as well.
(Score: 2) by opinionated_science on Sunday February 21 2016, @07:11PM
I have also wondered this - hence you nearly always need to be vigilant. I think debian are more careful, but....
It has occurred to me that PGP fingerprints could be forged using MITM, so I'm curious as to why the FOSS movement doesn't think this serious?
(Score: 0) by Anonymous Coward on Sunday February 21 2016, @07:33PM
Because most people consider hard-to-explain-without-jargon threats to be loony paranoia until it either affects them, or someone they know who's in a similar position to them.
Remember that most people think the measure of password strength is whether their coworkers will bother to guess it by hand, thus people think their pets name ("joey") is perfectly secure since "why would they think it's my dogs name? why would they bother?"
(Score: 3, Informative) by frojack on Sunday February 21 2016, @09:30PM
PGP fingerprints could be forged using MITM, so I'm curious as to why the FOSS movement doesn't think this serious?
Because its very difficult to pull off a MITM attack against the entire world simultaneously which will go un-noticed.
I keep signing stuff (packages, email, etc) using my valid (private) key, but some mitm substitutes a different public key, and all of a sudden my emails are won't validate, my packages won't validate, and alarms sound and people start checking. Its very tricky to pull off a MITM attack against a properly signed package or even a signed email.
No, you are mistaken. I've always had this sig.
(Score: 3, Interesting) by opinionated_science on Sunday February 21 2016, @10:23PM
well I am using debian, which doesn't sign by default. I used to use OpenSuse which did.
Since the Snowden revelations, I am surprised paranoia is not running at overload. Add the likelihood of backdoors at various levels of the hw/sw stack , the one place we can add security is the open source packages we install!!!
But then we have that old compiler problem too...;-)
Good Security is *HARD*. A lesson I feel a complete beginner at...
(Score: 3, Interesting) by frojack on Sunday February 21 2016, @11:08PM
I try to avoid Debian based distros just because you never know when they are going to erupt into another cat fight.
But in checking exactly one random package I see that things are signed as well checksumed at sign-in
( see https://packages.qa.debian.org/c/claws-mail/news/20160126T114928Z.html [debian.org] ).
But I haven't gone rooting around in their outbound distro source or binary repositories to see if that
persists all the way to the end user.
No, you are mistaken. I've always had this sig.
(Score: 2) by gottabeme on Tuesday February 23 2016, @07:11AM
well I am using debian, which doesn't sign by default.
What? Debian has been signing its repos for many years. Maybe you need to read this: https://www.debian.org/doc/manuals/securing-debian-howto/ch7 [debian.org] Scroll down to "7.5 Package signing in Debian".
(Score: 3, Interesting) by frojack on Sunday February 21 2016, @09:19PM
But how does a user securely obtain the public key of the publisher?
Securely in this case only means "valid", it doesn't mean obtained via encrypted channels, which is not necessary. Public keys are not secret.
Public keys are posted in a lot of different places, keyservers all over the world, on web pages, in email footers, etc.
If someone wants to substitute their own key for someone elses key so that they can sign backdoored software packages, they have to create a new key, sign with their private key, publish the new public key to keyservers, wait for it to propagate, then, (and only then) hack the web servers where the public keys are often displayed and downloadable.
All of these things have to be done in sequence, and in the meantime everyone's existing copy of the real public key will suddenly no longer work.
This is why you should sign your email routinely, because knowledgeable people will notify you if your key fails validation, as such validation is built into mail readers or plugins thereto.
As for other people's keys, You fetch them once and leave it in your key storage. and once in a while have it check against the keyservers.
You be very careful about accepting a new key that doesn't contain a long list of signatures, especially when dealing with software distros and important stuff.
No, you are mistaken. I've always had this sig.
(Score: 2) by Pino P on Monday February 22 2016, @09:37PM
But how does a user securely obtain the public key of the publisher?
Securely in this case only means "valid", it doesn't mean obtained via encrypted channels, which is not necessary. Public keys are not secret.
Though the channel through which a public key is obtained need not be private, it still needs to be tamper-evident. HTTPS is the best known tamper-evident channel included with mainstream operating systems. Cleartext HTTP is not.
If someone wants to substitute their own key for someone elses key so that they can sign backdoored software packages, they have to create a new key, sign with their private key, publish the new public key to keyservers, wait for it to propagate, then, (and only then) hack the web servers where the public keys are often displayed and downloadable.
All of these things have to be done in sequence
A sufficiently patient attacker can certainly do so, especially if it is an ISP- or state-level actor that can proxy all of the victim's cleartext HTTP connections.
As for other people's keys, You fetch them once
So how would the user of PuTTY fetch the PuTTY key once while ensuring that the keyserver from which the key is fetched isn't being maliciously proxied?
You be very careful about accepting a new key that doesn't contain a long list of signatures, especially when dealing with software distros and important stuff.
My reply to this sentence depends on how you define "a long list of signatures". If you just count other keys that sign the developer's key, it is vulnerable to a Sybil attack [wikipedia.org] in which the attacker generates a large number of keypairs, each of which signs the key used to sign the malware. If you mean the existence of one or more relatively short paths in the web of trust from oneself to the developer, then how would a legitimate new developer go about getting his key signed widely without traveling to key signing parties in foreign countries? See my reply to maxwell demon [soylentnews.org].
(Score: 3, Interesting) by frojack on Monday February 22 2016, @10:00PM
1) Tamper evidence is obvious, because the key doesn't work if tampered with. (besides, if you still believe in https you are hopelessly delusional: https://www.eff.org/deeplinks/2011/10/how-secure-https-today [eff.org] )
2) patience isn't part of the equation. There is a very short window of opportunity in which the key has propagated (usually happens within 20 minutes of key publishing), an when people start noticing there is an un-signed-un-trusted key in the key servers with their name on it. If you wait longer to publish your bogus ISO, it will be discovered. If you publish right away, no one will be able to check the signature in preparation for installing it.
Notice how long it took for Mint to detect this fraud. Mere hours, and the word is out.
3) its not sufficient to proxy a key server, you have to proxy ALL of them, because the work as a pool, and the one that gets queried is not predictable. Then, you have to convince someone to use a URL that clearly does not match the expected domain.
4) It probably doesn't need to be a long list, but it should to be a populated list. Most people don't due this level of cross checking, but it helps.
Tools for doing this are common, but anyone using Putty might never notice.
No, you are mistaken. I've always had this sig.
(Score: 2) by Pino P on Monday February 22 2016, @10:37PM
There is a very short window of opportunity in which the key has propagated (usually happens within 20 minutes of key publishing), an when people start noticing there is an un-signed-un-trusted key in the key servers with their name on it.
Provided the program signed with the key has a sufficient audience of highly knowledgeable users.
its not sufficient to proxy a key server, you have to proxy ALL of them
Which an ISP-level actor is certainly capable of doing to one or more of its subscribers.
Then, you have to convince someone to use a URL that clearly does not match the expected domain.
If you register foobarcdn.com then you can social engineer people into thinking linuxmint.foobarcdn.com is part of the new mirror network that Linux Mint is using.
Even then, PKI practices that work for a major Linux distribution might not work for a relatively new application with one or a few otherwise professionally unknown developers.
(Score: 2) by TheLink on Monday February 29 2016, @05:08AM
But how does a user securely obtain the public key of the publisher?
Doesn't matter in practice. If the past 9 releases over X years have been signed by the same key and nobody including the releasers themselves have been making noises then when the 10th release is signed by the same key then it's more likely to be as OK as the past releases.
In contrast this logic cannot apply if you use SHAx or MD5. Since hackers could often also tamper with the page listing the hashes.
Of course even then as this incident has shown even if you are using SHAx the lower security usually doesn't matter that much in practice - it doesn't go hidden for long.
The real problems are how they got hacked in the first place. Most organizations will have the same weaknesses and vulnerabilities to being pwned if not more. The bulk of them don't really get pwned by tampered ISOs, they get pwned by running forum software that's full of holes or by social engineering, getting spearphished etc.
(Score: 2) by Pino P on Monday February 29 2016, @03:45PM
The "key continuity" model could work for something long established like PuTTY. But how would it work for a new application?
(Score: 2) by TheLink on Tuesday March 01 2016, @06:13AM
And if it takes NewAppVendor 1 year to detect and announce that the released NewApp was actually signed by a malicious party's GPG key, then perhaps people should stop trusting NewAppVendor and NewApp so much and avoid using NewApp and other stuff by NewAppVendor.
People who care about security wouldn't have placed that much trust in PuTTY when it first started.
(Score: 4, Informative) by darkfeline on Monday February 22 2016, @01:05AM
No, you're not approaching this problem correctly.
If the hackers could change the links to the ISOs, why couldn't they change the MD5 sums as well? No need to look for collisions or anything, just link the MD5 for your backdoored ISO.
This is why you use PGP. Even if they signed the ISOs with their private key, all sorts of warning bells will go off. Missing signatures, signature verification not working, etc.
For example, if Mint's master PGP public key were signed by twenty Mint devs, the attacker would have to compromise the private keys of all twenty Mint devs plus Mint's server to mount a credible attack.
Join the SDF Public Access UNIX System today!
(Score: 0) by Anonymous Coward on Monday February 22 2016, @09:34PM
The approach is Linux Mint's. The choice of MD5 is, as you elucidate, one of several questionable decisions.
(Score: 2, Informative) by Anonymous Coward on Sunday February 21 2016, @03:38PM
https://news.ycombinator.com/item?id=11142986 [ycombinator.com]
https://www.reddit.com/r/linux/comments/46tdcj/beware_of_hacked_isos_if_you_downloaded_linux/ [reddit.com]
https://lwn.net/Articles/676613/ [lwn.net]
https://twitter.com/Linux_Mint/status/701222478178340864 [twitter.com]
(Score: 2) by frojack on Sunday February 21 2016, @08:43PM
According to Clem they used a wordpress hack to gain a shell in the web server
Edit by Clem: Yes, the breach was made via wordpress. From there they got a www-data shell.
No, you are mistaken. I've always had this sig.
(Score: -1, Flamebait) by Anonymous Coward on Sunday February 21 2016, @04:46PM
Linux security? Hahahahahahahahahaha!
(Score: 0) by Anonymous Coward on Sunday February 21 2016, @08:33PM
Regarding that OS which comes pre-installed on a large number of computers:
Did that OS ever start to ship with a mechanism to assure that downloads aren't a broken pile of bits or a purposely-altered rogue file?
...or is every added executable that its users download and run still unverified--i.e. a potential explosive satchel?
Back in the DOS days, I remember that the magazine that included text listings of executables included a checksum so that when you typed it in you could verify that you hadn't make a mistake.
I noticed that that sort of checking disappeared when Redmond's newer GUIware OS appeared.
When I started tinkering with Linux, I noticed that checksum verification was standard practice again.
...and trying to read Mint's forum yesterday evening was disappointing (Connection interrupted).
I had to go to Google and get their caches of Mint's pages.
There was a similar experience a few weeks back when they made changes to the site and didn't do sufficient testing before going live.
I seems that Clem and the guys need to brush up on site maintenance|security.
-- OriginalOwner_ [soylentnews.org]
(Score: 5, Insightful) by Lunix Nutcase on Sunday February 21 2016, @09:34PM
Did that OS ever start to ship with a mechanism to assure that downloads aren't a broken pile of bits or a purposely-altered rogue file?
Yeah, it's called code signing. Welcome to more than a decade ago.
...or is every added executable that its users download and run still unverified--i.e. a potential explosive satchel?
Nope, when the source can't be confirmed (because the executable isn't signed) it pops up asking if you really want to run it.
Back in the DOS days, I remember
Because that has any relevance to today.
(Score: 0) by Anonymous Coward on Monday February 22 2016, @03:44AM
code signing
That's a step in the right direction.
Apparently, it's Redmond that does the signing.
I'm guessing there is a monetary charge for that.
Must be nice--when you're on the right end of the racket.
A checksum sounds easier and cheaper.
more than a decade ago
Better late than never, I guess.
I had bailed on That Other OS by then, apparently.
the executable isn't signed
...because the dev wasn't willing to pay M$'s dangeld, one assumes.
A simple checksum would solve that situation.
any relevance
The topic was verifying the validity of an executable.
Being able to do that over 3 decades ago is absolutely on-topic.
Being able to do it at zero cost and with zero latency is quite relevant.
-- OriginalOwner_ [soylentnews.org]
(Score: 2) by Pino P on Monday February 22 2016, @10:29PM
A checksum sounds easier and cheaper.
Who signs the checksum?
(Score: 0) by Anonymous Coward on Monday February 22 2016, @10:58PM
The packager signs the checksum, obviously.
(It would be good if he didn't get his site pwned.)
-- OriginalOwner_ [soylentnews.org]
(Score: 2) by Pino P on Monday February 29 2016, @04:29PM
If the packager signs the checksum, who signs the packager's public key? That's all Authenticode is: a checksum encrypted with the publisher's private key, plus a certificate asserting that the corresponding public key belongs to the publisher.
(Score: 0, Funny) by Anonymous Coward on Monday February 22 2016, @12:22AM
I seems that Clem and the guys need to brush up on site maintenance|security.
Security has never been a priority for the mouth-breathers at Linux Mint, or the yokels who use it.
It has always been an easy to install not-Windows. That's it.
A few years ago, it was discovered that the Mint team was purposely withholding upstream security patches because it would be too difficult to apply them. What the actual fuck.
Mint is like the Palemoon browser, a bunch of amateurs who wouldn't have a product if they couldn't leech from upstream contributors and then change the logo. I certainly do not trust them with my data.
(Score: 5, Funny) by PinkyGigglebrain on Sunday February 21 2016, @05:43PM
This is great news!
Linux finally has enough mind share to get hackers to try and compromise the installs images!
Can the year of the Linux Desktop be far behind?
"Beware those who would deny you Knowledge, For in their hearts they dream themselves your Master."
(Score: 3, Insightful) by Pino P on Sunday February 21 2016, @05:46PM
This is why fans of Authenticode-style code signing claim that a secure channel (such as HTTPS) isn't enough, that each software publisher needs to obtain a certificate from a commercial certificate authority and keep it current.
(Score: 3, Insightful) by maxwell demon on Sunday February 21 2016, @07:49PM
Yeah sure, because money makes the key so much more secure.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by Pino P on Monday February 22 2016, @09:31PM
Money does not make the key itself more secure. It is believed to make the assertion of the identity of the key's holder more secure.
(Score: 0) by Anonymous Coward on Sunday February 21 2016, @08:02PM
You mean security theatre companies claim that if you only bought their product, you'd be safe?
I did not see that one coming.
(Score: 4, Insightful) by Dunbal on Sunday February 21 2016, @08:37PM
No, you'd FEEL safe, which is different.
(Score: 4, Informative) by frojack on Sunday February 21 2016, @08:21PM
The thing is, the actual mint ISOs were in fact all signed, and were not compromised.
The hackers created NEW ISOs, hosted on their own website which were compromised.
The only scary part here is that Mint's web server which contains links to the download server was hacked and links to the rogue server inserted. The hackers were never able to compromise the actual Mint repository server, but apparently the web server wasn't as well protected.
Code signing wouldn't have prevented this in any way.
What is alarming is that they had poor security on their web servers. As far as I know that hasn't been explained yet.
No, you are mistaken. I've always had this sig.
(Score: 3, Interesting) by frojack on Sunday February 21 2016, @08:49PM
According to Clem they the breach was made via wordpress. From there they got a www-data shell. From there they made changes to the web page containing the URLs for the download server.
So third party crapware running with excessive privileges defeats Linux security once again. Its not like its the first time Wordpress has been the source of such problems.
No, you are mistaken. I've always had this sig.
(Score: 3, Interesting) by darkfeline on Monday February 22 2016, @01:10AM
So ultimately, the problem is that no one verifies the signatures.
Join the SDF Public Access UNIX System today!
(Score: 2) by frojack on Monday February 22 2016, @01:58AM
I doubt that is the case, and I doubt that had anything to do with the current topic.
Personally, I don't fly to Germany to do an In person verification of Opensuse pgp keys, so my key
list remains in the "valid but untrusted" category. The web of trust that the opensuse signing keys
have is extensive, and I import all the keys for those who have signed the opensuse keys.
But clearly I don't import all the keys of those who signed opensuse's signing keys. I only go one level
deep.
I've signed a few people's keys over the years, and had them sign mine. But the web of trust is a world wide
thing which is pretty difficult to establish with complete certainty.
To the best of my knowledge, there is no "Kevin Bacon" tool to determine if there is a trusted link from
me to any random developer I communicate with. (Good Idea for a SmartPhone App).
No, you are mistaken. I've always had this sig.
(Score: 0) by Anonymous Coward on Sunday February 21 2016, @08:11PM
Mint is known for being security unconscious. They are usually slow to update their repo's when security updates come out and I'm not surpised to know that they run the rest of their shop with poor security.
I know they are popular but, newbs are better off with some flavor of Ubuntu.
(Score: 0) by Anonymous Coward on Sunday February 21 2016, @08:44PM
I've been to the Ubuntu forum and the Mint forum.
Mint's is more n00b-friendly IMO.
-- OriginalOwner_ [soylentnews.org]
(Score: 0) by Anonymous Coward on Sunday February 21 2016, @09:13PM
Different AC here, but how many people being set up with Linux are going to check either forum? No, most people are going to call whomever set up their computer (whether an OEM or a family member or friend), end up wherever a random Google takes them, or ask in some community they are already involved in, in case someone there knows.
On a related note:
If I'm giving someone Linux, it is most likely because my concerns boil down to some security issue I am fixing for them. Now while I don't know the particulars that the GP referred to, I am of the opinion that downstream is almost always less secure than the upstream. The only exception to that is if they have additional mitigations that upstream doesn't have. The two reasons for that is that being downstream results in more time for bugs to be exploited as they work their way down and the trickle down process introduces more chances of a security mistake being made. That is why would prefer Debian over Ubuntu and Ubuntu over Mint, as I'm not aware of any additional mitigations they do over their upstream that counter-balance the risk.
(Score: 1, Informative) by Anonymous Coward on Sunday February 21 2016, @09:14PM
You misspelled FreeBSD.
(Score: 0) by Anonymous Coward on Monday February 22 2016, @02:35AM
Out of curiosity, how many of you BSD shills actually use BSD for anything modernly productive?
(Score: 0) by Anonymous Coward on Monday February 22 2016, @05:10AM
Reading email and surfing the web. I'm a rebel!!!!
(Score: 2) by Pino P on Monday February 22 2016, @10:15PM
Every iOS app in existence was made with *BSD.
(Score: 5, Interesting) by Natales on Sunday February 21 2016, @09:45PM
This would not have happened if they distribute images via IPFS (ipfs.io) since the actual filename is based on the original hash and signature of the binary. Any change in the binary would refer another object altogether since files are immutable. The sooner we move to an immutable web for these kinds of use cases, the better.
(Score: 2) by Pino P on Monday February 22 2016, @10:20PM
In order for security updates to be published, something has to be mutable. For example, this something might be the IPFS filename of the list of updated packages. An attacker could use IPFS to generate trojaned packages and then hack the site containing the mutable filename.