KernelCI now testing Linux Rust code (Collabora blog)
KernelCI now testing Linux Rust code (Collabora blog)
Posted Dec 8, 2022 15:22 UTC (Thu) by khim (subscriber, #9252)In reply to: KernelCI now testing Linux Rust code (Collabora blog) by james
Parent article: KernelCI now testing Linux Rust code (Collabora blog)
And how would have your procedure helped?
AFAICS it was case where binary have come from “trusted” source, only contained unwanted content.
Pointless dance which you propose to do for no good reason is not enough to prevent something like that from happening.
They could have easily published all the checksums and PGP signatures if needed.
And version with backdoor would have had them, too.
Again: the whole point of rustup is to keep your rust compiler up-to-date.
If you don't need or want such service — then you wouldn't use rustup in the first place.
If you do need or want such service — then you have to trust rustup providers and it's stupid the add more protection to the installation script than to the payload which said script installs.
Posted Dec 11, 2022 13:02 UTC (Sun)
by ballombe (subscriber, #9523)
[Link] (4 responses)
Posted Dec 11, 2022 13:21 UTC (Sun)
by khim (subscriber, #9252)
[Link] (3 responses)
Security if always about trade-offs. “Everything should come from the distors!” fanboys tend to forget about that. Time required to push update matters, too. What good is you “good source” if you can not obtain what you want/need from it? Yes. At the cost of making it unable to use anything up-to-date. Bad for end-users (coz games and most productivity software), bad for developers (coz up-to-date versions of everything are never there). It's not even clear whether that's a win for security (certainly no one in Rust land would be bothered to think about updating packages as old as you get from Debian), but it's definitely not a good fit for development in any modern language. That's fine. They offer another point on the security/velocity curve. You may like systems where bug fix needs months if not years to be delivered, other people prefer response time measured in minutes. As long as you don't try to impose you rules on other people you may do whatever you want. You can not give others what they need/want, but thanks to the stability offered by Linux kernel and/or GLibC you don't need to - and I'm yet to see any offer which is compatible with normal development-at-trunk approach which would be safer than what
Posted Dec 11, 2022 13:53 UTC (Sun)
by pizza (subscriber, #46)
[Link] (2 responses)
Over the course of my career, I've noticed the folks who complain the loudest about regressions are also the same ones complaining about updates taking too long.
Ask them to prioritize "speed" or "stability", and it will always be the opposite of what they currently have. If "cost" is also included in the mix, they'll _always_ complain that it's not zero.
Posted Dec 11, 2022 14:50 UTC (Sun)
by khim (subscriber, #9252)
[Link] (1 responses)
IOW: some people loudly complain, some people silently suffer. And I'm proud to admit that I complain about both. Why? Because the way to reduce problems with regressions is to make updates less painful! It's not a big deal for me if Even if it's my fault (for using some unstable feature or something) I don't spend too much time on these regressions — because they are limited. On the other hand every time I need to upgrade It's because of false dichotomy. Once upon time MS IE was both a pinnacle of web browsing and epitome of stability. There was very stable steam of articles (and even books!) which described its various bugs and deficiences. Today that literature genre have mostly dried up: if something is crazy bad then you report it and it's easier fixed or, at least, acknowledged. I don't perceive it as a problem, although some people miss time where they both needed to collect pile of hacks needed for MS IE 6 and could afford to collect such pile because MS IE 6 was destined to stay with us for decade or more. Again: they are no saying anything others are not thinking, do they?
Posted Dec 11, 2022 17:31 UTC (Sun)
by pizza (subscriber, #46)
[Link]
Those were never simultaneously true. I'm not sure if the former was _ever_ true in anyone's eyes but Microsoft's.
> Again: they are no saying anything others are not thinking, do they?
They're not willing to acknowledge, much less pay for, the price of what they want.
KernelCI now testing Linux Rust code (Collabora blog)
Linux distributions provide that. A private update service does not and neither the curl | sh dance.
KernelCI now testing Linux Rust code (Collabora blog)
rustup offers.KernelCI now testing Linux Rust code (Collabora blog)
> Over the course of my career, I've noticed the folks who complain the loudest about regressions are also the same ones complaining about updates taking too long.
KernelCI now testing Linux Rust code (Collabora blog)
rustc or any other fast-moving component intermittently regresses: I just report the issue, roll it back for a few days and after few days (if regression is fault on the rustc side) everything is fixed.gcc or debian or any other project which releases updates once a year or, even worse, once per 2-3 years… it's a pain: regressions are numerous, I hit them all at once and even if each one, individually is “not a big deal”… cumulatively they are a problem.KernelCI now testing Linux Rust code (Collabora blog)