8 ms·

I'm not sure distro needs to "maintain" N versions. The distro maintain 1, but all N remain available and able to fulfill the dependencies of the underlying ap

I'm not sure distro needs to "maintain" N versions. The distro maintain 1, but all N remain available and able to fulfill the dependencies of the underlying application It's not the distro's job to ensure the application is secure and up to date, its up to the application packager (i.e. docker container maintainer) to do that. i.e. to rev new releases of the application image even if nothing has changed in the core app, just to take care of security updates in distro provided packages). In pr

cuu508 4y ago
> It's not the distro's job to ensure the application is secure and up to date I would prefer a distro that ensures applications in its repository are up to date. Consider a log4j-type issue. In one case, the distro quickly fixes the vulnerability in a library package, the user installs the update and that is that. In the other case, the user has to track down which installed applications use the affected library, update them if there is an update available, and figure out what to do if there is no update available.
- josephg 4y ago
  > Consider a log4j-type issue. … the user installs the update and that is that. I hear what you’re saying. But - I’ve been writing a lot of rust lately. For better and worse, most rust programs pull in dozens of crates as direct or transitive dependencies. Apt isn’t up to the task of replacing cargo: - Apt’s dynamic library mechanism is designed around C’s dynamic library support. This doesn’t work with many other languages. It certainly doesn’t work with rust, which doesn’t have an ABI. - There are too many rust packages, and they update too frequently for apt to keep up. Apt could be a bad, out of date, partial clone of cargo. But that sounds worse than cargo in every way. - Shipping deps with cargo (or whatever) is preferred by app developers because cargo is better integrated with the language. And it works reliably on every platform. A dpkg wouldn’t even work on every version of Debian. We have a similar problem with ruby gems, nodejs packages (in npm), etc etc. I could imagine apt wrapping cargo, npm, and friends and providing equivalent functionality. But the authors of apt seem to think it’s already good enough. It’s not. Cargo, npm, and friends run rings around apt from the point of view of developer mindshare, ease of use, platform independent packaging, and so on. Apt and friends don’t have the features we want, and all the browbeating in the world won’t change that.
  - JohnFen 4y ago
    > There are too many rust packages, and they update too frequently for apt to keep up. That sounds like a pretty large downside to using Rust.
    - josephg 4y ago
      Having a large, healthy ecosystem of well maintained 3rd party packages is a delight.
  - pabs3 4y ago
    Rust has dynamic linking and a symbol name mangling ABI now and it is potentially useful enough that distros could use it. https://wiki.debian.org/StaticLinking#Rust https://wiki.debian.org/StaticLinking#Rust https://github.com/rust-lang/rfcs/pull/2603 https://github.com/rust-lang/rfcs/pull/2603 https://github.com/rust-lang/rust/issues/60705 https://github.com/rust-lang/rust/issues/60705
    - josephg 4y ago
      The symbol mangling ABI isn't considered stable yet. And even if it was stable, rust's struct packing is still compiler-defined. Rust libraries can be dynamically linked if they look like a C library, or get wrapped by abi_stable[1] or something. But this isn't the standard. Probably less than 5% of the crate ecosystem is packaged like this. And a 5% solution is nowhere near good enough. Right now, I can build any rust package on any system, no matter what dependencies it has by just running cargo build. For apt to be competitive, it'd need to pull the ~100k cargo packages into apt's repository, wrap all of them in abi_stable or some equivalent and parse Cargo.toml files into the equivalent dpkg config. Ideally it should also work across every OS (though starting with ubuntu, debian and mint would be a start). This is possible. But for all the hand wringing about how modern packages should use apt, nobody seems to actually care enough to make any of this happen. [1] https://crates.io/crates/abi_stable https://crates.io/crates/abi_stable
      - pabs3 4y ago
- robertlagrant 4y ago
  I don't think distros are going to be fixing vulnerabilities in all their packages. Is that what you mean?
  - cuu508 4y ago
    Yes, that is what I mean.
    - phkahler 4y ago
      That's not really their job. For log4j they could update that package. Any app that breaks as a result needs to be fixed upstream anyway, and then the distro can rebuild that. Fixes like that do get through the process, but it's not specifically the distros job to fix it. These problems are all about dependencies, which fall to upstream to make managable. If your favorite app breaks all the time it's probably because the code base is a giant mess. Oh, and some of the mess comes from too many different licenses in use, which prevents tighter integration of source code.
      - ticviking 4y ago
        That is the entire value dynamic linking and a stable ABI and API provide me. The ability to seamlessly replace an updated dependency by restarting an application and loading the library. If I'm just going to completely rebuild the app and all of it's dependencies I may as well statically link them and get the unique optimizations we can do after link time by analyzing the resulting executable.
      - cuu508 4y ago
        It's up to the distro to define what their job is. As I said, I prefer distros that proactively patch security issues regardless of what upstream does :-)
        robertlagrant 4y ago
        Point being a log4j issue would be downstream of the distro, not upstream.
- compsciphd 4y ago
  applications in the distro should be up to date by simply being in the distro in that case, i.e. we are more talking about applications that are outside the distro and installed on top of it. Because we have dependency issues, containerization is a good method. anything the distro ships itself should always be using the latest of everything the distro ships.
nine_k 4y ago
A distro often has to maintain more than one version of a,library: consider Debian stable, oldstable, and backports.
goodpoint 4y ago
> It's not the distro's job to ensure the application is secure and up to date On the contrary, it's the most important feature of distributions.
- compsciphd 4y ago
  so you install Oracle on a Debian installation, it's Debian's job to ensure Oracle is secure? I'm not talking applications provided by the distribution, those aren't "applications" (i.e. in my usage, something installed onto an existent operating system), but part of the provided operating system itself, and yes, I'd agree it's their job to keep their provided operating system secure. It's not their job to keep external apps secure (but to provide the means for whoever is maintaining those apps to keep them secure).
  - goodpoint 4y ago
    > those aren't "applications" ...
  - JohnFen 4y ago
    With Linux, anyway, the operating system is just the kernel. Everything else is an application.

cuu508 4y ago

> It's not the distro's job to ensure the application is secure and up to date I would prefer a distro that ensures applications in its repository are up to date. Consider a log4j-type issue. In one case, the distro quickly fixes the vulnerability in a library package, the user installs the update and that is that. In the other case, the user has to track down which installed applications use the affected library, update them if there is an update available, and figure out what to do if there is no update available.

josephg 4y ago
> Consider a log4j-type issue. … the user installs the update and that is that. I hear what you’re saying. But - I’ve been writing a lot of rust lately. For better and worse, most rust programs pull in dozens of crates as direct or transitive dependencies. Apt isn’t up to the task of replacing cargo: - Apt’s dynamic library mechanism is designed around C’s dynamic library support. This doesn’t work with many other languages. It certainly doesn’t work with rust, which doesn’t have an ABI. - There are too many rust packages, and they update too frequently for apt to keep up. Apt could be a bad, out of date, partial clone of cargo. But that sounds worse than cargo in every way. - Shipping deps with cargo (or whatever) is preferred by app developers because cargo is better integrated with the language. And it works reliably on every platform. A dpkg wouldn’t even work on every version of Debian. We have a similar problem with ruby gems, nodejs packages (in npm), etc etc. I could imagine apt wrapping cargo, npm, and friends and providing equivalent functionality. But the authors of apt seem to think it’s already good enough. It’s not. Cargo, npm, and friends run rings around apt from the point of view of developer mindshare, ease of use, platform independent packaging, and so on. Apt and friends don’t have the features we want, and all the browbeating in the world won’t change that.
- JohnFen 4y ago
  > There are too many rust packages, and they update too frequently for apt to keep up. That sounds like a pretty large downside to using Rust.
  - josephg 4y ago
    Having a large, healthy ecosystem of well maintained 3rd party packages is a delight.
- pabs3 4y ago
  Rust has dynamic linking and a symbol name mangling ABI now and it is potentially useful enough that distros could use it. https://wiki.debian.org/StaticLinking#Rust https://wiki.debian.org/StaticLinking#Rust https://github.com/rust-lang/rfcs/pull/2603 https://github.com/rust-lang/rfcs/pull/2603 https://github.com/rust-lang/rust/issues/60705 https://github.com/rust-lang/rust/issues/60705
  - josephg 4y ago
    The symbol mangling ABI isn't considered stable yet. And even if it was stable, rust's struct packing is still compiler-defined. Rust libraries can be dynamically linked if they look like a C library, or get wrapped by abi_stable[1] or something. But this isn't the standard. Probably less than 5% of the crate ecosystem is packaged like this. And a 5% solution is nowhere near good enough. Right now, I can build any rust package on any system, no matter what dependencies it has by just running cargo build. For apt to be competitive, it'd need to pull the ~100k cargo packages into apt's repository, wrap all of them in abi_stable or some equivalent and parse Cargo.toml files into the equivalent dpkg config. Ideally it should also work across every OS (though starting with ubuntu, debian and mint would be a start). This is possible. But for all the hand wringing about how modern packages should use apt, nobody seems to actually care enough to make any of this happen. [1] https://crates.io/crates/abi_stable https://crates.io/crates/abi_stable
    - pabs3 4y ago
robertlagrant 4y ago
I don't think distros are going to be fixing vulnerabilities in all their packages. Is that what you mean?
- cuu508 4y ago
  Yes, that is what I mean.
  - phkahler 4y ago
    That's not really their job. For log4j they could update that package. Any app that breaks as a result needs to be fixed upstream anyway, and then the distro can rebuild that. Fixes like that do get through the process, but it's not specifically the distros job to fix it. These problems are all about dependencies, which fall to upstream to make managable. If your favorite app breaks all the time it's probably because the code base is a giant mess. Oh, and some of the mess comes from too many different licenses in use, which prevents tighter integration of source code.
    - ticviking 4y ago
      That is the entire value dynamic linking and a stable ABI and API provide me. The ability to seamlessly replace an updated dependency by restarting an application and loading the library. If I'm just going to completely rebuild the app and all of it's dependencies I may as well statically link them and get the unique optimizations we can do after link time by analyzing the resulting executable.
    - cuu508 4y ago
      It's up to the distro to define what their job is. As I said, I prefer distros that proactively patch security issues regardless of what upstream does :-)
      - robertlagrant 4y ago
        Point being a log4j issue would be downstream of the distro, not upstream.
compsciphd 4y ago
applications in the distro should be up to date by simply being in the distro in that case, i.e. we are more talking about applications that are outside the distro and installed on top of it. Because we have dependency issues, containerization is a good method. anything the distro ships itself should always be using the latest of everything the distro ships.

nine_k 4y ago

A distro often has to maintain more than one version of a,library: consider Debian stable, oldstable, and backports.

goodpoint 4y ago

> It's not the distro's job to ensure the application is secure and up to date On the contrary, it's the most important feature of distributions.

compsciphd 4y ago
so you install Oracle on a Debian installation, it's Debian's job to ensure Oracle is secure? I'm not talking applications provided by the distribution, those aren't "applications" (i.e. in my usage, something installed onto an existent operating system), but part of the provided operating system itself, and yes, I'd agree it's their job to keep their provided operating system secure. It's not their job to keep external apps secure (but to provide the means for whoever is maintaining those apps to keep them secure).
- goodpoint 4y ago
  > those aren't "applications" ...
- JohnFen 4y ago
  With Linux, anyway, the operating system is just the kernel. Everything else is an application.