LWN: Comments on "Fedora opens up to bundling"

Fedora opens up to bundling

Cyberax — Tue, 27 Oct 2015 08:02:45 +0000

> But you need _operating system_ updates in order to punch these new holes in the sandbox, not software vendor actions.
Yes. But currently application vendors are not just at the mercy of the OS, but at the mercy of many packagers! It's even worse - what if your app depends on a feature of a package with asshole maintainer?

> And these introduce even more headaches, because punching new holes may break old software (or even new software, if we look into selinux).
Quite unlikely. New APIs rarely affect the old APIs.

> And in practice this is a much more common scenario than a malicious presentation reading your browser story -- see long tradition of Office viruses. After all, you've already compromised the office suite, so there's 0% additional effort in doing that, while there's sure to be some platform and browser-dependent code in reading browser history.
Viruses these days exist to actually earn money for their developers. Botnetting and browser history (including CC information) are the easiest target, while documents are almost always useless.

> I still believe in that a smaller programs model is much better for security, and that the App Store model clearly goes against smaller programs; if only because it becomes much harder to share data between programs.
So basically you're saying: "I believe in magic and unicorns". No packaging system can make a complicated office suite a "small" program. It might remove a bunch of peripheral dependencies, but nothing else.

So let's actually think about the threat model. Suppose I want to steal users' credit card information.
1) If I have an exploit for a widely used library like zlib or libpng then I probably wouldn't want to bother exploiting LibreOffice, never mind trying to exploit a sandboxed LibreOffice.

2) I have an exploit for LibreOffice itself. With a naïve distro model I simply need to hack LibreOffice and I instantly get access to browser's history with all the juicy CC info. With the sandboxed code I have to try and infect other documents, hoping that a user eventually opens a document with CC info.

So it appears that distro model provides no advantage here. Now, there might be a question of update speed. A distro might be able to update a shared library faster than a vendor can go through a full formal QA process. And that actually might be a disadvantage.

Fedora opens up to bundling

javispedro — Tue, 27 Oct 2015 07:20:32 +0000

> And that's fine. Vendors release new versions of applications all the time.

But you need _operating system_ updates in order to punch these new holes in the sandbox, not software vendor actions. And these introduce even more headaches, because punching new holes may break old software (or even new software, if we look into selinux). Unless you're thinking final software developers will ship the list of sandbox holes they need, but while this is a very interesting approach for a user trusted catalog of software (e.g. distro repository) it does not seem valid for a general "app store" model.

Remember that I'm saying the Apple sandbox model does not even provide half of the holes required for even a mere office suite to work well. The only such program that I currently known working under the sandbox is NeoOffice, and they do trickery such as showing up an OSX open dialog pointing at the file it wants to read every time it wants to read some random file. They also disable all extensions and is generally a pain to use. And this is most probably an example of a program that in theory seems easy to sandbox.

> Nope, it _might_ be able to infiltrate documents as you open them. It won't be able to read browser history or install spyware.

Sorry but we're going circles about this:
>> But sandboxing as it is done now usually involves making programs larger (e.g. Libreoffice-like huge suites instead of collections of individual programs cooperating, like in TeX), and this means that one single bug in the almost never used code that imports .mp4 fart sounds to use in Libreoffice presentations would also be enough to access ALL your sikret files.

And in practice this is a much more common scenario than a malicious presentation reading your browser story -- see long tradition of Office viruses. After all, you've already compromised the office suite, so there's 0% additional effort in doing that, while there's sure to be some platform and browser-dependent code in reading browser history.

I still believe in that a smaller programs model is much better for security, and that the App Store model clearly goes against smaller programs; if only because it becomes much harder to share data between programs.

> Linux-style dependency management clearly doesn't work well.
Note that sandboxing is independent of dependency management.

Fedora opens up to bundling

javispedro — Tue, 27 Oct 2015 06:41:02 +0000

> You can certainly switch back to 32-bit mode and use vm86

So why you keep saying you can't if it turns out you can? It was even documented on the original AMD64 manual albeit they did certainly mention it was tricky.

I've been always curious about this, since I've been doing exactly that for at least a decade, it's a ~4k patch in 3.x, performance is still better than qemu or vt-x, and I guess no one wants to talk about the security/races of vm86 in general.

Fedora opens up to bundling

mathstuf — Tue, 27 Oct 2015 03:08:58 +0000

Oh man, I can't wait for there to be one for Mill :D .

Fedora opens up to bundling

mjg59 — Tue, 27 Oct 2015 02:33:07 +0000

That… is horrifying.

Fedora opens up to bundling

deater — Tue, 27 Oct 2015 02:27:15 +0000

You can certainly run 16-bit x86 *code* in 64-bit mode although the stealing of opcodes for REX prefixes as well as various Linux security features certainly make it difficult. See https://github.com/deater/ll_asm/blob/master/linux16/16.s for one example.

Whether you can run unmodified code written for x86 real mode operating systems is a different story.

I know this is a bit of a nitpick, but there's a lot of confusion out there about this.

Fedora opens up to bundling

mjg59 — Mon, 26 Oct 2015 21:00:12 +0000

> actually that's wrong

No it's not. 64-bit mode has no support for vm86 mode, and so you can't run 16-bit code. You can certainly switch back to 32-bit mode and use vm86, which is presumably what the patch you're talking about does - but that's a pretty awful hack.

Fedora opens up to bundling

javispedro — Mon, 26 Oct 2015 20:53:54 +0000

> But it's hard to blame MS about this one - there's no 16-bit support in 64-bit mode.

Nitpick: actually that's wrong. 64-bit processors certainly support 16-bit mode, otherwise they wouldn't be proper supersets of 32-bit processors. MS not supporting 16-bit is just a cost-benefit trade-off. In fact, for similar reasons Linux does not support vm86 on amd64, but there's a patch floating around for it, and it works quite well.

Fedora opens up to bundling

Cyberax — Mon, 26 Oct 2015 20:16:58 +0000

> To sum it up: not only there's a huge amount of holes that need to be punched, but you need to keep punching brand new holes "all the time".
And that's fine. Vendors release new versions of applications all the time.

> Why not? As long as there's _any_ saved state (call it normal.dot, call it "shared config" -- what's the difference?) between invocations, then every future document you open with that program is compromised.
You assume that you can infiltrate through configuration. It's much less likely, especially if good config framework is used.

> Point is, even with OS X style sandboxing, a single "dancing cows" document will also be able to send all your company finances to Nigeria.
Nope, it _might_ be able to infiltrate documents as you open them. It won't be able to read browser history or install spyware.

Also, AppStore model allows vendors to quickly make and QA a patch for a security issue. With distros you have to go through maintainers and slow release process. Then you have to do QA for multiple distro versions.

It's pretty clear which security model is more advantageous.

> Not only that, but OS X style sandboxing is so problematic to implement, it might very well be not worth the effort, save perhaps for platform that are already usability limited from the start.
So what's your proposal? Linux-style dependency management clearly doesn't work well.

Fedora opens up to bundling

javispedro — Mon, 26 Oct 2015 19:55:30 +0000

> Operating systems are not set in stone. If there's a demand then new integration points are likely to be added. That is happening all the time both with iOS and Android.
To sum it up: not only there's a huge amount of holes that need to be punched, but you need to keep punching brand new holes "all the time".

> I think a billion smartphone users might disagree with you. And can you point me to an MS article about failing AppStore models?

>> There's a reason unsandboxed new programs appear daily even on platforms where the default is to be sandboxed (such as Windows or OS X). Any current platform that only allows for sandboxed binaries (WinRT, iPad *cough*) falls straight into the "it's completely useless for any serious work" territory.
>> And please don't use the "people do real work on an iPad" argument. By now even MS marketing guys have realized how stupid it is: they actually promote the completely unsandboxed environment called Win32 as their distinguishing feature over the plethora of tablets.

> You can't do it. It's an obvious vector and so Apple's own processor tools have a special sandbox mode for it. It allows you to open and write the shared config, but nothing else.
Why not? As long as there's _any_ saved state (call it normal.dot, call it "shared config" -- what's the difference?) between invocations, then every future document you open with that program is compromised.

> Please, explain how this is worse than the quagmire we have in Linux right now when a "dancing cows" LibreOffice document can send all your credit card info to Nigeria.
Point is, even with OS X style sandboxing, a single "dancing cows" document will also be able to send all your company finances to Nigeria. Not only that, but OS X style sandboxing is so problematic to implement, it might very well be not worth the effort, save perhaps for platform that are already usability limited from the start.

Fedora opens up to bundling

Cyberax — Mon, 26 Oct 2015 17:29:19 +0000

> That's a _huge_ thing to say. How do you even know 6 months by now there won't be a usecase that needs direct access from your word processor to your phone?
> Hell, I'm sure _I_ wouldn't bet against it!
Operating systems are not set in stone. If there's a demand then new integration points are likely to be added. That is happening all the time both with iOS and Android.

> NO! You're affirming the consequent here. I'm precisely arguing that it does NOT work! And I even explicitly mentioned above how even MS has come to realize this.
I think a billion smartphone users might disagree with you. And can you point me to an MS article about failing AppStore models?

> So I'll just infect the equivalent of normal.dot and reload myself on startup everytime. _A single bug on that binary compromises every further file saved by that binary_. Unless you want to prevent saving any state at all?
You can't do it. It's an obvious vector and so Apple's own processor tools have a special sandbox mode for it. It allows you to open and write the shared config, but nothing else.

Please, explain how this is worse than the quagmire we have in Linux right now when a "dancing cows" LibreOffice document can send all your credit card info to Nigeria.

> Please turn your brain on a bit before replying, as you've been told above.
Should I repeat my advice?

Fedora opens up to bundling

javispedro — Mon, 26 Oct 2015 15:53:53 +0000

> Not really. Most of the integration points for regular desktop use are known by now.

That's a _huge_ thing to say. How do you even know 6 months by now there won't be a usecase that needs direct access from your word processor to your phone?

Hell, I'm sure _I_ wouldn't bet against it!

> And so? App Store model works for most users.

NO! You're affirming the consequent here. I'm precisely arguing that it does NOT work! And I even explicitly mentioned above how even MS has come to realize this.

> Sandboxing command-line utilities is also possible
And precisely from a decade of SELinux experiences I know how stupid most sandboxing is, and how hard it is to actually make it usable.

> No, that's incorrect. Mac OS does not allow programs to store authorizations forever.

So I'll just infect the equivalent of normal.dot and reload myself on startup everytime. _A single bug on that binary compromises every further file saved by that binary_. Unless you want to prevent saving any state at all?

> Please, educate yourself about the state of the art, at least.

Please turn your brain on a bit before replying, as you've been told above.

Fedora opens up to bundling

Cyberax — Mon, 26 Oct 2015 05:57:10 +0000

Yup.

To be fair, in Mac OS X command line utilities invoked through exec() from sandboxed apps do have read-only access to Unix system directories, but they don't have access to users' directories.

Fedora opens up to bundling

mp — Sun, 25 Oct 2015 14:22:47 +0000

> Sandboxing command-line utilities is also possible - through SELinux or similar approaches.

Through complex LSMs that NOBODY understands? Oh well.

Fedora opens up to bundling

HelloWorld — Fri, 23 Oct 2015 22:11:16 +0000

> C and Python suck because you don't have private dependencies, they say!
And they're completely right. When I depend on a library x I shouldn't need to care what libraries x depends on, as long as they're not somehow exposed through x's API.

Fedora opens up to bundling

Cyberax — Thu, 22 Oct 2015 22:52:17 +0000

> i.e. punch specific holes in the sandbox. Hard to do when there are gazillions of possible usecases, and most of them we don't even envision today.
Not really. Most of the integration points for regular desktop use are known by now. Anything more advanced will require special-level access, but even developer desktops these days are pretty much vanilla.

> Because "command line apps are special", and because you break many of the common approaches which programs use to share data, you are encouraging developers to create "all-in-one" suites instead of collections of small programs (the so misnamed "unix way") and bigger shared libraries.
And so? App Store model works for most users. Sandboxing command-line utilities is also possible - through SELinux or similar approaches.

> Yeah... as well as any future file you open with that program, which for many users includes _ALL_ of the user's most important files
No, that's incorrect. Mac OS does not allow programs to store authorizations forever.

Please, educate yourself about the state of the art, at least.

guile and unicode

wingo — Thu, 22 Oct 2015 20:18:30 +0000

This is a bit far afield of the original article, but you persist in a misunderstanding about a project that I maintain :) To Guile 1.x, a character is a byte. To Guile 2.x, a character is a unicode codepoint: not a grapheme.

So when Guile reads a byte sequence which according to the given locale it decodes as U+0065 LATIN SMALL LETTER E followed by U+0301 COMBINING ACUTE ACCENT, those are the code points it stores internally. It does not normalize the codepoint sequence, although there are the string-normalize-nfc, string-normalize-nfd, string-normalize-nfkc, and string-normalize-nfkd procedures if the application chooses to do so, for whatever reason.

Fedora opens up to bundling

Wol — Thu, 22 Oct 2015 17:58:00 +0000

Notably, installers that DON'T work, appear to be MS's own :-)

Cheers,
Wol

guile and unicode

Wol — Thu, 22 Oct 2015 17:53:08 +0000

> There is no such thing as a deprecated codepoint.

aiui, there is a unicode character for a-acute. There is also the sequence <compose><acute><a>. What are you going to do when one string uses one encoding, and another string uses the other? Apparently, the Unicode spec now says you are supposed to use the <compose> sequence, which Guile v2 implements.

Hence lilypond blowing up when what it thinks is a string COPY, is turned by v2 into a string TRANSLATION :-( Please note, that BOTH the input AND the output in this case are not some random encoding, but are quite explicitly Unicode character strings.

Cheers,
Wol

Fedora opens up to bundling

javispedro — Thu, 22 Oct 2015 15:15:34 +0000

> Otherwise, a user must grant your application (somewhat mislabeled) "Accessibility" permissions.

i.e. punch specific holes in the sandbox. Hard to do when there are gazillions of possible usecases, and most of them we don't even envision today.

> Command-line apps are somewhat special.

And this I disagree with. Specially in the context of a distro's packaging, command-line apps are _the norm_.

> Uhm? What?

Because "command line apps are special", and because you break many of the common approaches which programs use to share data, you are encouraging developers to create "all-in-one" suites instead of collections of small programs (the so misnamed "unix way") and bigger shared libraries.

Otherwise, something as trivial as copying and pasting a plot from the spreadsheet program to the word processing program using anything more advanced (i.e. vector, linking, etc.) than a shared .png file becomes a nightmare.

An example of this is iOS.

> Nope. It'll only get access to that presentation and perhaps some recent files.

Yeah... as well as any future file you open with that program, which for many users includes _ALL_ of the user's most important files, esp. all of the text documents, the spreadsheets with financial data, presentations, drawings, the mailing list with all of your patients which you used once with your word processor, and the list of all words you've even written on any document so far (which obviously are only kept for "training purposes"), etc.

Fedora opens up to bundling

Cyberax — Thu, 22 Oct 2015 14:35:17 +0000

Windows autodetects some of the typical 16-bit installers (like InstallShield and others) and transparently emulates them.

But it's hard to blame MS about this one - there's no 16-bit support in 64-bit mode. They could have used a CPU emulator, but at this point it just makes sense to drop 20-year-old compatibility.

Fedora opens up to bundling

Cyberax — Thu, 22 Oct 2015 14:32:29 +0000

> "One bug" == "pwned", and who knows what damage is done :-( If it has LO's permissions, then it can access all of LO's files. (Which for most users, is pretty much everything.)
That's not true for sandboxed apps on Mac OS X. A document file with an embedded exploit will probably not be able to access even the recently opened documents. It definitely won't be able to modify the LO executable files or even _read_ other user's files.

On Linux, a compromised document can slurp browser's history and secret storage and send it to nice folks in Nigeria.

Now, which model do you trust more?

guile and unicode

wingo — Thu, 22 Oct 2015 13:26:06 +0000

Not sure why Guile is getting the blame here, but to clear things up:

Before Guile 2.0, Guile's strings were byte strings -- like in Python 2. Guile 2 changed so that strings were composed of characters. To Guile, a character is a unicode codepoint.

When reading strings from a byte stream, as from an fd, those characters have an encoding, which is usually taken from your locale. In some encodings, like ISO-8859-1, all byte sequences are valid, so reading data in and writing it out will produce the same byte sequence. In others, like UTF-8, maybe Guile could read an invalid sequence. In that case it can error, or replace the character with "?", depending on what the application chose to do. Likewise when writing, it could be Guile tries to write a codepoint that can't be expressed in the desired encoding; at which point it can error or write a ?. The application decides what strategy to take.

There is no such thing as a deprecated codepoint.

Fedora opens up to bundling

Wol — Thu, 22 Oct 2015 10:02:51 +0000

> > There are windows apps that worked on 7 and don't work on 10, windows isn't perfectly backwards compatible either (and the difference between RHEL4 and RHEL7 isn't Windows7 vs Windows10, it's more like XP/Vista -> Windows10

> All of my 32-bit XP apps still work on Win10 64-bit. Microsoft does an amazing job to make sure that old apps are not broken with each OS release. Their quality slipped a bit recently, though.

Many older apps may have been 32-bit, but their installers were 16-bit. So it's no f***ing use that they work, if you can't install the things!!!

Cheers,
Wol

Fedora opens up to bundling

Wol — Thu, 22 Oct 2015 09:54:22 +0000

> > (e.g. Libreoffice-like huge suites instead of collections of individual programs cooperating, like in TeX), and this means that one single bug in the almost never used code that imports .mp4 fart sounds to use in Libreoffice presentations would also be enough to access ALL your sikret files.

> Nope. It'll only get access to that presentation and perhaps some recent files.

Cyberax, sometimes you need to "engage brain before opening mouth".

"One bug" == "pwned", and who knows what damage is done :-( If it has LO's permissions, then it can access all of LO's files. (Which for most users, is pretty much everything.)

(Incidentally, LO is not a monolithic blob. Although I'll admit it often feels like it ...)

Cheers,
Wol

Fedora opens up to bundling

Wol — Thu, 22 Oct 2015 09:39:02 +0000

> In my opinion, the mistake was to standardize on what was already shipped, instead of specifying what should be shipped.

> Basically catering to the wishes of the distributors instead of the needs of the developers.

Sort of yes ...

They shouldn't have standardised on what was shipped, they should have standardised a way of describing what was required...

I tried to get them to do that - the example I give is I wanted to create an LSB virtual package that would pull in the components required by WordPerfect. That approach would have been great - an app developer just specifies the pre-requisites and leaves it to the distro to ensure they are met.

What's the point of describing what's there, if there's no way of prescribing what's needed?

Cheers,
Wol

Fedora opens up to bundling

Wol — Thu, 22 Oct 2015 09:34:22 +0000

And then there's Unicode ... :-)

I use lilypond. Which is still stuck on Guile v1.

"cat input | guile > output"

Assuming all guile does is read from stdin and copy to stdout, unfortunately Guile v2 breaks the expectation that "input == output", and this breaks lilypond :-( In very subtle and hard-to-fix ways :-(

So this is another, pretty classic, example of a program with bundled dependencies because mainstream (no longer) provides features on which it relies.

For info, as I understand it, Guile v2 converts deprecated code points on the fly to up-to-date ones. All composite characters (eg a-umlaut, e-acute etc) are now deprecated and should be <compose><accent><letter> or whatever the correct version is. Lilypond assumes that a character offset in the input will point to the same character in the output, and of course if any of these conversions has happened, it breaks that assumption :-(

Cheers,
Wol

Fedora opens up to bundling

pizza — Wed, 21 Oct 2015 17:43:55 +0000

...except for applications that take libraries, mangle them in incompatible ways, and bundle the results. (Chrome/chromium was the most infamous example of this, though I understand they have considerably cleaned up their act in recent years)

Fedora opens up to bundling

rwmj — Wed, 21 Oct 2015 16:12:47 +0000

... is the correct answer. The problem isn't just applications, it's libraries not offering long term stable API guarantees. This is sloppy, lazy programming.

Fedora opens up to bundling

Cyberax — Tue, 20 Oct 2015 23:29:22 +0000

> That doesn't even start to cover all the holes that should be poked.
It covers most.

> What if you want to share a spell checker whitelist between Abiword and Libreoffice? What if you just installed the Zotero plugin and want to run it in both Abiword, Libreoffice, and Firefox, preferably with the same bibliography? Hidden file dependencies? etc.
If your spellchecker is specific to AbiWord and Libreoffice - you can explicitly whitelist it in each application. Otherwise, a user must grant your application (somewhat mislabeled) "Accessibility" permissions.

> Even for compiling a single .c file the amount of required holes is mind-boggling. Or running a trivial NumPy number-crunching script. Or creating a basic plot with R. Or ...
Command-line apps are somewhat special. They can be sandboxed, but nobody really cares about them.

> But sandboxing as it is done now usually involves making programs larger
Uhm? What?

> (e.g. Libreoffice-like huge suites instead of collections of individual programs cooperating, like in TeX), and this means that one single bug in the almost never used code that imports .mp4 fart sounds to use in Libreoffice presentations would also be enough to access ALL your sikret files.
Nope. It'll only get access to that presentation and perhaps some recent files.

Fedora opens up to bundling

Cyberax — Tue, 20 Oct 2015 23:24:10 +0000

I'm afraid it's per _application_. Newer applications use manifests (either embedded or standalone) which redirect DLLs to side-by-side directories. Microsoft also does some magic tricks - it uses a bunch of heuristics to detect that a legacy installer is running and redirects its libraries away from System32.

Yeah, it's extra-ugly but works.

Fedora opens up to bundling

javispedro — Tue, 20 Oct 2015 22:21:11 +0000

Not each legacy application, just every user sees a different copy of it. I.e. it's like a unionfs where writes (which would otherwise be blocked by perms) go to the per-user overlay. (In addition to the 32/64 duality)

In Windows it would be completely impossible to do any sensible "per-application" thing. How do you even determine which executables are part of each application?

Fedora opens up to bundling

javispedro — Tue, 20 Oct 2015 22:15:30 +0000

> Apple does this just fine with their sandboxing for AppStore applications. Basically, "Open File" action allows an application to access user-specified files.

That doesn't even start to cover all the holes that should be poked. What if you want to share a spell checker whitelist between Abiword and Libreoffice? What if you just installed the Zotero plugin and want to run it in both Abiword, Libreoffice, and Firefox, preferably with the same bibliography? Hidden file dependencies? etc.

Even for compiling a single .c file the amount of required holes is mind-boggling. Or running a trivial NumPy number-crunching script. Or creating a basic plot with R. Or ...

There's a reason unsandboxed new programs appear daily even on platforms where the default is to be sandboxed (such as Windows or OS X). Any current platform that only allows for sandboxed binaries (WinRT, iPad *cough*) falls straight into the "it's completely useless for any serious work" territory.

And please don't use the "people do real work on an iPad" argument. By now even MS marketing guys have realized how stupid it is: they actually promote the completely unsandboxed environment called Win32 as their distinguishing feature over the plethora of tablets.

> This is a far better approach than playing whack-a-mole with bugs where one single bug in an "Exploding Kittens" game might be enough to get access to ALL your files.

But sandboxing as it is done now usually involves making programs larger (e.g. Libreoffice-like huge suites instead of collections of individual programs cooperating, like in TeX), and this means that one single bug in the almost never used code that imports .mp4 fart sounds to use in Libreoffice presentations would also be enough to access ALL your sikret files.

Being an idealist, I still think that a system that doesn't encourage huge monster applications (and thus keeps bug numbers at manageable levels) is a much better approach.

Fedora opens up to bundling

rahulsundaram — Tue, 20 Oct 2015 16:46:57 +0000

Sure but this is an ongoing conversation if anyone has followed along with the discussions and likely would involve tweaking the language in the policy. I wouldn't read any of the current policy as conclusive.

Fedora opens up to bundling

lsl — Tue, 20 Oct 2015 16:40:48 +0000

Sure, but those Javascript guidelines were written before the "we need bundling" decision was made. Note that almost no upstream "allowed" the Javascript unbundling that was done (or planned) for Fedora packages.

Fedora opens up to bundling

rahulsundaram — Tue, 20 Oct 2015 16:16:48 +0000

No idea what you mean by the Fedora way? The guidelines limit it considerably

https://fedoraproject.org/wiki/Packaging:JavaScript#Stati...

Fedora opens up to bundling

pabs — Tue, 20 Oct 2015 15:47:12 +0000

JavaScript libraries are absolutely the worst thing to be bundling, do not do that. We are not going the Fedora way in Debian.

Fedora opens up to bundling

ploxiln — Tue, 20 Oct 2015 07:19:30 +0000

It gets worse.

Pip, the standard python package installer nowadays, bundles ("vendors") its dependencies. Ubuntu 14.04 unbundled them for its pip package, and if you install a version of the popular "requests" module from just a few months after ubuntu 14.04 was released (into the site-packages dir where it won't conflict with the dist-packages dir for ubuntu-packaged modules), it breaks the packaged pip.

Most nodejs applications use dependencies that bundle their dependencies. So overall they end up bundling multiple different versions of the same libraries! Then often end up with literally over a thousand bundled libraries, which are various versions of somewhere under 100 different libraries, which provide maybe 20 different sets of functionality. And they think this is the greatest thing ever! C and Python suck because you don't have private dependencies, they say!

So as "common" developers and "popular" libraries get accustomed to this sort of thing, respect for backwards compatibility and security maintenance goes out the window. (Even as they tout their "semver" versioning.) It really is ridiculous. But it's also just the definition of "common" and "popular" changing, as entirely new groups of developers come to exist at a magnitude larger than the previous groups.

Fedora opens up to bundling

roc — Mon, 19 Oct 2015 23:14:42 +0000

I agree sending fixes upstream is generally a good thing to do. I have not said otherwise.

Fedora opens up to bundling

emptysquare — Mon, 19 Oct 2015 13:36:39 +0000

Thanks for this engaging, educational article. I'm dealing with issues just like this in a Debian package I'm preparing -- I need to bundle *both* a stable copy of a javascript library *and* a tweaked copy of a C library -- and this helped me understand where the community is moving. A surprisingly brisk read on a pretty dry subject. =)