A COUPLE OF years ago, I fell in love with a color scheme: off-white text accented with a buttery yellow-orange and a neutral blue against a deep gray, the “color of television, tuned to a dead channel,” to borrow a phrase from Neuromancer author William Gibson. The colors were part of a theme called Solarized Dark for the popular MacOS code editor TextMate. To be honest, I didn’t think much of Solarized at first. But I soon found that I couldn’t work with any other color scheme. Staring at screens all day can make you particular about fonts and colors.

It turns out I’m not alone. I’m not a coder by trade, but I like to use code editors for writing and organizing notes. While hunting for tools after switching from a Mac to Windows, I started to see Solarized Dark and its sibling Solarized Light, which uses the same 16-color palette, practically everywhere I looked. It’s hard to say how many programmers use it. The design is free and open source, so there’s no tally of purchases. It’s available for every major code editor and many other programming tools. Microsoft even bundled it with its popular code editor VS Code. Solarized has a loyal following.

“If I bring up a terminal window that doesn’t have Solarized, I feel out of place; I don’t feel at home,” says Zachery Bir, a Richmond, Virginia, programmer and artist who has been using Solarized since shortly after it was released in 2011. Bir likes Solarized so much he uses it as the color scheme for his computer-generated art. “I didn’t trust myself to come up with a palette that was balanced and looked good both in a dark and light medium,” he says.

The Solarized color scheme is no accident. It reflects the obsessive attention to detail of its creator, Ethan Schoonover. “I didn’t release it until I was 1,000 percent sure I loved all the colors and they were all dialed in mathematically,” Schoonover says. “I had multiple monitors, some were color calibrated, others were deliberately messed up. Sometimes I showed my wife, who thought I was a little nuts.”

Too Much Contrast

Schoonover was working as a designer and programmer in Seattle when he started work on Solarized in 2010. He’d recently switched operating systems and was disappointed in the color schemes available for the tools he used. Many applications offered only a simple white-on-black scheme that harkened back to old-school text-based computer terminals. But Schoonover found these throwback color schemes much harsher than the retro displays they tried to emulate. That’s because the backgrounds displayed on old 1980s monitors weren’t truly black, Schoonover says. “They had less contrast.” Today’s LCD’s, on the other hand, are capable of displaying much darker, and much brighter, colors.

The optimal amount of contrast for text on a screen is controversial; many people prefer high-contrast themes. But contrast wasn’t Schoonover’s only concern. He found most low-contrast color schemes lacking as well. Even the best-designed themes tended to use at least one color that appeared distractingly brighter than others. That’s because the apparent brightness of a color varies depending on its background. In other words, a specific shade of blue will appear more or less bright, depending on the surrounding colors.

This phenomenon, known as the Helmholtz–Kohlrauscheffect, is particularly aggravating for programmers because coding tools use color to distinguish different parts of code. In the code for a web page in a typical text editor using the Solarized Dark theme, for example, web links appear in green; the syntax for formatting, such as adding italics, is blue, and comments that developers write for themselves are gray. Ideally, the colors should help tell these elements apart, but no single element should stand out more than others.

Schoonover set out to find a set of colors that would not only look good together, but would have the same apparent brightness. That task was made more difficult because he wanted to use the same palette in both a light and a dark theme. Hence the need for all the monitors and testing.

Examples of the Solarized Dark (left) and Solarized Light (right) themes displaying HTML code in the code editor Vim. ETHAN SCHOONOVER

Schoonover talks a lot about the mathematical nature of his color selections, but he picked the starting colors, a blue and a yellow, for very personal reasons. The blue reminds him of his long-standing thalassophobia, the fear of very deep water. And though he says he doesn’t otherwise experience synesthesia—such as hearing colors or tasting words—the yellow invokes tastes and smells he associates with his childhood. “My parents are artists, I’m comfortable picking things for obscure reasons,” he says.

With those starting points, Schoonover sought out other colors that provided just enough—but not too much—contrast between elements, and that maintained the same level of contrast in light and dark versions. The result is a palette of just 16 colors that retain the same relationships even when inverted. “I suppose it’s a little like composing music with only a limited number of notes,” Schoonover says. “There can be something sparse and beautiful about it.”

An Open Source Program Takes Off

Schoonover released Solarized for free in April 2011 on GitHub, a code-hosting platform and collaboration service. He says he never intended to commercialize it. “It would kill something special about it, taint it,” he says. “I believe in open source software, I believe in giving something special to the world that anyone can use.”

Although he’d tested the color scheme in a variety of applications, Schoonover initially released themes for only a few tools he used in his own work, like the code editor Vim and the text-based email client Mutt. He announced the release of Solarized on the Vim mailing list; soon after, the project hit the front page of the online community Hacker News. It was an immediate hit with programmers, who soon went to work adapting it to other programming tools beyond those Schoonover initially supported. In 2013, Solarized Dark appeared on the monitors of developers in a Facebook commercial—watch for those dark rectangles on the screens and notice the faintly colored lines that cross them.

Solarized is slowly starting to find its way into applications for non-geeks. Ulysses, a writing application for MacOS, includes Solarized themes as an option. The color scheme was used for many of the graphics in the videogame N++ in 2014. The note-taking app MicroPad even advertises Solarized as a feature on its website. “Solarized Dark for MicroPad is especially useful for late-night studying, which I do more often than I would like to admit,” says MicroPad creator Nick Webster, a computer science student at Victoria University in Wellington, New Zealand.

But it still hasn’t really crossed over to the mainstream as a color scheme for, say, a major web application or software suite. “When Apple introduced dark mode for MacOS, I thought it was cool,” says Bir, the Virginia programmer and artist. “But I wish it was Solarized.”

With more applications, like Google Chrome, Facebook Messenger, and Slack, releasing dark-mode themes, though, Solarized just might have its day in the sun.

[Stolen from:]

Severe security bug found in popular PHP library for creating PDF files

A security researcher has found a severe security flaw in one of the internet’s most popular PHP libraries for creating PDF files.

The vulnerability impacts TCPDF, one of the “big three” PHP libraries –together with mPDF and FPDF– for converting HTML code to PDF docs or assembling PDF files on the fly.

The security flaw can be exploited by an attacker to achieve “remote code execution” on websites and web apps that use the TCPDF library, allowing a threat actor to run malicious code and potentially take over these systems.

The vulnerability, per-se, is actually a variation of another researcher’s discovery.

The initial flaw was found by Secarma researcher Sam Thomas who in a series of experiments showcased a new deserialization bug affecting PHP apps over the summer of 2018. He released a research paper detailing PHP serialization attacks against the WordPress and Typo3 CMS platforms, but also the TCPDF library embedded inside the Contao CMS.


In a blog post published over the weekend, an Italian security researcher who goes online as Polict revealed a new PHP serialization flaw impacting TCPDF in the same way as the one discovered by Thomas last year.

Polict says the vulnerability he found can be exploited in two ways. The first case is on websites that allow user input to be part of the PDF file generation process, such as when adding names or other details inside invoices.

The second is on websites that contain cross-site scripting (XSS) vulnerabilities where an attacker can plant malicious code inside the HTML source code that will be fed to the TCPDF library to convert into a PDF.

The trick is to supply malformed data to the TCPDF library. This data is modified in such a way to force the TCPDF library to call the PHP server’s “phar://” stream wrapper, and later abuse the PHP deserialization process to run code on the underlying server.

It’s a very complex attack routine, and it requires advanced PHP coding knowledge to exploit. Deserialization exploits, in general, are hard to uncover and they’re the bane of many programming languages, including Ruby, Java, and .NET –besides PHP.

FLAW FIXED IN V6.2.20… ERM… V6.2.22

The researcher says he reported the vulnerability (CVE-2018-17057) to the TCPDF library author last August. The TCPDF team released TCPDF 6.2.20 in September to address the issue.

However, users should update to at least version 6.2.22 because the TCPDF team accidentally re-introduced the vulnerability reported by Sam Thomas while attempting to patch the one reported by Polict. Both issues were deemed resolved in version 6.2.22.

The Italian security researcher published details about this vulnerability only today, six months after the patch, because of the bug’s severity and to allow website and web app owners enough time to patch.

The TCPDF library is one of today’s most popular PHP libraries and has been used all over the place –in standalone websites, in content management systems (CMSs), CMS plugins, CMS themes, enterprise intranets, CRMs, HRMs, invoicing solutions, many PDF-centered web apps, and others.

Patching isn’t as easy as it sounds. In some cases, this might mean replacing a file and editing a build instruction, but in other places, this might require rewriting large swaths of code.

[Lifted from:]

Bootstrap 5 will replace jQuery entirely

The Bootstrap team is nearing its mission to completely remove jQuery from its framework in favor of JavaScript. Bootstrap is an open-source framework for responsive mobile solutions on the web.

The team recently released version 4.3 of the framework with its plans to remove jQuery. “The cat is out of the bag—we’re dropping our largest client-side dependency for regular JavaScript,” the team wrote in a blog post. “We’ve been working on this for a long time and have a pull request in progress and near completion.”

According to the pull request, this has been in the works since 2017. Once Bootstrap is released without jQuery, developers will still be able to use the framework plugin if jQuery is detected, the team explained.

The move to remove jQuery has spurred a lot of controversy in the development community.

“This entire effort seems of dubious benefit to me,” one developer commented. “Whereas before it was ‘jQuery for EVERYTHING,’ now it seems to be the reverse: ‘remove jQuery from EVERYTHING,’ which is equally silly. jQuery does a lot of useful stuff, and all things considered remains a pretty neat project. It shouldn’t be used for everything, but spending loads of time in removing it just because it’s no longer the [cool framework] of the week just seems like a waste of effort.”

While others feel like jQuery was good for a lot of useful stuff, now it is unmaintained and has little interest or support.

“It is ‘slow’ compared to other frameworks that now use the Shadow Dom, and can be replaced with features that are native to JS — what’s there not to like about that?” another developer commented. “One less dependency, network request and more efficient code is always worth the effort.”

Other upcoming projects include improving the Bootstrap branches for development and moving to Hugo.

I read the ‘PHP is fractally bad’ article, and it’s crap, of course.

Look, that article is just a subset of the larger problem of abstraction sickness. When abstractions become not only the cudgels of power that they have evolved to be for us to do battle with other people, but also alienated things with their own authority apart from the will of their host, then they are problematic. Try telling people who make $100k and better a year on PHP-based systems that PHP is horrifyingly bad. Try telling the people who use and find what they seek in said systems that they are stupid for being satisfied. No, it’s the know-it-all CS student who is great at abstract thought and ignorant about his own mind and its foibles in the face of alienated abstractions who puts first things like having all the tools he’s read about associated with this or that paradigm of programming. The person who is focused on solving real problems in any domain apart from computer science is not going to share the same priorities. As the house painter who taught himself how to program using PHP (yeah, I said “program”), I have seen and written sloppy code that just happened to work well enough for my purpose. But then I fucked around and taught myself C++ and OOP and functional programming, too, and I am telling you, for sure, it is the personal insecurity of programmers who have made it through a CS education and have put in the hours using C++ who want to preserve “programming clout” to their own group/self.