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."
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.
I don't think that rust is a silver bullet. There will always be newer programming languages coming out. Some will have promises like memory safeness, but that doesn't mean you should necessarily write all previous code in that language.
What is your favorite programming language?
To be honest, I like programming languages that are fast and efficient but non-bloated like C and C++.
But not because I know much of any, but because I can trust they won't be overly bloated.
My belief is that bloated programming languages are a time bomb for stability and security.
Some will of course disagree with this thinking, but that is how I think. Its the same reason I try to use GNU/Linux distros that are less bloated like Hyperbola. Devuan is another one I use as a next best thing, but I disable all proprietary repos if I intend to use it as a computer where I desire privacy/security which is just about all of them, except maybe one.
Its not the systemd thing that some care about, it goes well beyond that. Java is also huge as well and I don't trust it even more than rust by like 10000% and also because it has been hacked before due to the Log2shell for example and possibly other vulnerabilities.
But yeah, you could say some of it is definitely paranoia. That's also why some jumped the ship of proprietary operating systems. Although, there is reasonable evidence for the insecurities of proprietary operating systems in general.
Long winded answer done