The website / service you want to use will not accept your key, but only the key from the organization that makes sure that your software does not make it possible to skip the ads. So I think the only chance to avoid this is to reject such concepts completely from the beginning.
Rust as a language is not relevant, but the Rust community still helped to popularize the idea that trashing a community by a rewrite is ok if it serves some "higher goal". This rewrite is just a striking example why this is problematic.
I assume it is meant to not only have hashes of the final output, but also securely record all steps done by the right people and the right inputs during building of the software. But this solves the wrong^1 problems while still leaving the door open for malware. Reproducible builds are the right step forward if you actually care about security of free software ecosystem.
1. I guess this depend on your position. In the context of remote attestation, I think this is also even dangerous / evil.
1. What would this be?
2. Good point, but for most purposes I think exploiting some aspect of the build system or the language that moves the exploit code or causes it to be executed before main would be easier than exploiting a memory issue in the compiler (I agree though in principle).
For this to be useful you would need to modify the compiler binary to make the exploit persistent. Otherwise why put an exploit for the compiler in the source to so that the compiler can put some malware in a binary, when you can put the malware in the source directly?
The aspects where I think Rust is worse are: compilation time, high complexity, less stable, only one implementation, no international standard, no proper ABI.
xz was a highly sophisticated attack using social engineering and hiding malware in build artifacts, and it was found just in time. It has nothing to do with languages (it was not obfuscated C or something), but highlights that one has to carefully protect the supply chain. There were several compromised packages in cargo already, Rustup teaches people to do curl | sh.
Rust is not a lot better than C. In many aspect, it is worse. It is better if you focus on a specific point (memory safety) and exaggerate its importance beyond all other considerations and ignoring all other options to make progress in this area. This is the zealotry part.
For my personal IT security, people pushing Rust made things worse not better as I do not get security updates for parts of my OS (Debian) anymore. Also the supply chain risks in the Rust ecosystem are worrying. So even if you go the overall topic security rather than just memory safety, the situation is not all that clear anymore.
It is, of course, in the best interest of Google and co., who are in the business of putting spyware and locked-down content-distribution systems in everybody's pocket, to fully focus on memory safety. Not so much for the free software community where supply chain, long-term maintenance, and the health of existing projects and communities are more important.
And just to preempt the argument "but the superior type system will make everything better". I also was super excited about type system in my youth. I get why people are exited about this. But with experience I realized this also fairly easy to overestimate the impact of this (as I did myself). I also think that Rust is somewhat poorly designed in this regard compared to what is possible here, and adopting it makes it harder to adopt truly better techniques.
Also waypipe is inferior by design as it is a proxy added after the fact.
But it does not matter that they now have some kind of a solution for a use case for which they denied that it even exists for a long time. I will avoid Wayland because I do not like the direction and the interests that drive it.
Not much, and people also should not to do this. One should at least have a check of hash of the download vs some document signed with a key.
In any case, the curl|bash from a website is way worse as it leaves no trace. Here, you have an artifact, and multiple steps, so the probability that an issue can be detected is higher and when someone gets compromises one has a change to figure out what happened and warn others. (so good practice to copy the file somewhere else). People look at this only from purely "can I get compromised" perspective, but overlook this community aspect.
The better choice would have been to double down on N9 and successors. This was my opinion at that time and still is. You may be right about all the internal problems that delayed thing, but the Windows Phone decision was bad and poorly executed.
"But the N9’s accolades did not ultimately carry the day. "
I think it would have. The N9 was killed before it came to market. It was never sold in any of the major markets, the platform was declared dead as the switch to Windows Phone was already announced. But the N9 was technically a very good phone and I do not think it came too late. At that time Nokia was still strong with Symbian and the iPhone was not strong in Europe. The move to Windows Phone (even if you think it would be a good platform) delayed things further. Declaring all your existing products a dead end before having an alternative on the market was a really bad idea.
I think Rust is annoyingly complex and badly designed (although it has good parts) and this would be the same mistake as past pushs to move projects to C++ because "object orientation is clearly better", and as such also step towards more complexity that is difficult to undo again and therefor actively harmful. The better and more powerful approach to safety is proving correctness, which is already possible today but we lack good opensource tooling. Proofs can be added to existing code without introducing complexity.
This is nonsense. There is quite a subset of C which is perfectly safe and an even larger one which can easily be safe with tooling. You could argue that unsafe keyword is easier to spot than the unsafe features of C, so that makes it somewhat easier to screen for issues. But if you screen for memory safety only, this is problematic anyhow.
Ok, you are right. There are situation where something should be re-designed from scratch. I am also not against building something new or better alternatives. But I would still argue that far more often than not rewrites are misguided.