[vanderZwan]

> Sadly, it's obvious Red Hat developers working on flatpak do not care about security, yet the self-proclaimed goal is to replace desktop application distribution - a cornerstone of linux security.

Sheesh, while the issues raised are all valid, this does not actually justify such a conclusion about the intent of the Red Hat developers. Telling people what their side of the story is for them in a dismissive fashion like this is not going to make it more likely that they admit their mistakes.

A bit of Hanlon's Razor[0] goes a long way to resolve problems involving human cooperation (of any kind) more smoothly.

[0] https://en.wikipedia.org/wiki/Hanlon%27s_razor

[kilburn]

> A bit of Hanlon's Razor[0] goes a long way to resolve problems involving human cooperation (of any kind) more smoothly.

I don't like the snarky tone of the article, but I really thing you're being naive here. Let's examine the facts:

- Flatpak's intent is clear and stated first in in their homepage [1]: "Flatpak is a next-generation technology for building and distributing desktop applications on Linux"

- Red Hat is the company other companies hire to manage their linux systems.

- In the flatpak homepage there's a huge quote stating "The Fedora Workstation team are very excited about Flatpak and the prospects it brings for making the Linux desktop easier to develop for. We plan to continue supporting this effort going forward."

- The FAQ page states "We are explicitly using many features of the linux kernel (bind mounts, namespaces, seccomp, etc) to create the sandbox that Flatpak apps are running in." ... and then it turns out that they aren't, or at least they aren't enforcing it.

I don't think this is stupidity. This is flat out lying to try and get mindshare.

[gbraad]

Fedora and Red Hat are not the same thing. Sure, there is a relation between the two, but inclusion in Fedora is not an endorsement or guaranteed inclusion in RHEL.

I just wonder why the author of this page does not disclose his name... And even hides this from the whois info. This could have been written by a person with a grudge for all I am concerned.

Sure, improvements might be needed, but haa the author tried to get this happen in a different way, like a discussion? Creating a webpage and scream fire is not the best approach in my opinion.

The issue raised about security updates for packaged apps is the same as for container images and packages like .deb or .rpm in general. Generating a runtime is a possible solution? Something like an automated way to regenrate packages is needed, like flathub?!?

[dpwm]

> I just wonder why the author of this page does not disclose his name...

> And even hides this from the whois info.

The registrant country is listed as France and the registrar is OVH. They are simply adhering to the GDPR. I have domains that have been like this since May, even though I would be quite happy to have everything public.

> This could have been written by a person with a grudge for all I am concerned.

Your comment could have been written by somebody with a grudge against the person you are claiming could have had a grudge for all I am concerned. A vested interest can make a difference, but I don't really see how any of the points are hard to verify.

Does this being written by a person with a grudge really negate the points made?

- Flatpak is claiming to be secure

- Flatpak is sandboxing apps with full access to your home directory.

(What is the worst thing that an app can do? Nuke your home directory or run malicious software. The sandboxing here does little to mitigate this.)

- Apps are not being updated as quickly as their distribution repository counterparts.

- At some point in its past, a (presumably) privileged component with permissions to setuid did not check that it wasn't blindly copying setuid.

It seems to me that this is more about easy delivery of software with a security claim that is arguably pretty weak at the moment against likely attack vectors. I can't see that changing without first thinking of what you're actually sandboxing for.

There are already software delivery systems, such as 0install and appimage, that do not make claims about being sandboxed and yet provide a similar (or greater in the setuid case) level of security for the main threats.

I find it hard to understand who the project is for. If you're a developer on your own machine then using your distro's package manager is probably more secure. If you're a sysadmin, letting users use flatpak serves only to increase the attack surface for privilege escalation.

[toyg]

The problem is that distro package managers are many and often complex to satisfy, which is one of the reasons people don’t develop “real” desktop software for Linux.

The new generation of installers (flatpak, snap etc) takes a cross-distro approach that is supposed to result, more or less, in “package once, run everywhere”: you build your app in a certain way and every distro should be able to run it, regardless of package managers. It’s basically a way to offload the compatibility headaches to flatpak developers and distribution builders.

Obviously that approach works only if flatpak does actually get good support in all distributions and becomes a de-facto standard, which is a challenge because there are many competitors (Ubuntu Snap being the most relevant one). If it remains just a glorified rpm (i.e. a redhat-specific tool), then there is no point.

[dpwm]

> The problem is that distro package managers are many and often complex to satisfy, which is one of the reasons people don’t develop “real” desktop software for Linux.

If by real you mean the kind of proprietary {ad,spy,toolbar}-ware encrusted "real" desktop software that Windows has become notorious for then I think we may be better off without it. If you're talking about OSX, then I think you're missing that it's a market skewed towards those with the money and will to pay for proprietary software. Plenty of people are developing "real" desktop software for Linux.

> The new generation of installers (flatpak, snap etc) takes a cross-distro approach that is supposed to result, more or less, in “package once, run everywhere”: you build your app in a certain way and every distro should be able to run it, regardless of package managers. It’s basically a way to offload the compatibility headaches to flatpak developers and distribution builders.

This isn't novel. 0install and AppImage have been around for a while now. What is novel is that Flatpak combines this with sandboxing that doesn't really do so much to mitigate against any vulnerabilities that aren't in the kernel. I actually think they've got the sandboxing right, in that they are really starting with minimum privileges and adding only what is needed.[0] The problem, as they state, is that it is fine to drop all privileges for something like a single-player game, but it sucks for a file manager. At least according to their wiki, they're already doing most of what you could imagine you could improve on the sandboxing. [0]

It's always this interaction with the outside world that breaks sandboxing. It's rather easy to make a sandbox that runs as nobody and has no privileges and no capabilities and no file access. It's a bit harder to make something which has any of those things in a way which the user can grant sensible permissions.

It sounds like in Portals [1] the Flatpak team have gone in pretty much the only workable direction, although the Wiki is hopefully out of date and there are more portals. The problem they will have found is that to package anything useful and get feedback and validation requires that they implement the most difficult bits first. So I suspect the situation is "secure file picker is coming".

Sandboxing is a lot of work, not in the closing down but in the opening up. One of the more innovative approaches is to be found in Sandstorm [2]. Although marketed as a way to run web applications on your own server easily, it is actually a tight sandbox built on top of Cap'n Proto, which means that E-style capability-based RPC is intrinsic.

Sandboxed apps have no access to anything, cutting down on kernel attack space. The only connection to the outside world is through a UNIX socket file descriptor opened by the supervisor. The capabilities-based security model mean that a sandboxed app could request the ability to connect to "drive.google.com", or even a specific URL. This could also be passed to other apps through the supervisor, subject to user approval. Capabilities can be stored on disk to be later restored from the supervisor.

In Sandstorm the UI for granting capabilities between apps is working, but progress has slowed as the team have all had to find other ways to pay the bills.

> Obviously that approach works only if flatpak does actually get good support in all distributions and becomes a de-facto standard, which is a challenge because there are many competitors (Ubuntu Snap being the most relevant one). If it remains just a glorified rpm (i.e. a redhat-specific tool), then there is no point.

I think the problem is that if your target is casual users, they're not going to necessarily understand the nuances and limitations of the sandboxing.

[0] https://github.com/flatpak/flatpak/wiki/Sandbox

[1] https://github.com/flatpak/flatpak/wiki/Portals

[2] https://sandstorm.io/how-it-works#capabilities

[TimJYoung]

"If by real you mean the kind of proprietary {ad,spy,toolbar}-ware encrusted "real" desktop software that Windows has become notorious for then I think we may be better off without it."

You're ignoring a huge amount of business software that is created for, and runs on, Windows. That's like judging Android or iOS based upon the consumer crapware that gets sold/given away in their app stores, as opposed to the many business apps that are used to automate and improve all sorts of tasks on mobile devices.

I keep seeing this pattern repeated over and over again: someone (this has been me, several times) mentions on HN that Linux needs a better way to allow for binaries to be dropped on a system and run without requiring re-compilation or overly-complicated containers/sandboxes, and the answers invariably end up being "don't want it, don't care". But, the reality is that there are a very large number of people that would jump to Linux in a heartbeat if they could target the OS for distribution in that fashion. It just seems like a bunch of ideology run amok with zero thought given to the actual needs of professional developers/companies. And, there's a lot of evidence that this is one of the primary things holding back Linux adoption on the desktop.

The rest of your reply was very informative, thanks.

[finchisko]

I like what Microsoft did in UWP. App is allowed to read own files, files explicitly selected by user from Open Dialog. For anything else app developer has to ask for permission and user has to approve it (like in iOS, Android....). Specially the second option is nice, because you as user have a choice to grant access only for specific files and dirs you want app to have the access.

[gbraad]

Flatpak does not claim to be secure. This is also clearly stated in the FAQ. They provide a means of separation of applications. Sandboxing is not per se a form of security, just like this was with Docker in the 'early days'.

[syshum]

>>I just wonder why the author of this page does not disclose his name...

That is a weak argument to rebut the article. The author should not matter only the facts

Either what this person has claimed about Flatpak is true, or it is not

You do not need the persons name, address, and background to form that conclusion.

The only reason to demand that is to exert public pressure on them likely in an effort to silence them. Anonymous Speech is a cornerstone of a free society

[alxlaz]

> This could have been written by a person with a grudge for all I am concerned.

Or by a person who does not wish to be on a no-hire list. The job market for Linux developers working on this sort of stuff is not exactly enormous.

[mfukar]

> This could have been written by a person with a grudge for all I am concerned.

So glad that you can judge his points regardless of that irrelevant information, then.

[gbraad]

Nowhere on the page they claim to be secure. See also the https://flatpak.org/faq/. they are aware that security benefits at the moment are at a minimum.

Perhaps the term 'sandboxing'is being misunderstood as it was with docker. This is not per se a means of providing security.

[vanderZwan]

I'm going to stay a on the meta-discussions level for a bit (all other points in this debate have already been made anyway). Hanlon's Razor is about assuming intent, about railroading others into perceived roles. You bring up interesting points, but they were not part of the article we are responding to. The conclusion was supposed to follow from the earlier arguments given. Within that context there is a big assumption being made.

So what am I being naive about, exactly? Note that I have merely called out the assumptions made by others. I have not stated anything about Red Hat's intentions myself, so if I'm being perceived as naive about that, it would be making another assumption. EDIT: I suppose the "mistake" wording does imply good faith behavior. But there too: bad faith should be looked out for, tested for, but not presumed about others.

[TheDong]

> The FAQ page states "We are explicitly using many features of the linux kernel (bind mounts, namespaces, seccomp, etc) to create the sandbox that Flatpak apps are running in." ... and then it turns out that they aren't, or at least they aren't enforcing it

They are using those features. flatpak has network namespaces for applications that don't need access to the network and bindmounts for applications that use very limited parts of the filesystem.

Sure, in reality many desktop apps have more far-reaching permissions, but all they're saying is that flatpak can make use of those features in some cases.

> This is flat out lying to try and get mindshare

Usually that's just called marketing. I don't think any of the above statements are actually lies in any way though. Can you point to what's actually a lie, or what lie is implied in your mind?

[jessaustin]

The part where they say it's a sandbox, and it doesn't even attempt to be a sandbox. That's a lie.

[derefr]

It's a sandbox like Android has a sandbox: each app lists a set of capabilities; the user gets a dialogue on installation where they have to grant those capabilities (or else cancel the install); and then for anything the app tries to do that's not in that set of capabilities, it fails.

A sandbox doesn't mean "you can never do [foo]." A sandbox means "you can never doo [foo] unless the user lets you." Even web browsers (the classical "true sandboxes") have an API that gets you access to the user's microphone, and another for access to their GPS data. There's just a dialogue in between that the user can say "No" to; and, having said no, the content of the tab can't ask again, and just gets denied automatically. That's what makes it a sandbox.

[jonstewart]

Is it also like Android's "sandbox" in that every application asks for every permission and the only choice is between "no security" and "can't install anything useful" and inures the user to just click "accept" on everything?

[Ndymium]

Android's permission system was overhauled in version 6 so that permissions are now generally asked when they are needed, for a specific type of operation, instead of the big dialog when installing.

I personally use several apps where I have granted one set of permissions and denied another (because it was for a feature I don't use). It has gotten a lot better than what it used to be.

[MayeulC]

For now, the GUIs are as far as I know, but there is a `flatpak override` command that seems promising for changing an installed application's permissions.

[viraptor]

The system is configured to run apps in a sandbox though - that's completely true. It's the app's part that declares: it needs full access to your home directory to work. If that wasn't possible, we'd get people complaining about apps not working as expected instead. The balance may not be currently on the right side, but they don't lie about what's provided.

It's like standard Linux permissions. If you install an app which creates its directories with mode 0777, or install a package which has a suid binary, you don't complain that Linux offers no file access control. That's the author's or packager's fault.

[yzmtf2008]

“Sandbox” and “full access to your home directory” doesn’t compute. That’s literally one of the biggest reasons to sandbox applications.

[michaelmrose]

Nobody wants a packaging system that can't package existing apps not designed to be secure in a useful fashion.

In a traditional app packaged as a deb/rpm the developer releases the source which then must be packaged and made to work with each distribution/platform. If the app is malicious or is sold to someone/compromised by someone who is then you are 100% hosed.

In a flatpak not designed to be properly sandboxed you are in fact no worse off than the alternative deb/rpm situation save that the issue of packing for distribution has been made easier.

It's in fact probably extremely challenging to package all sorts of applications without giving the user the option to provide an individual app elevated permissions.

At best we are relying on the user to decide which app ought to get those permissions.

If you think people can't be trusted to do this then the logical solution is to rely on packagers to decide what belongs in the official repo and keep malicious content out.

[viraptor]

It depends on your use case. If you sandbox tar (for example), you'd do it be removing all network access and a few fancy caps, but you'd leave the rw access to the whole system. (within its standard privileges) If you sandbox netcat, you'd do the opposite: remove all fs access (unless you care about pipes) and leave open networking.

There's nothing about the idea of a sandbox that requires a specific approach.

[untog]

It's true, but I'm not sure how e.g. VS Code would even work on a truly sandboxes environment. There'd be no file browser.

[TheDong]

"sandbox" is an ill defined term, but what flatpak provides fits it perfectly well.

A sandbox is an environment where capabilities can be restricted in a set of ways.

The javascript sandbox lets you manipulate the website and make network requests, but not access arbitrary files.

The flatpak sandbox is configured per-app and can prevent all fs access, all file io (with seccomp), all networking, etc.

The article is simply pointing out that most popular applications do not use the sandbox features well.

That doesn't mean flatpak does not have the sandbox they claim to, merely that it does not mesh well with many popular apps currently.

I still see nothing that merits the word "lie".

[ricardobeat]

The sandbox is there for portability. I don't see a promise of being _more secure_ than other app distribution channels on linux anywhere. Though the packaging & sandboxing model certainly opens a path for improvements in the area.

Is it any less safe than installing something via aptitude or Ubuntu's app store?

[Shorel]

The alternative if using Ubuntu is called Snap. It has a sandbox and it is better implemented, at the very least the part about reading and writing in home dir.

[MayeulC]

As far as I was told, snap sandboxing only works with a specially-patched (and apparmor-enabled) kernel [1], though I am not sure what the current status is.

I would like to know what's better implemented in snap, it seems this is simply a case of most applications requesting a r/w permission in the home directory. It might get complicated sandboxing vs code without that, don't you think? Or at least lead to a subpar user experience.

I am hopeful it will improve, though. Sandboxing needs to become the default.

[1]: https://web.archive.org/web/20170615042616/https://github.co...

Edit: Similar echo here https://news.ycombinator.com/item?id=18180877

[briffle]

Yes, his other major gripe is that the security updates for non-official flatpaks take a while to get security releases out. I have the same problem when I run applications that have an official RPM repo, and a volunteer packages the deb and pushes it to the official Ubuntu/debian repos. The same thing with Alpine Linux packages. Its not a problem with the tech, its a lack of volunteers (or not yet enough adoption by the developers to maintain it)

In fact, it could be nicer if it catches on, as developers won't need to maintain deb files, rpm files, pacman files, etc.

[kilburn]

> his other major gripe is that the security updates for non-official flatpaks

I don't know whether it is true or not, but the author explicitly states that it is the official applications AND runtimes that aren't properly maintained.

> I have the same problem when I run applications that have an official RPM repo, and a volunteer packages the deb and pushes it to the official Ubuntu/debian repos

No you don't, because either (a) the package was not uploaded to the official (main) debian repository or (b) the debian security team is in charge of fixing it if the maintainer is no longer available.

[geofft]

The Debian security team being responsible may help you figure out who to blame, but it doesn't magically help the update actually happen. The Debian security team is a volunteer team, and it's entirely realistic that someone may actually have seen delays in the packages they care about getting security updates. "No you don't" is arrogant - you have no way of knowing that.

[viraptor]

> The Debian security team being responsible may help you figure out who to blame, but it doesn't magically help the update actually happen.

Actually they do. Debian does carry local patches when necessary. It will also backport patches to release in older versions which may not be updated upstream. They literally make the updates happen.

In this case, it's valid to ask - where/when did you see the issue with this working.

[mcguire]

...and, as I recall, that got them in trouble with openssl.

[bananadonkey]

Parent was talking about Debian upstream patches making it into his platform of choice; in this case RHEL/CentOS.

That requires paid/volunteer package maintainers.

[gmueckl]

Most of the issues that are expicitly mentioned are fixable bugs and not fundamental design errors. In the end it seems to come down to poor package repository maintenance, which many repositories for Linux distros suffer from. While I do not like the idea of flatpak very much myself, this criticism seems too harsh to me.

[TheDong]

The fact that many desktop applications need access to $HOME and that $HOME also conveniently provides arbitrary code execution via .bashrc/.profile/etc is kinda fundamentally at odds with doing filesystem sandboxing of desktop apps.

Sure, flatpak isn't making things worse by not being able to fix the fact that desktop users expect to open $HOME/screenshot.png in gimp, but it's also not going to easily fix that.

This is fixable on android / chromeos by specifically having applications request access to data which is isolated from arbitrary code execution (e.g. "user files" which don't include .bashrc). I think flatpak may need to ultimately have a custom file-browser where the user can "share" subsets of files into a sandbox and then patch applications to use that file browser... or to otherwise build a new filesystem abstraction.

Until then, this issue will be tricky to fix. I, of course, agree with your main point that things like updating packages more is fixable and the post is overly harsh and critical of what's effectively "things aren't perfect" with no empathy for how complicated stuff can be.

[microtonal]

This is fixable on android / chromeos by specifically having applications request access to data which is isolated from arbitrary code execution (e.g. "user files" which don't include .bashrc). I think flatpak may need to ultimately have a custom file-browser where the user can "share" subsets of files into a sandbox and then patch applications to use that file browser... or to otherwise build a new filesystem abstraction.

It does have that through portals:

https://github.com/flatpak/xdg-desktop-portal

If you Flatpak a Gtk+ 3 or modern Qt application you get portals for free. E.g. I packaged a Qt application and I am not sharing the home directory - when the user opens a file it uses the Qt/KDE portal (similarly to macOS, ChromeOS, etc.).

As far as I understand the problem is that portals are only available for Gtk+ and recent Qt versions. Some of the applications that the posts mentions use toolkits that probably don't support portals (Java JDK, wxWidgets, etc.).

The situation for Linux is a bit different than e.g. macOS, where practically everything uses Cocoa and Apple could just throw the switch.

So, for applications that do not use vanilla Gtk+ or Qt they still need to make the home directory visible or they would not be Flatpack'able.

[int_19h]

The situation is similar on Win10 (and the approach is also the same - sandbox apps have to use a certain API to invoke the file browser and get access to some files or folders).

But apps that don't do that because they're too old, just don't get access to the Store... or at least they didn't use to. Now you can ship non-sandboxed Win32 apps through the Store, and it doesn't even seem particularly obvious which ones are and which ones aren't. Windows 10 S only lets you install the sandboxed ones, but how many people use that?

So basically Windows couldn't solve that - the users ultimately decided that they care about stuff working as it did more than they did about security. I don't see why it would be any different on Linux.

[microtonal]

I don't see why it would be any different on Linux.

There will always be legacy applications that will stay on old toolkits and they cannot fully benefit from sandboxing.

However, a lot of widely-used Linux applications that are on older toolkits are currently working on upgrades. E.g. Inkscape and The Gimp will be Gtk+3 applications. There are often other carrots, such as proper support for scaling for HiDPI screens, etc.

[rkeene2]

Such views can also be provided by userspace filesystems (fuse, coda, nfs, 9p, etc).

I have a fuse filesystem that shows different users different views of the filesystem, as a basic example.

[gmueckl]

Forcing applications to use a separately defined and maintained file dialog is impractical in my opinion. There are lots of ways in which file access can be presented in a user interface.

The problem is rather caused by filesystem layout conventions. I think that a better solution would be to split user home directories into two classes of files: data (that is, files that the user typically wants to see and work with as part of the normal workflow) and "user profile" kind of stuff (.bashrc, configuration files, etc...) that should be "privileged" and require special access rights. These might require interactive confirmation before write access is granted (similar to the split user accounts in Windows with UAC). However, I wonder if these sets of files can be separated cleanly. Marking files as "privileged" should be doable using extended attributes, though.

[tannhaeuser]

A poor package repository is a consequence of too many packaging formats, and lack of volunteer maintainers, though (I, too, could have made more to help). So coming up with package formats all the time - .deb, .rpm, .apk, Alpine's pm format, pkg, .dmg, flatpack, snap, docker and whatnot - is exactly the problem (cf. https://xkcd.com/927/). Maybe Slackware got it right after all by only building from upstream .tgz source archives. We'll see in a decade or two what software is even remotely in a usable state still.

[derefr]

Those aren't "package formats"; they're different names for a very small set of actual container formats (e.g. tar, zip), with the names there to namespace different incompatible OS file-layout hierarchies and sandboxing technologies.

If it was just about packaging, everyone would just have a build server that creates their binary once and then slams it through https://github.com/jordansissel/fpm.

But there are more fundamental differences between OSes than how the insides of their packages look. The packages are "differently shaped" to prevent you doing something stupid and damaging your OS by installing a package that will spew files in all the wrong places, and rely on classes of protections that aren't there.

[AnIdiotOnTheNet]

Hmm... it's almost like maybe applications shouldn't spew their files all over in the first place, then you wouldn't have to worry about putting them in the wrong places...

[derefr]

If you can tell me what a self-contained equivalent to, say, the libpam package would be, I’m all ears.

Oh, also, a subset of case 2 is: packages that contain servers need to register the server as a service with the OS’s init system, and every OS has its own init system that expects a service definition file in its own distinct format and location.

[AnIdiotOnTheNet]

libpam should be part of the base system, obviously. Like the widget library, ssl, and the display server. It's only really in UNIX world that this separation between "system" and "application" doesn't exist.

[im3w1l]

The reason applications spew files all over the place is because that's how you hook into other systems. Want a man-page? There's a folder for that. Want to autostart? Folder for that. Want your program to be runnable without specifying the full path? Put it in path.

The reason configuration sucks is because we use filesystems, which are necessarily hierarchical, when we should use a more general database.

If we had a table where the first column was "thing to be configured" and the second column was "program" things would be much better. We could query by the first column to get e.g. all programs that want to automatically start, or all programs in path. Or we could query the second column to get all configuration for a given program.

Database people have done a lot of work on how to prevent inconsistent state, and we are stupid for not leveraging that.

[derefr]

> Database people have done a lot of work on how to prevent inconsistent state, and we are stupid for not leveraging that.

It's kind of amusing that on the Windows side, you have a vertical integration between the filesystem (NTFS) and the update mechanism, where any MSI package will actually be installed in a filesystem transaction, such that if you e.g. cut power in the middle of package installation, then your disk will actually have nothing of the package's installed data on it. The transaction failed, and was rolled back.

And yet, even with that fancy tech in place, uninstallers still are manually-written apps that blow away files by explicitly naming them, rather than also taking advantage of these filesystem-level transactions together with some sort of hypothetical transaction WAL log, to reverse what the install did.

[xfer]

> We'll see in a decade or two what software is even remotely in a usable state still.

Most distributions need non-free explicitly enabled, so almost all packages are open source, so it is irrelevant to distro packaging format.

[tannhaeuser]

Open source doesn't ensure it'll even build against new compilers, libs, language runtime, and all the other stuff we're reinventing all the time to keep the hamster wheel spinning. What open source desktop apps are you using that need sandboxing anyway all of the sudden? GIMP, Inkscape, Audacity? Come on.

[voltagex_]

>GIMP, Inkscape, Audacity

Yep - all of those. GIMP has scripting capabilities and exposure to vulnerabilities via image codecs, same as Inkscape, and Audacity could be linked to ffmpeg, which is a huge attack surface.

[WrtCdEvrydy]

> We'll see in a decade or two what software is even remotely in a usable state still.

Fucking none of it, that's your answer.

[DCKing]

The article is really over the top hostile. 'Flatkill', 'Fakepak', 'Red Hat does not care about security'. What intentions could the author possibly have?