Planet Debian

Subscribe to Planet Debian feed
Planet Debian - https://planet.debian.org/
Updated: 42 min 25 sec ago

Jaskaran Singh: GSoC Project Overview & Week 1

2 June, 2019 - 07:00
Overview:

Here’s a quick rundown on my project for this summer:

The Debian Patch Porting System aims to systematize and partially automate the security patch porting process.

The number of security vulnerability identifiers is quite large- these are relevant to specific distributions, organizations and applications. Each organization handles security vulnerabilities that are relevant to them in their own way. MITRE’s vulnerability identifier called Common Vulnerabilities and Exposures (CVE) is global, and most advisories are somehow related to a CVE.

The purpose of the system is to unify all these algorithmically for easy patch finding, management and application. The system would be able to take any vulnerability as input and extract patches w/r/t that vulnerability. Patches can be collected by employing certain patch finding methods. Some of these methods are to crawl sites, trackers, and various distributions’ respositories. Along with that, general purpose information about that vulnerability and its equivalent identifiers for other organizations could also be collected to get the vulnerability’s complete profile. This profile could then be stored in a NoSQL database.

Following this, the system would then test whether the patches are applicable for the upstream source that they are for. Patching heuristics can be employed to test the patch’s applicability in the source package. Some of these heuristics are fuzzing, patching w/r/t offsets, etc.

The nature of the system is to be generic enough so that it can fit in with Debian (maybe allow use with the Debian Security Tracker), or act independently as well.

GSoC:

The focus in this GSoC would be to design a flexible crawler i.e. a patch finder. The patch finder would primarily find patches for a given vulnerability, and optionally a given source package. Implementing the patch finder would require a modular implementation of certain patch finding methods, which would be based extensively on web crawling. A very simple example of this is to extract patches from fixed versions of a Debian package, as these are mostly in the debian/patches folder.

My mentors for this project are Luciano Bello and László Böszörményi (GCS). Luciano started this project in 2017 and implemented it, but due to its limited scope, he felt re-doing what has been done with a broader vision in mind was called for. You can find his and his team’s work here.

Prior to this week was the Community Bonding Period. Most of that time was spent in discussion about the ins and outs of the system, its scope, ultimate goal, and design. We also decided on how and when conference conversations should take place, mainly on Hangouts.

GSoC’s coding period commenced on 27th May 2019. Due to my university examinations till 3rd June 2019, I found putting in the required 40 hours for the first week a bit difficult, so I chose a task that would require minimal effort and could be completed in under week. I decided on setting up the base of the implementation, mostly classes that would be used in the input and output of the patch finder, and then tested these. I won’t go into implementation specific details as there’s not much to talk about yet code-wise. You can check out the code and follow our progress in the GitHub repository. As our prime language, we’ve chosen Python3.

Feel free to contact me on the address in the footer.

Jonathan Carter: Free Software Activities (2019-05)

2 June, 2019 - 01:37

A relatively quiet free software month, I’m feeling the Debian Buster final freeze fatigue for sure. Also dealt with a bunch of personal and work stuff that kept me busy otherwise, and also, haven’t been very good at logging activities so this will be short one…

Debian packaging work

2019-05-01: Upload live-wrapper (0.10) to debian unstable (Closes: #927216, #927217).

2019-05-01: Upload live-tasks (0.6) to debian unstable (Closes: #924211, #924214, #925331).

2019-05-16: Upload live-tasks (0.7) to debian unstable (Closes: #866391)

2019-05-24: File unblock request for live-tasks (0.7)

Debian live

2019-05-01: Update debian-live local scripts to fix stale fstab, duplicate sources.list entries.

2019-05-02: Full testing on daily build media.

2019-05-02: Prepare Debian Live RC1 announcement.

2019-05-03: Spot check testing on RC1 builds.

DebConf

2019-05-01: Submit DebConf BoF proposal for “100 Paper cuts kick-off“.

2019-05-01: Post initial bursary results.

2019-05-02: Post bursary results for smaller (<$200) amounts.

2019-05-02: Submit DebConf BoF proposal for “Debian Live“.

And lots of bursaries admin throughout the month. To be honest I’m glad that the bulk of it is mostly over.

Molly de Blanc: Free software activities (May, 2019)

1 June, 2019 - 21:34
Personal
  • I attended the two-day Open Source Initiative board of directors Spring face-to-face meeting where I joined the Staffing and Fundraising committees and was elected President of the board of directors. More details on this upcoming in my next OSI blog post.
  • We had some OSI meetings in addition to the F2F — namey the Staffing Committee and then meeting between the GM, myself, and the VP.
  • I submitted to the Open Source Summit EU CfP.
  • May brought the 11th instance of someone being mean to me on the internet.
  • We had an Anti-harassment team meeting.
  • Outreachy and GSoC hurtled forward.
  • I did a bunch of writing on free and open source software.
  • I finally celebrated becoming a DD by having a pancake party with some of my favorite free software people. Believe me, some of you who didn’t make it (or didn’t know about it) were sorely missed.
  • Free as in Freedom published their interview with me and the recording of my talk from Copyleft Conf 2019!
Professional
  • Exciting things to be announced IN THE FUTURE!

Wouter Verhelst: Moved!

1 June, 2019 - 19:48

A few months ago, I moved from Mechelen, Belgium to Cape Town, South Africa.

No, that's not the view outside my window. But Muizenberg beach is just a few minutes away by car. And who can resist such a beach? Well, if you ignore the seaweed, that is.

Getting settled after a cross-continental move takes some time, especially since the stuff that I decided I wanted to take with me would need to be shipped by boat, and that took a while to arrive. Additionally, the reason of the move was to move in with someone, and having two people live together for the first time requires some adjustment in their daily routine; and that is no different for us.

After having been here for several months now, however, things are pulling together:

I had a job lined up before I moved to cape town; but there were a few administrative issues in getting started, which meant that I had to wait at home for a few months while my savings were being reduced to almost nothingness. That is now mostly resolved (except that there seem to be a few delays with payment, but nothing that can't be resolved).

My stuff arrived a few weeks ago. Unfortunately the shipment was not complete; the 26" 16:10 FullHD monitor that I've had for a decade or so now, somehow got lost. I contacted the shipping company and they'll be looking into things, but I'm not hopeful. Beyond that, there were only a few minor items of damage (one of the feet of the TV broke off, and a few glasses broke), but nothing of real consequence. At least I did decide to go for the insurance which should cover loss and breakage, so worst case I'll just have to buy a new monitor (and throw away a few pieces of debris).

While getting settled, it was harder for me to spend quality time on doing free software- or Debian-related things, but I did manage to join Gerry and Mark to do some FOSDEM-related video review a while ago (meaning, all the 2019 videos that could be released have been released now), and spent some time configuring the Debian SReview instance for the Marseille miniconf last weekend, and will do the same for the Hamburg one that will heppening soon. Additionally, there have been some comments on the upstream nbd mailinglist that I cooperated with.

All in all, I guess it's safe to say that I'm slowly coming out of hibernation. Up next: once the payment issues have been fully resolved and I can spend money with a bit more impudence, join a local choir and/or orchestra and/or tennis club, and have some off time.

Russ Allbery: podlators 4.12

1 June, 2019 - 10:58

This release only fixes a test suite issue. I've been putting it off for ages because I was hoping to pick up some previous discussions and make some more substantive changes, but that hasn't happened yet and I keep getting mail from failing tests. Worse, a few other people have investigated the problem helpfully, and I don't want to waste more of anyone's time!

Also, I noticed I'd not posted anything but book reviews for this month, so wanted to do at least one software release, even if trivial.

Anyway, sometimes the Encode module gets loaded before the test suite for podlators, which makes it impossible to test the warnings that happen if Encode isn't available. That's fine, except that the test failed entirely in that case, instead of being skipped. This release fixes it to be skipped properly.

You can get the latest release from the podlators distribution page.

Paul Wise: FLOSS Activities May 2019

1 June, 2019 - 06:41
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

31 May, 2019 - 22:22

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

31 May, 2019 - 22:14

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

31 May, 2019 - 19:15

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

31 May, 2019 - 18:01

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:

  • 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

31 May, 2019 - 10:43

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

Jonathan Dowland: Multi-architecture OpenShift containers

30 May, 2019 - 15:56

Following the initial release of RHEL8-based OpenJDK OpenShift container images, we have now pushed PPC64LE and Aarch64 architecture variants to the Red Hat Container Registry. This is the first time I've pushed Aarch64 images in particular, and I'm excited to work on Aarch64-related issues, should any crop up!

Sean Whitton: Debian Policy call for participation -- May 2019

30 May, 2019 - 06:35

There has been very little activity in recent weeks (preparing the Debian buster release is more urgent than the Policy Manual for most contributors), so the list of bugs I posted in February is still valid.

Bits from Debian: Ask anything you ever wanted to know about Debian Edu!

29 May, 2019 - 22:30

You have heard about Debian Edu or Skolelinux, but do you know exactly what we are doing?

Join us on the #debian-meeting channel on the OFTC IRC network on 03 June 2019 at 12:00 UTC for an introduction to Debian Edu, a Debian pure blend created to fit the requirements of schools and similar institutions.

You will meet Holger Levsen, contributing to Debian Edu since 2005 and member of development team. Ask him anything you ever wanted to know about Debian Edu!

Your IRC nick needs to be registered in order to join the channel. Refer to the Register your account section on the oftc website for more information on how to register your nick.

You can always refer to the debian-meeting wiki page for the latest information and up to date schedule.

Michal &#268;iha&#345;: Spring cleanup

29 May, 2019 - 15:15

What you can probably spot from past posts on my blog, my open source contributions are heavily focused on Weblate and I've phased out many other activities. The main reason being reduced amount of free time with growing family, what leads to focusing on project which I like most. It's fun to develop it and it seems like it will work business wise as well, but that's still something to be shown in the future.

Anyway it's time to admit that I will not spend much time on other things in near future.

Earlier this year, I've resigned from being phpMyAdmin project admin. I was in this role for three years and I've been contributing to the project for 18 years. It has been time, but I haven't contributed significantly in last few months. I will stay with the project for few more months to handle smooth transition, but it's time to say good bye there.

On the Debian project I want to stay active, but I've reduced my involvement and I'm looking for maintainers for some of my packages (mostly RPM related). The special case is the phpMyAdmin package where I was looking for help since 2017, but it still didn't help from the package becoming heavily outdated with security issues what lead to it's removal from Buster. It seems that this has triggered enough attention to resurrect work on the updated packages.

Today I've gone through my personal repos on GitHub and I've archived bunch of them. These have not received any attention for years (many of them were dead by the time I've imported them to GitHub) and it's good to clearly show that to random visitors.

I'm still main developer behind Gammu, but I'm not really doing there more than occasional review of pull requests and merging them. I don't want to abandon the project without handing it out to somebody else, but the problem is that there is nobody else right now.

Filed under: Debian English Gammu SUSE

Russ Allbery: Review: Nimona

29 May, 2019 - 11:28

Review: Nimona, by Noelle Stevenson

Publisher: HarperTeen Copyright: 2015 ISBN: 0-06-227822-3 Format: Graphic novel Pages: 266

Ballister Blackheart is a supervillain, the most notorious supervillain in the kingdom. He used to be a knight, in training at the Institute alongside his friend Goldenloin. But then he defeated Goldenloin in a joust and Goldenloin blew his arm off with a hidden weapon. Now, he plots against the Institute and their hero Sir Goldenloin, although he still follows certain rules.

Nimona, on the other hand, is not convinced by rules. She shows up unexpectedly at Ballister's lair, declaring herself to be his sidekick, winning him over to the idea when she shows that she's also a shapeshifter. And Ballister certainly can't argue with her effectiveness, but her unconstrained enthusiasm for nefarious schemes is rather disconcerting. Ballister, Goldenloin, and the Institute have spent years in a careful dance with unspoken rules that preserved a status quo. Nimona doesn't care about the status quo at all.

Nimona is the collected form of a web comic published between 2012 and 2014. It has the growth curve of a lot of web comics: the first few chapters are lightweight and tend more towards gags, the art starts off fairly rough, and there is more humor than plot. But by chapter four, Stevenson is focusing primarily on the fascinating relationship between Ballister and Nimona, and there are signs that Nimona's gleeful enthusiasm for villainy is hiding something more painful. Meanwhile, the Institute, Goldenloin's employer, quickly takes a turn for the sinister. They're less an organization of superheroes than a shadow government with some dubious goals, and Ballister starts looking less like a supervillain and more like a political revolutionary.

Nimona has some ideas about revolution, most of them rather violent.

At the start of this collection, I wasn't sure how much I'd like it. It's mildly amusing in a gag sort of way while playing with cliches and muddling together fantasy, science fiction, faux-medieval politics, sinister organizations, and superheros. But the story deepens as it continues. Ballister starts off caring about Nimona because he's a fundamentally decent person, but she becomes a much-needed friend. Nimona's villain-worship, to coin a phrase, turns into something more nuanced. And while that's happening, the Institute becomes increasingly sinister, and increasingly dangerous. By the second half of the collection, despite the somewhat excessive number of fight scenes, it was very hard to put down.

Sadly, I didn't think that Stevenson landed the ending. It's not egregiously bad, and the last page partly salvages it, but it wasn't the emotionally satisfying catharsis that I was looking for. The story got surprisingly dark, and I wanted a bit more of a burst of optimism and happiness at the end.

I thought the art was good but not great. The art gets more detailed and more nuanced as the story deepens, but Stevenson stays with a flat, stylized appearance to her characters. The emotional weight comes mostly from the dialogue and from Nimona's expressive transformations rather than the thin and simple faces. But there's a lot of energy in the art, a lot of drama when appropriate, and some great transitions from human scale to the scale of powerful monsters.

That said, I do have one major complaint: the lettering. It's hand-lettered (so far as I can tell) in a way that adds a distinctive style, but the lettering is also small, wavers a bit, and is sometimes quite hard to read. Standard comic lettering is, among other things, highly readable in small sizes; Stevenson's more individual lettering is not, and I occasionally struggled with it.

Overall, this isn't in my top tier of graphic novels, but it was an enjoyable afternoon's reading that hooked me thoroughly and that I was never tempted to put down. I think it's a relatively fast read, since there are a lot of fight scenes and not a lot of detail that invites lingering over the page. I wish the lettering were more uniform and I wasn't entirely happy with the ending, but if slowly-developing unexpected friendship, high drama, and an irrepressible shapeshifter who is more in need of a friend than she appears sounds like something you'd like, give this a try.

Rating: 7 out of 10

Jonathan McDowell: More Yak Shaving: Moving to nftables to secure Home Assistant

29 May, 2019 - 03:17

When I setup Home Assistant last year one of my niggles was that it wanted an entire subdomain, rather than being able to live under a subdirectory. I had a desire to stick various things behind a single SSL host on my home network (my UniFi controller is the other main one), rather than having to mess about with either SSL proxies in every container running a service, or a bunch of separate host names (in particular one for the backend and one for the SSL certificate, for each service) in order to proxy in a single host.

I’ve recently done some reorganisation of my network, including building a new house server (which I’ll get round to posting about eventually) and decided to rethink the whole SSL access thing. As a starting point I had:

  • Services living in their own containers
  • Another container already running Apache, with SSL enabled + a valid external Let’s Encrypt certificate

And I wanted:

  • SSL access to various services on the local network
  • Not to have to run multiple copies of Apache (or any other TLS proxy)
  • Valid SSL certs that would validate correctly on browsers without kludges
  • Not to have to have things like hass-host as the front end name and hass-backend-host as the actual container name.

It dawned on me that all access to the services was already being directed through the server itself, so there was a natural redirection point. I hatched a plan to do a port level redirect there, sending all HTTPS traffic to the service containers to the container running Apache. It would then be possible to limit access to the services (e.g. port 8123 for Home Assistant) to the Apache host, tightening up access, and the actual SSL certificate would have the service name in it.

First step was to figure out how to do the appropriate redirection. I was reasonably sure this would involve some sort of DNAT in iptables, but I couldn’t find a clear indication that it was possible (there was a lot of discussion about how you also ended up needing SNAT, and I needed multiple redirections to 443 on the Apache container, so that wasn’t going to fly). Having now solved the problem I think iptables could have done it just fine, but I ended up being steered down the nftables route. This is long overdue; it’s been available since Linux 3.13 but lacking a good reason to move beyond iptables I hadn’t yet done so (in the same way I clung to ipfwadm and ipchains until I had to move).

There’s a neat tool, iptables-restore-translate, which can take the output of iptables-save and provide a simple translation to nftables. That was a good start, but what was neater was moving to the inet filter instead of ip which then mean I could write one set of rules which applied to both IPv4 and IPv6 services. No need for rule duplication! The ability to write a single configuration file was nicer than the sh script I had to configure iptables as well. I expect to be able to write a cleaner set of rules as I learn more, and although it’s not relevant for the traffic levels I’m shifting I understand the rule parsing is generally more efficient if written properly.Finally there’s an nftables systemd service in Debian, so systemctl enable nftables turned on processing of /etc/nftables.conf on restart rather than futzing with a pre-up in /etc/network/interfaces.

With all the existing config moved over the actual redirection was easy. I added the following block to the end of nftables.conf (I had no NAT previously in place), which redirects HTTPS traffic directed at 192.168.2.3 towards 192.168.2.2 instead.

nftables dnat configuration
table ip nat {
        chain prerouting {
                type nat hook prerouting priority 0
                # Redirect incoming HTTPS to Home Assistant to Apache proxy
                iif "enp24s0" ip daddr 192.168.2.3 tcp dport https \
                        dnat 192.168.2.2
        }
        chain postrouting {
                type nat hook postrouting priority 100
        }
}

I think the key here is I can guarantee that any traffic coming back from the Apache proxy is going to pass through the host doing the DNAT; each container has a point-to-point link configured rather than living on a network bridge. If there was a possibility traffic from the proxy could go direct to the requesting host (e.g. they were on a shared LAN) then you’d need to do SNAT as well so the proxy would return the traffic to the NAT host which would then redirect to the requesting host.

Apache was then configured as a reverse proxy, with my actual config ending up as follows. For now I’ve restricted access to within my house; I’m still weighing up the pros and cons of exposing access externally without the need for a tunnel. The domain I used on my internal network is a proper registered thing, so although I don’t expose any IP addresses externally I’m able to use Mythic Beasts’ DNS validation instructions and have a valid cert.

Apache proxy config for Home Assistant
<VirtualHost *:443>
        ServerName hass-host

        ProxyPreserveHost On
        ProxyRequests off
        RewriteEngine on

        # Anything under /local/ we serve, otherwise proxy to Home Assistant
        RewriteCond %{REQUEST_URI} '/local/.*'
        RewriteRule .* - [L]
        RewriteCond %{HTTP:Upgrade} =websocket [NC]
        RewriteRule /(.*) ws://hass-host:8123/$1 [P,L]
        ProxyPassReverse /api/websocket ws://hass-host:8123/api/websocket
        RewriteCond %{HTTP:Upgrade} !=websocket [NC]
        RewriteRule /(.*) http://hass-host:8123/$1 [P,L]
        ProxyPassReverse / http://hass-host:8123/

        SSLEngine on
        SSLCertificateFile /etc/ssl/le.crt
        SSLCertificateKeyFile /etc/ssl/private/le.key
        SSLCertificateChainFile /etc/ssl/lets-encrypt-x3-cross-signed.crt

        # Static files can be hosted here instead of via Home Assistant
        Alias /local/ /srv/www/hass-host/
        <Directory /srv/www/hass-host/>
                Options -Indexes
        </Directory>

        # Only allow access from inside the house
        ErrorDocument 403 "Not for you."
        <Location />
                Order Deny,Allow
                Deny from all
                Allow from 192.168.1.0/24
        </Location>
</VirtualHost>

I’ve done the same for my UniFi controller; the DNAT works exactly the same, while the Apache reverse proxy config is slightly different - a change in some of the paths and config to ignore the fact there’s no valid SSL cert on the controller interface.

Apache proxy config for Unifi Controller
<VirtualHost *:443>
	ServerName unifi-host

	ProxyPreserveHost On
	ProxyRequests off

	SSLProxyEngine on
	SSLProxyVerify off
	SSLProxyCheckPeerCN off
	SSLProxyCheckPeerName off
	SSLProxyCheckPeerExpire off

	AllowEncodedSlashes NoDecode
	ProxyPass /wss/ wss://unifi-host:8443/wss/
	ProxyPassReverse /wss/ wss://unifi-host:8443/wss/
	ProxyPass / https://unifi-host:8443/
	ProxyPassReverse / https://unifi-host:8443/

	SSLEngine on
	SSLCertificateFile /etc/ssl/le.crt
	SSLCertificateKeyFile /etc/ssl/private/le.key
	SSLCertificateChainFile /etc/ssl/lets-encrypt-x3-cross-signed.crt

	# Only allow access from inside the house
	ErrorDocument 403 "Not for you."
	<Location />
		Order Deny,Allow
		Deny from all
		Allow from 192.168.1.0/24
	</Location>
</VirtualHost>

(worth pointing out that one of my other Home Assistant niggles has also been fixed - there’s now the ability to setup multiple users and separate out API access to OAuth, rather than a single password providing full access. It still needs more work in terms of ACLs for users, but that’s a bigger piece of work.)

Joachim Breitner: Ιωακείμ

28 May, 2019 - 20:24

At a dance event in Freiburg someone told me that my first name would be spelled Ιωακείμ in Greek.

I am happy that my name contains ω (the first infinite ordinal, α (which identifies programs that differ only in names), ε (the crucial variable in a calculus proofs) and μ (which builds recursive types).

Sorry ι and κ, you just aren’t that cool.

Debian GSoC Kotlin project blog: Welcome to the Debian Kotlin GSoC blog

28 May, 2019 - 14:25

I’ll be using this blog to track progress on packaging Kotlin and report on what I am doing during the GSoC period. So let me go on a head and start with the current progress in packaging Kotlin.

Packaging Kotlin Kotlin 1.1.1

During GSoC 2018 I tried to package kotlin-1.1.1 because it was built with ant and looked easy, but as it turned out it had its shortcomings. For starters, since it was very old, it missed a lot of the dependencies that were supposed to be up and hosted by Jetbrains. I had to patch up these dependencies with the closest matching versions and got things building. Recently it ran into a massive hiccup and the problem just couldn't be solved as I couldn't figure which dependency was causing it. I opened an issue with Jetbrains and the conclusion I arrived at was that Kotlin 1.1.1 is too old and not supported anymore.

So following the advice of the Kotlin devs I have proceeded to take on the task of packaging Kotlin 1.3.30 (a couple months old version) into Debian.

Kotlin 1.3.30

This is my Google Summer of Code 2019 project.

This is the source for Kotlin 1.3.30. Unlike Kotlin 1.1.1, Kotlin 1.3.30 had everything it needed to build successfully already hosted. So I went on ahead and split the work into 3 subtasks as follows:

  1. Convert all gradle build scripts from kts to groovy so that we dont have to depend on kotlin-gradle-dsl.
  2. Downgrade the build from gradle 5.1 to gradle 4.4.1 which is the version available in Debian Sid.
  3. Package the dependencies of Kotlin 1.3.30 so that it builds fine using packages from the Debian Sid software environment alone.

A major blocker for this would in 3, when we are packaging the dependencies of Kotlin 1.3.30. We would have to package IDEA and this will be a huge task. Also yesterday I noted that Jetbrains has stopped hosting Kotlin 1.3.30-eap-28 gradle plugin which is the bootstrap for Kotlin 1.3.30. I have gotten things to build with 1.3.30 gradle plugin and have opened an issue with Jetbrains asking them to prolong hosting the dependecies for Kotlin 1.3.30.

You can see my work on kotlin 1.3.30 here and I will be posting here in this blog once every week with the major updates. You can find me as m36[m] or m36 in #debian-java or #debian-mobile channels hosted at OFTC.

Kees Cook: security things in Linux v5.1

28 May, 2019 - 10:49

Previously: v5.0.

Linux kernel v5.1 has been released! Here are some security-related things that stood out to me:

introduction of pidfd
Christian Brauner landed the first portion of his work to remove pid races from the kernel: using a file descriptor to reference a process (“pidfd”). Now /proc/$pid can be opened and used as an argument for sending signals with the new pidfd_send_signal() syscall. This handle will only refer to the original process at the time the open() happened, and not to any later “reused” pid if the process dies and a new process is assigned the same pid. Using this method, it’s now possible to racelessly send signals to exactly the intended process without having to worry about pid reuse. (BTW, this commit wins the 2019 award for Most Well Documented Commit Log Justification.)

explicitly test for userspace mappings of heap memory
During Linux Conf AU 2019 Kernel Hardening BoF, Matthew Wilcox noted that there wasn’t anything in the kernel actually sanity-checking when userspace mappings were being applied to kernel heap memory (which would allow attackers to bypass the copy_{to,from}_user() infrastructure). Driver bugs or attackers able to confuse mappings wouldn’t get caught, so he added checks. To quote the commit logs: “It’s never appropriate to map a page allocated by SLAB into userspace” and “Pages which use page_type must never be mapped to userspace as it would destroy their page type”. The latter check almost immediately caught a bad case, which was quickly fixed to avoid page type corruption.

LSM stacking: shared security blobs
Casey Shaufler has landed one of the major pieces of getting multiple Linux Security Modules (LSMs) running at the same time (called “stacking”). It is now possible for LSMs to share the security-specific storage “blobs” associated with various core structures (e.g. inodes, tasks, etc) that LSMs can use for saving their state (e.g. storing which profile a given task confined under). The kernel originally gave only the single active “major” LSM (e.g. SELinux, Apprmor, etc) full control over the entire blob of storage. With “shared” security blobs, the LSM infrastructure does the allocation and management of the memory, and LSMs use an offset for reading/writing their portion of it. This unblocks the way for “medium sized” LSMs (like SARA and Landlock) to get stacked with a “major” LSM as they need to store much more state than the “minor” LSMs (e.g. Yama, LoadPin) which could already stack because they didn’t need blob storage.

SafeSetID LSM
Micah Morton added the new SafeSetID LSM, which provides a way to narrow the power associated with the CAP_SETUID capability. Normally a process with CAP_SETUID can become any user on the system, including root, which makes it a meaningless capability to hand out to non-root users in order for them to “drop privileges” to some less powerful user. There are trees of processes under Chrome OS that need to operate under different user IDs and other methods of accomplishing these transitions safely weren’t sufficient. Instead, this provides a way to create a system-wide policy for user ID transitions via setuid() (and group transitions via setgid()) when a process has the CAP_SETUID capability, making it a much more useful capability to hand out to non-root processes that need to make uid or gid transitions.

ongoing: refcount_t conversions
Elena Reshetova continued landing more refcount_t conversions in core kernel code (e.g. scheduler, futex, perf), with an additional conversion in btrfs from Anand Jain. The existing conversions, mainly when combined with syzkaller, continue to show their utility at finding bugs all over the kernel.

ongoing: implicit fall-through removal
Gustavo A. R. Silva continued to make progress on marking more implicit fall-through cases. What’s so impressive to me about this work, like refcount_t, is how many bugs it has been finding (see all the “missing break” patches). It really shows how quickly the kernel benefits from adding -Wimplicit-fallthrough to keep this class of bug from ever returning.

stack variable initialization includes scalars
The structleak gcc plugin (originally ported from PaX) had its “by reference” coverage improved to initialize scalar types as well (making “structleak” a bit of a misnomer: it now stops leaks from more than structs). Barring compiler bugs, this means that all stack variables in the kernel can be initialized before use at function entry. For variables not passed to functions by reference, the -Wuninitialized compiler flag (enabled via -Wall) already makes sure the kernel isn’t building with local-only uninitialized stack variables. And now with CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL enabled, all variables passed by reference will be initialized as well. This should eliminate most, if not all, uninitialized stack flaws with very minimal performance cost (for most workloads it is lost in the noise), though it does not have the stack data lifetime reduction benefits of GCC_PLUGIN_STACKLEAK, which wipes the stack at syscall exit. Clang has recently gained similar automatic stack initialization support, and I’d love to this feature in native gcc. To evaluate the coverage of the various stack auto-initialization features, I also wrote regression tests in lib/test_stackinit.c.

That’s it for now; please let me know if I missed anything. The v5.2 kernel development cycle is off and running already. :)

© 2019, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

Pages

Creative Commons License ลิขสิทธิ์ของบทความเป็นของเจ้าของบทความแต่ละชิ้น
ผลงานนี้ ใช้สัญญาอนุญาตของครีเอทีฟคอมมอนส์แบบ แสดงที่มา-อนุญาตแบบเดียวกัน 3.0 ที่ยังไม่ได้ปรับแก้