Language Selection

English French German Italian Portuguese Spanish

Debian

Syndicate content
Planet Debian - https://planet.debian.org/
Updated: 4 hours 14 min ago

Paul Wise: FLOSS Activities May 2019

Friday 31st of May 2019 11:41:16 PM
Changes Issues Review Administration
  • Debian: answer SSH question, redirect LDAP change mail, fix some critical typos in LDAP, restart bacula after postgres restart
  • Debian wiki: forward questions to page authors, answer wiki support questions, whitelist email domains, whitelist email addresses, ping folks with bouncing email addresses, disable accounts with bouncing email
  • Debian package tracking system: deploy changes, configure automatic disabling of unused oldstable suites
  • Debian derivatives census: restore corrupted file from backups, disable the code that corrupted the file, deploy changes
Communication Sponsors

The leptonlib/tesseract-lang/tesseract/sysstat Debian uploads and the ufw feature request were sponsored by my employer. All other work was done on a volunteer basis.

Sylvain Beucler: Debian LTS - May 2019

Friday 31st of May 2019 03:22:10 PM

Here is my transparent report for my work on the Debian Long Term Support (LTS) project, which extends the security support for past Debian releases, as a paid contributor.

In May, the monthly sponsored hours were split evenly among contributors depending on their max availability - I declared max 30h and got 18h.

  • firefox-esr: jessie-security update, security-ish issue with modules signing authority, backporting stretch's
  • CVE-2018-19969/phpmyadmin: attempt backporting the 49 patches and decide against it since they merely mitigate the CSRF issues but certainly break the testsuite
  • CVE-2018-20839/systemd: attempt to reproduce issue in Jessie, conclude no-dsa due to non-reproducibility and regressions introduced by the patch
  • CVE-2019-2697/openjdk-7: triage (sync with previous uploaders, conclude "not-affected")
  • CVE-2019-0227/axis: triage (clarify SSRF situation, sync with packager, conclude "unfixed")
  • dns-root-data: discuss potential update, conclude not relevent due to no reverse dependencies
  • gradle, kdepim: update triage info

Incidentally, last month I mentioned how regularly updating a 19MB text file caused issues in Git - it appears it's even breaking salsa.debian.org! Sadly conversation between involved parties appears difficult.

If you'd like to know more about LTS security, I recommend you check:

Sylvain Beucler: Debian LTS - May 2019

Friday 31st of May 2019 03:14:55 PM

Here is my transparent report for my work on the Debian Long Term Support (LTS) project, which extends the security support for past Debian releases, as a paid contributor.

In May, the monthly sponsored hours were split evenly among contributors depending on their max availability - I declared max 30h and got 18h.

  • firefox-esr: jessie-security update, security-ish issue with modules signing authority, backporting stretch's
  • CVE-2018-19969/phpmyadmin: attempt backporting the 49 patches and decide against it since they merely mitigate the CSRF issues but certainly break the testsuite
  • CVE-2018-20839/systemd: attempt to reproduce issue in Jessie, conclude no-dsa due to non-reproducibility and regressions introduced by the patch
  • CVE-2019-2697/openjdk-7: triage (sync with previous uploaders, conclude "not-affected")
  • CVE-2019-0227/axis: triage (clarify SSRF situation, sync with packager, conclude "unfixed")
  • dns-root-data: discuss potential update, conclude not relevent due to no reverse dependencies
  • gradle, kdepim: update triage info

Incidentally, last month I mentioned how regularly updating a 19MB text file caused issues in Git - it appears it's even breaking salsa.debian.org! Sadly conversation between involved parties appears difficult.

If you'd like to know more about LTS security, I recommend you check:

Bits from Debian: Debian welcomes its GSoC 2019 and Outreachy interns

Friday 31st of May 2019 12:15:00 PM

We're excited to announce that Debian has selected seven interns to work with us during the next months: two people for Outreachy, and five for the Google Summer of Code.

Here is the list of projects and the interns who will work on them:

Android SDK Tools in Debian

Package Loomio for Debian

Debian Cloud Image Finder

Debian Patch Porting System

Continuous Integration

Congratulations and welcome to all the interns!

The Google Summer of Code and Outreachy programs are possible in Debian thanks to the efforts of Debian developers and contributors that dedicate part of their free time to mentor interns and outreach tasks.

Join us and help extend Debian! You can follow the interns weekly reports on the debian-outreach mailing-list, chat with us on our IRC channel or on each project's team mailing lists.

Chris Lamb: Free software activities in May 2019

Friday 31st of May 2019 11:01:02 AM

Here is my monthly update covering what I have been doing in the free software world during May 2019 (previous month):

  • As part of my duties of being on the board of directors of the Open Source Initiative I attended our biannual face-to-face board meeting in New York, attending the OSI's local event organised by Open Source NYC in order to support my colleagues who were giving talks, as well as participated in various licensing discussions, advocacy activities etc. throughout the rest of the month over the internet.

  • For the Tails privacy-oriented operating system, I attended an online "remote sprint" where we worked collaboratively on issues, features and adjacent concerns regarding the move to Debian buster. I particularly worked on a regression in Fontconfig to ensure the cache filenames remain determinstic [...] as well as reviewed/tested release candidates and others' patches.

  • Gave a few informal talks to Microsoft employees on Reproducible Builds in Seattle, Washington.

  • Opened a pull request against the django-markdown2 utilitiy to correct the template tag name in a documentation example. [...]

  • Hacking on the Lintian static analysis tool for Debian packages:

Reproducible builds

Whilst anyone can inspect the source code of free software for malicious flaws almost all software is distributed pre-compiled to end users.

The motivation behind the Reproducible Builds effort is to ensure no flaws have been introduced during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised.

The initiative is proud to be a member project of the Software Freedom Conservancy, a not-for-profit 501(c)(3) charity focused on ethical technology and user freedom.

Conservancy acts as a corporate umbrella, allowing projects to operate as non-profit initiatives without managing their own corporate structure. If you like the work of the Conservancy or the Reproducible Builds project, please consider becoming an official supporter.

This month, I:

  • Gave a number of informal talks to Microsoft employeers on Reproducible Builds in Seattle, Washington.

  • Drafted, published and publicised our monthly report.

  • Authored and submitted 5 patches to fix reproducibility issues in fonts-ipaexfont, ghmm, liblopsub, ndpi & xorg-gtest.

  • I spent some time our website this month, adding various fixes for larger/smaller screens [...], added a logo suitable for printing physical pin badges [...]. I also refreshed the text on our SOURCE_DATE_EPOCH page.

  • Categorised a huge number of packages and issues in the Reproducible Builds "notes" repository, kept isdebianreproducibleyet.com up to date [...] and posted some branded merchandise to other core team members.

I also made the of following changes to diffoscope, our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues:

  • Support the latest PyPI package repository upload requirements by using real reStructuredText comments instead of the raw directive [...] and by stripping out manpage-only parts of the README rather than using the only directive [...].

  • Fix execution of symbolic links that point to the bin/diffoscope entry point in a checked-out version of our Git repository by fully resolving the location as part of dynamically calculating Python's module include path. [...]

  • Add a Dockerfile [...] with various subsequent fixups [...][...][...].

  • Published the resulting Docker image in the diffoscope container registry and updated the diffoscope homepage to provide "quick start" instructions on how to use diffoscope via this image.

Finally, I made a large number of following changes to my web-based ("no installation required") version of the diffoscope tool, try.diffoscope.org:

Debian Debian LTS

This month I have worked 18 hours on Debian Long Term Support (LTS) and 12 hours on its sister Extended LTS project.

  • Investigated and triaged CVE-2019-12217, CVE-2019-12219, CVE-2019-12220, CVE-2019-12221 and CVE-2019-12222 in libsdl1.2/libsdl2, simplesamlphp, freeimage & firefox-esr for jessie LTS, and capstone (CVE-2016-7151), sysdig (CVE-2019-8339), enigmail (CVE-2019-12269), firefox-esr (CVE-2019-1169) & sdl-image1.2 (CVE-2019-12218) for wheezy LTS.

  • Frontdesk duties, responding to user/developer questions, reviewing others' packages, etc.

  • Issued DLA 1793-1 for the dhcpcd5 network management protocol client to fix a read overflow vulnerability.

  • Issued DLA 1805-1 to fix a use-after-free vulnerability in minissdpd, a network device discovery daemon where a remote attacker could abuse this to crash the process.

  • Issued ELA-119-1 and DLA 1801-1 for zookeeper (a distributed co-ordination server) where users who were not authorised to read any data were still able to view the access control list.

  • For minissdpd, I filed an appropriate tracking bug for its outstanding CVE (#929297) and then fixed it in the current Debian stable distribution, proposing its inclusion in the next point release via #929613.


Uploads
  • redis (5:5.0.5-1) — New upstream release.

  • python-django (2:2.2.1-1) — New upstream release.

  • bfs (1.4.1-1) — New upstream release.

I also made the following non-maintainer uploads (NMUs) to fix release-critical bugs in Debian buster:

  • coturn (4.5.1.1-1.1) — Don't ship the (empty) /var/lib/turn/turndb SQLite database and generate it on-demand in the post-installation script to avoid overwriting it on upgrade/reinstall. (#929269)

  • libzorpll (7.0.1.0~alpha1-1.1) — Apply a patch from Andreas Beckmann to add suitable Breaks for smoother upgrades from stretch. (#928883)

  • mutt (1.10.1-2.1) — Prevent undefined behaviour when parsing invalid Content-Disposition mail headers. (#929017)

FTP Team

As a Debian FTP assistant I ACCEPTed 16 packages: cc-tool, gdal, golang-github-joyent-gosign, golang-github-mgutz-str, golang-github-mgutz-to, golang-github-ovh-go-ovh, golang-github-src-d-gcfg, golang-golang-x-xerrors, golang-gopkg-ldap.v3, libgit2, nodejs, opensbi, openzwave, rustc, u-boot & websocketd.

Russ Allbery: Review: Bad Blood

Friday 31st of May 2019 03:43:00 AM

Review: Bad Blood, by John Carreyrou

Publisher: Alfred A. Knopf Copyright: 2018 ISBN: 1-5247-3166-8 Format: Kindle Pages: 302

Theranos was a Silicon Valley biotech startup founded by Elizabeth Holmes in 2003. She was a sophomore chemical engineering major at Stanford University when she dropped out to start the company. Theranos's promised innovation was a way to perform blood tests quickly and easily with considerably less blood than was used by normal testing methods. Their centerpiece product was supposed to be a sleek, compact, modern-looking diagnostic device that could use a finger-stick and a small ampule of blood to run multiple automated tests and provide near-immediate results.

Today, Holmes and former Theranos president Ramesh "Sunny" Balwani are facing federal charges of wire fraud. Theranos, despite never producing a working product, burned through $700 million of venture capital funding. Most, possibly all, public demonstrations of their device were faked. Most of their partnerships and contracts fell through. For the rare ones where Theranos actually did testing, they either used industry-standard equipment (not their own products) or sent the samples to other labs.

John Carreyrou is the Wall Street Journal reporter who first broke the story of Theranos's fraud in October of 2015. This book is an expansion of his original reporting. It's also, in the last third or so, the story of that reporting itself, including Theranos's aggressive attempts to quash his story, via both politics and targeted harassment, which were orchestrated by Theranos legal counsel and board member David Boies. (If you had any respect for David Boies due to his association with the Microsoft anti-trust case or Bush v. Gore, this book, along with the similar tactics his firm appears to have used in support of Harvey Weinstein, should relieve you of it. It's depressing, if predictable, that he's not facing criminal charges alongside Holmes and Balwani.)

Long-form investigative journalism about corporate malfeasance is unfortunately a very niche genre and deserves to be celebrated whenever it appears, but even putting that aside, Bad Blood is an excellent book. Carreyrou provides a magnificent and detailed account of the company's growth, internal politics, goals, and strangely unstoppable momentum even while their engineering faced setback after setback. This is a thorough, detailed, and careful treatment that draws boundaries between what Carreyrou has sources for and what he has tried to reconstruct. Because the story of the reporting itself is included, the reader can also draw their own conclusions about Carreyrou's sources and their credibility. And, of course, all the subsequent legal cases against the company have helped him considerably by making many internal documents part of court records.

Silicon Valley is littered with failed startups with too-ambitious product ideas that were not practical. The unusual thing about Theranos is that they managed to stay ahead of the money curve and the failure to build a working prototype for surprisingly long, clawing their way to a $10 billion valuation and biotech unicorn status on the basis of little more than charisma, fakery, and a compelling story. It's astonishing, and rather scary, just how many high-profile people like Boies they managed to attract to a product that never worked and is probably scientifically impossible as described in their marketing, and just how much effort it took to get government agencies like the CMS and FDA to finally close them down.

But, at the same time, I found Bad Blood oddly optimistic because, in the end, the system worked. Not as well as it should have, and not as fast as it should have: Theranos did test actual patients (badly), and probably caused at least some medical harm. But while the venture capital money poured in and Holmes charmed executives and negotiated partnerships, other companies kept testing Theranos's actual results and then quietly backing away. Theranos was forced to send samples to outside testing companies to receive proper testing, and to set up a lab using traditional equipment. And they were eventually shut down by federal regulatory agencies, albeit only after Carreyrou's story broke.

As someone who works in Silicon Valley, I also found the employment dynamics at Theranos fascinating. Holmes, and particularly Balwani when he later joined, ran the company in silos, kept secrets between divisions, and made it very hard for employees to understand what was happening. But, despite that, the history of the company is full of people joining, working there for a year or two, realizing that something wasn't right, and quietly leaving. Theranos management succeeded in keeping enough secrets that no one was able to blow the whistle, but the engineers they tried to hire showed a lot of caution and willingness to cut their losses and walk away. It's not surprising that the company seemed to shift, in its later years, towards new college grads or workers on restrictive immigration visas who had less experience and confidence or would find it harder to switch companies. There's a story here about the benefits of a tight job market and employees who feel empowered to walk off a job. (I should be clear that, while a common theme, this was not universal, and Theranos arguably caused one employee suicide from the stress.)

But if engineers, business partners, a reporter, and eventually regulatory agencies saw through Theranos's fraud, if murkily and slowly, this is also a story of the people who did not. If you are inclined to believe that the prominent conservative Republican figures of the military and foreign policy establishment are wise and thoughtful people, Bad Blood is going to be uncomfortable reading. James Mattis, who served as Trump's Secretary of Defense, was a Theranos booster and board member, and tried to pressure the Department of Defense into using the company's completely untested and fraudulent product for field-testing blood samples from soldiers. One of Carreyrou's main sources was George Shultz's grandson, who repeatedly tried to warn his grandfather of what was going on at Theranos while the elder Republican statesman was on Theranos's board and recruiting other board members from the Hoover Institute, including Henry Kissinger. Apparently the film documentary version of Bad Blood is somewhat kinder to Shultz, but the book is methodically brutal. He comes across as a blithering idiot who repeatedly believed Holmes and Theranos management over his grandson on the basis of his supposed ability to read and evaluate people.

If you are reading this book, I do recommend that you search for video of Elizabeth Holmes speaking. Carreyrou mentions her personal charisma, but it's worth seeing first-hand, and makes some of Theranos's story more believable. She has a way of projecting sincerity directly into the camera that's quite remarkable and is hard to describe in writing, and she tells a very good story about the benefits of easier and less painful (and less needle-filled) blood testing. I have nothing but contempt for people like Boies, Mattis, and Shultz who abdicated their ethical responsibility as board members to check the details and specifics regardless of personal impressions. In a just world with proper legal regulation of corporate boards they would be facing criminal charges along with Holmes. But I can see how Holmes convinced the media and the public that the company was on to something huge. It's very hard to believe that someone who touts a great advancement in human welfare with winning sincerity may be simply lying. Con artists have been exploiting this for all of human history.

I've lived in or near Palo Alto for 25 years and work in Silicon Valley, which made some of the local details of Carreyrou's account fascinating, such as the mention of the Old Pro bar as a site for after-work social meetings. There were a handful of places where Carreyrou got some details wrong, such as his excessive emphasis on the required non-disclosure agreements for visitors to Theranos's office. (For better or ill, this is completely routine for Silicon Valley companies and regularly recommended by corporate counsel, not a sign of abnormal paranoia around secrecy.) But the vast majority of the account rang true, including the odd relationship between Stanford faculty and startups, and between Stanford and the denizens of the Hoover Institute.

Bad Blood is my favorite piece of long-form journalism since Bethany McLean and Peter Elkin's The Smartest Guys in the Room about Enron, and it is very much in the same mold. I've barely touched on all the nuances and surprising characters in this saga. This is excellent, informative, and fascinating work. I'm still thinking about what went wrong and what went right, how we as a society can do better, and the ways in which our regulatory and business system largely worked to stop the worst of the damage, no thanks to people like David Boies and George Shultz.

Highly recommended.

Rating: 9 out of 10

More in Tux Machines

Android Leftovers

Linux on the mainframe: Then and now

Last week, I introduced you to the origins of the mainframe's origins from a community perspective. Let's continue our journey, picking up at the end of 1999, which is when IBM got onboard with Linux on the mainframe (IBM Z). These patches weren't part of the mainline Linux kernel yet, but they did get Linux running on z/VM (Virtual Machine for IBM Z), for anyone who was interested. Several efforts followed, including the first Linux distro—put together out of Marist College in Poughkeepsie, N.Y., and Think Blue Linux by Millenux in Germany. The first real commercial distribution came from SUSE on October 31, 2000; this is notable in SUSE history because the first edition of what is now known as SUSE Enterprise Linux (SLES) is that S/390 port. Drawing again from Wikipedia, the SUSE Enterprise Linux page explains: Read more

OSS: Cisco Openwashing, GitLab Funding, Amazon Openwashing, Chrome OS Talk and More Talks

  • Why Open Source continues to be the foundation for modern IT

    Open source technology is no longer an outlier in the modern world, it's the foundation for development and collaboration. Sitting at the base of the open source movement is the Linux Foundation, which despite having the name Linux in its title, is about much more than just Linux and today is comprised of multiple foundations, each seeking to advance open source technology and development processes. At the recent Open Source Summit North America event held in San Diego, the width and breadth of open source was discussed ranging from gaming to networking, to the movie business ,to initiatives that can literally help save humanity. "The cool thing is that no matter whether it's networking, Linux kernel projects, the Cloud Native Computing Foundation projects like Kubernetes, or the film industry with the Academy Software Foundation (ASWF), you know open source is really pushing innovation beyond software and into all sorts of different areas," Jim Zemlin, executive director of the Linux Foundation said during his keynote address.

  • GitLab Inhales $268M Series E, Valuation Hits $2.75B

    GitLab raised a substantial $268 million in a Series E funding round that was more than doubled what the firm had raised across all of its previous funding rounds and pushed its valuation to $2.75 billion. It also bolsters the company’s coffers as it battles in an increasingly competitive DevOps space. GitLab CEO Sid Sijbrandij said in an email to SDxCentral that the new Series E funds will help the company continue to move on its goal of providing a single application to support quicker delivery of software. It claims more than 100,000 organizations use its platform. “These funds will help us to keep up with that pace and add to that with our company engineers,” Sijbrandij explained. “We need to make sure every part of GitLab is great and that CIOs and CTOs who supply the tools for their teams know that if they bet on GitLab that we’ll stand up to their expectations.”

  • Amazon open-sources its Topical Chat data set of over 4.7 million words [Ed: openwashing of listening devices without even releasing any code]
  • How Chrome OS works upstream

    Google has a long and interesting history contributing to the upstream Linux kernel. With Chrome OS, Google has tried to learn from some of the mistakes of its past and is now working with the upstream Linux kernel as much as it can. In a session at the 2019 Open Source Summit North America, Google software engineer Doug Anderson detailed how and why Chrome OS developers work upstream. It is an effort intended to help the Linux community as well as Google. The Chrome OS kernel is at the core of Google's Chromebook devices, and is based on a Linux long-term support (LTS) kernel. Anderson explained that Google picks an LTS kernel every year and all devices produced in that year will use the selected kernel. At least once during a device's lifetime, Google expects to be able to "uprev" (switch to a newer kernel version). Anderson emphasized that if Google didn't upstream its own patches from the Chrome OS kernel, it would make the uprev process substantially more difficult. Simply saying that you'll work upstream and actually working upstream can be two different things. The process by which Chrome OS developers get their patches upstream is similar to how any other patches land in the mainline Linux kernel. What is a bit interesting is the organizational structure and process of how Google has tasked Chrome OS developers to work with upstream. Anderson explained that developers need to submit patches to the kernel mailing list and then be a little patient, giving some time for upstream to respond. A key challenge, however, is when there is no response from upstream. "When developing an upstream-first culture, the biggest problem anyone can face is silence," Anderson said. Anderson emphasized that when submitting a patch to the mailing list, what a developer is looking for is some kind of feedback; whether it's good or bad doesn't matter, but it does matter that someone cares enough to review it. What the Chrome OS team does in the event that there is no community review is it will have other Chrome OS engineers publicly review the patch. The risk and worry of having Chrome OS engineers comment on Chrome OS patches is that the whole process might look a little scripted and there could be the perception of some bias as well. Anderson noted that it is important that only honest feedback and review is given for a patch.

  • Open Source Builds Trust & Credibility | Karyl Fowler

    Karyl Fowler is co-founder and CEO of Transmute, a company that’s building open source and decentralized identity management. We sat down with Fowler at the Oracle OpenWorld conference to talk about the work Transmute is doing.

  • What Is Infrastructure As Code?

    Rob Hirschfeld, Founder, and CEO of RackN breaks Infrastructure As Code (IaC) into six core concepts so users have a better understanding of it.

  • Everything You Need To Know About Redis Labs

    At the Oracle OpenWorld conference, we sat down with Kyle Davis – Head of Developer Advocacy at Redis Labs – to better understand what the company does.

Programming: Java, Python, and Perl

  • Oracle Releases Java 13 with Remarkable New Features

    Oracle – the software giant has released Java SE and JDK 13 along with the promise to introduce more new features in the future within the six-month cycle. The Java 13’s binaries are now available for download with improvements in security, performance, stability, and two new additional preview features ‘Switch Expressions’ and ‘Text Blocks’, specifically designed to boost developers’ productivity level. This gives the hope that the battle of Java vs Python will be won by the former. Remarking on the new release, Oracle said: “Oracle JDK 13 increases developer productivity by improving the performance, stability and security of the Java SE Platform and the JDK,”. [...] Speaking of the Java 13 release, it is licensed under the GNU General Public License v2 along with the Classpath Exception (GPLv2+CPE). The director of Oracle’s Java SE Product Management, Sharat Chander stated “Oracle offers Java 13 for enterprises and developers. JDK 13 will receive a minimum of two updates, per the Oracle CPU schedule, before being followed by Oracle JDK 14, which is due out in March 2020, with early access builds already available.” Let’s look into the new features that JDK 13 comes packed with.

  • 8 Python GUI Frameworks For Developers

    Graphical User Interfaces make human-machine interactions easier as well as intuitive. It plays a crucial role as the world is shifting.

  • What's In A Name? Tales Of Python, Perl, And The GIMP

    In the older days of open source software, major projects tended to have their Benevolent Dictators For Life who made all the final decisions, and some mature projects still operate that way. Guido van Rossum famously called his language “Python” because he liked the British comics of the same name. That’s the sort of thing that only a single developer can get away with. However, in these modern times of GitHub, GitLab, and other collaboration platforms, community-driven decision making has become a more and more common phenomenon, shifting software development towards democracy. People begin to think of themselves as “Python programmers” or “GIMP users” and the name of the project fuses irrevocably with their identity. What happens when software projects fork, develop apart, or otherwise change significantly? Obviously, to prevent confusion, they get a new name, and all of those “Perl Monks” need to become “Raku Monks”. Needless to say, what should be a trivial detail — what we’ve all decided to call this pile of ones and zeros or language constructs — can become a big deal. Don’t believe us? Here are the stories of renaming Python, Perl, and the GIMP.

  • How to teach (yourself) computer programming

    Many fellow students are likely in the same boat, the only difference being that the vast majority not only that don’t list computer science as one of their passions (but more as one of their reasons for not wanting to live anymore), but they get a very distorted view of what computer science and programming actually is.

    Said CS classes tend to be kind of a joke, not only because of the curriculum. The main reason why they are bad and boring is the way they are taught. I am going to address my main frustrations on this matter together with proposed solutions and a guide for those who want to start learning alone.

  • [Old] Perl Is Still The Goddess For Text Manipulation

    You heard me. Freedom is the word here with Perl.

    When I’m coding freely at home on my fun data science project, I rely on it to clean up my data.

    In the real world, data is often collected with loads of variations. Unless you are using someone’s “clean” dataset, you better learn to clean that data real fast.

    Yes, Perl is fast. It’s lightening fast.