Go- and Rust-based packages
- Login o registrati per inviare commenti
"There are some packages where Debian cannot promise to provide minimal backports for security issues. These are covered in the following subsections.
[...]
5.2.1.2. Go- and Rust-based packages
The Debian infrastructure currently has problems with rebuilding packages of types that systematically use static linking. With the growth of the Go and Rust ecosystems it means that these packages will be covered by limited security support until the infrastructure is improved to deal with them maintainably.
In most cases if updates are warranted for Go or Rust development libraries, they will only be released via regular point releases."
More work to do is fair price to pay for security of Rust, even governments state C, C++ and other insecure languages need abolished in favor of Rust.
https://www.infoworld.com/article/2336216/white-house-urges-developers-to-dump-c-and-c.html
Oh, I see. You and the White House will pay that extra price and do that extra work. Problem solved.
I am a translator!
I recently wanted to try using https://github.com/mrusme/neonmodem (discourse client).
I did git clone it, went offline and tried compiling it. The compilation failed quickly as it was trying to fetch something from an external repository. Searching further, I found a file discourse.go with signatures for 319 things that I assume need to be fetched.
Does that mean that, to make a package of this, and ensure that source are available, one would have to fetch the sources for these 319 things, possibly make a package of each of them, and, possibly of any other thing that these 319 things might need? Possibly, this would mean providing as package all of what is in the go repository, which looks like a very heavy task. Is it what is actually needed?
Then, is the problem of maintenance raised by the Debian team about static linking related to this? Does static linking mean that all the dependencies are included in every binary, so that any update in one dependency requires to regenerate all the binaries? Is there no way with go to make dynamic linking?
I am not asking about rust because I have not had to deal with anything written in rust yet.
> Does static linking mean that all the dependencies are included in every binary, so that any update in one dependency requires to regenerate all the binaries?
Yes, you need to compile everything again whenever a linked library has been modified, or if you want to link to a different library. It is not an impossible task, but it is easier said than done, and it means that bugs may take longer to be fixed downstream, let alone backported. This is precisely what the Debian release notes are saying, specifically about security updates.
Isn't the reason people developed rust to prevent certain mistakes from being made that you can easily make in programming C language?
If so, it sounds like training wheels for developers.
Wouldn't it just be better to get developers who are experts at c programming instead?
You can disagree if you want, but I don't understand that to be a problem of C and C++.
I think that is a problem of people not being good enough at coding.
Just my twocents prospero and others.
Isn't the reason people invented lighters to ease the making of fire?
If so, it looks like training wheels for fire makers.
Wouldn't it just be better to get people who are experts at rubbing two sticks together?
You can disagree if you want, but I don't understand that to be a problem with stick rubbing.
I think that is a problem of people not being good enough at rubbing.
That is a fair point. I still don't think C and C++ are anymore insecure than rust.
The only difference is that the guardrails on rust are more obvious personally.
But yeah, lighters were made to ease fire making.
I think replacing debian package mantainers with an AI programmed in rust would be the simplest solution.