[pdonis]

I agree there's a ton of software out there that wants you to install it this way, not just on Linux but on any OS. My point is simply that I, as a user, am never going to use software that wants me to install it this way. The extra work involved in setting up secure distribution is a feature, not a bug.

[zeroname]

> My point is simply that I, as a user, am never going to use software that wants me to install it this way.

I, as a developer, am not sure I care. It's tough for me to care about Linux in the first place (you guys are picky!), but let's say I went through the trouble of maintaining multiple third-party repositories for major distributions, how exactly is that more secure from your perspective? You still have to trust that I don't ship malicious binaries, just as if you just had downloaded the package from my website. Worse yet, you also trust that I maintain all these repositories securely, which means a bigger attack surface for you.

> The extra work involved in setting up secure distribution is a feature, not a bug.

Except it isn't really secure from a technical perspective, it's literally just more work.

[pdonis]

> I, as a developer, am not sure I care.

I'm not saying you have to care. If your software is so good that I need to have it, then either my distro will have it, or you'll have set up some kind of distribution infrastructure that I can use securely, or, if I have to, I'll download your source code and build it myself. OTOH, if I don't need your software, and it's not easily available to me securely through my distro, then I just won't use it.

> It's tough for me to care about Linux in the first place (you guys are picky!),

Yep, I sure am. I have to be picky to keep my information secure. Most people don't seem to care about that, which is why they're not as picky as I am. Sooner or later it will bite them.

> let's say I went through the trouble of maintaining multiple third-party repositories for major distributions, how exactly is that more secure from your perspective? You still have to trust that I don't ship malicious binaries, just as if you just had downloaded the package from my website.

If I'm getting binaries from you directly (instead of from my distro's maintainers, who are building binaries from your open source code), then yes, I have to trust them. If downloading them from your website is the only way you'll give them to me, and your software is so good that I need to have it, then I'll end up downloading them from your website. So far, the set of software that is so good I'm willing to do that, and which forces me to do that by giving me no other alternative, is empty.

Also, even supposing downloading from your website is the only alternative you give me, to do that securely, you'll have to use HTTPS, you'll have to sign your binaries with a public key I trust, you'll have to provide signed hashes so I can verify the download, etc.--in other words, all the stuff you'd have to do if you maintained a third-party PPA. The software that is so good that I'd be willing to download it from your website without all those precautions is not only empty, it is inconceivable to me that it will ever be anything other than empty (whereas I can at least conceive it being possible that somebody, sometime, will write software that's so good that I'll go to their website to download, with all of those precautions, if given no other option).

And also again, if you don't supply a third-party PPA that my distro's package manager can pull updates from automatically, how are you going to ship me updates? Are you going to ask me to go to your website every time? Or are you going to reinvent, poorly, the packaging and updating infrastructure that has already been field tested for years by distros?

[TimJYoung]

"Also, even supposing downloading from your website is the only alternative you give me, to do that securely, you'll have to use HTTPS, you'll have to sign your binaries with a public key I trust, you'll have to provide signed hashes so I can verify the download, etc.--in other words, all the stuff you'd have to do if you maintained a third-party PPA."

This is how most professional Windows desktop software is distributed today. Also, you don't need a signed hash if the binaries are code-signed - you can verify that they haven't been tampered with by simply right-clicking on the binary and looking at the cert/SHA-1/SHA-2 signatures.

[zeroname]

> ...then I just won't use it.

So far, that seems like a very reasonable compromise for both of us.

> Yep, I sure am. I have to be picky to keep my information secure. Most people don't seem to care about that, which is why they're not as picky as I am. Sooner or later it will bite them.

I don't see your point. If it's about Microsoft's data collection, that's orthogonal to how software distribution works. Otherwise, there's no reason to trust the competence of Canonical or RedHat employees (or even volunteers for other distros) over those of Apple or Microsoft. Either one can mess up, either one can expose your system.

> Also, even supposing downloading from your website is the only alternative you give me, to do that securely, you'll have to use HTTPS, you'll have to sign your binaries with a public key I trust, you'll have to provide signed hashes so I can verify the download, etc.--in other words, all the stuff you'd have to do if you maintained a third-party PPA.

It doesn't stop at PPA, to really support all the other picky Linux guys with their distributions I need to provide dozens of packages built against the dependencies of whichever versions of those distributions are currently in use. That's the actual problem Flatpak is solving. If there was one package format that worked everywhere, it would be a different story. You can trivially download and install (compatible) deb or rpm files as well, why aren't you lamenting that being a security issue?

> And also again, if you don't supply a third-party PPA that my distro's package manager can pull updates from automatically, how are you going to ship me updates?

Your distribution could integrate Flatpak updates into its update mechanism, or you can run them manually or as a cron job.

> Or are you going to reinvent, poorly, the packaging and updating infrastructure that has already been field tested for years by distros?

Personally, the amount of times that this "packaging and updating infrastructure" has broken working applications or whole Linux installations leads me to believe that no amount of testing will ever make it work reliably. On the other hand, the software that has all its dependencies in one place, where an update consists of overwriting or replacing the installation directory, has rarely failed. On Windows, this is called "portable", on Mac OS, this is simply a regular application.

[linuxftw]

> Personally, the amount of times that this "packaging and updating infrastructure" has broken working applications or whole Linux installations leads me to believe that no amount of testing will ever make it work reliably.

What distributions have you been using? I rarely have a problem with Debian or Fedora in this manner.

> It doesn't stop at PPA, to really support all the other picky Linux guys with their distributions I need to provide dozens of packages built against the dependencies of whichever versions of those distributions are currently in use.

Get your package into Debian and Fedora, other distros might pick it up. If your software is popular enough, someone might volunteer to do the packaging for you. If it's something I care about and not available, I'll compile it (if it's a compiled language). If it's something I care about and it needs to go into production, I'd build and maintain my own rpms or debs internally.

[zeroname]

> What distributions have you been using? I rarely have a problem with Debian or Fedora in this manner.

Fedora and especially Arch are big offenders. Debian is so "stable" that I can't install newer software through the provided packages anyway, so that's trading off one failure over another.

> Get your package into Debian and Fedora...

If you stay inside the FOSS bubble, of course maybe some maintainer will eventually spend their precious time packaging some version of your application in some (sometimes broken) fashion. I don't think that's a good solution even for FOSS, but for non-FOSS it's not even on the table.

[linuxftw]

> Debian is so "stable" that I can't install newer software through the provided packages anyway, so that's trading off one failure over another.

I've already addressed this, it's pretty trivial to recompile most major software packages. You can also pull those packages from testing or unstable.

> but for non-FOSS it's not even on the table.

Sucks to be a proprietary software vendor. You have to do all this hard work for people to not buy your product anyway.

[pdonis]

> there's no reason to trust the competence of Canonical or RedHat employees (or even volunteers for other distros) over those of Apple or Microsoft.

Yes, there is: Apple and Microsoft have broken people's systems, and leaked their data, multiple times. Microsoft has even shipped virus infected CD-ROMs to customers. RedHat and Canonical have not done those things. So their track record is much better.

> It doesn't stop at PPA, to really support all the other picky Linux guys with their distributions I need to...

You only need to do all that stuff if you insist on providing your own binaries. But the whole point of each distro having its own packaging system is that the distro builds the binaries and packages them. You, the upstream developer, just provide your open source code.

> Personally, the amount of times that this "packaging and updating infrastructure" has broken working applications or whole Linux installations leads me to believe that no amount of testing will ever make it work reliably.

I've never had this problem, so we apparently have had very different experiences.