[pdonis]

> This isn't any less "broken" than painstakingly adding third-party repositories when your package happens to not be maintained.

True, it isn't any less broken than that; it's more broken.

First, adding a third-party repository, and then using your distro's GUI package manager to install an app from that repository, is a lot more work for the average user than clicking on a download link and then dragging the downloaded file to your desktop (or clicking on it to open it and start an install process). That's by design: it should take some work on the user's part to download and install software that hasn't been vetted by their distro. Greatly reducing that work, as Flatpak does, is a bug, not a feature. (See further comments below.)

Second, third party repositories don't promise that their apps are sandboxed; a binary from a third-party repo has the same privileges as any other binary from the distro. Users aren't being told that the third party apps are "more secure". Promising that your apps are sandboxed means they need to actually be sandboxed; disabling the sandbox with default privilege settings breaks that promise. So users get less security than they think they are getting with this model.

> Linux is secure because nobody can ship software on it without going through massive hurdles

Really? Then why are there thousands of open source applications in my distro's package manager? (And that's without installing any third party repositories.)

> everybody who is smart enough to install software on Linux does some diligence.

Nothing can protect a user who is not smart enough to do some due diligence before installing software. So setting up the system to require some due diligence seems like a better idea than removing the due diligence just because users will find that easier, and then claiming that you can still provide security.

[linuxftw]

> is a lot more work for the average user than clicking on a download link and then dragging the downloaded file to your desktop (or clicking on it to open it and start an install process).

You can totally download binaries from the internet and execute them if they don't require libraries (if the binary even needs any libraries, ie not statically compiled).

You can also download a .sh installer and execute that to install software, it can even create an icon on your desktop (if you even still have one of those that has icons ;) ). Unfortunately, there's a ton of software that installs like this on Linux.

Edit: Grammar

[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.

[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.