Here s my (eleventh) monthly update about the activities I ve done in the F/L/OSS world.
Debian
This was my 20th month of contributing to Debian.
I became a DM in late March last year and a DD last Christmas! \o/
Well, this month we had DebConf! \o/
(more about this later this week!)
Anyway, here are the following things I did in Debian this month:
Uploads and bug fixes:
rubocop (0.89.1+dfsg-1) - New upstream version for RuboCop::Packaging.
ruby-rubocop-ast (0.3.0+dfsg-1) - New upstream version for RuboCop's latest version.
Also, I log daily updates at gsocwithutkarsh2102.tk.
Since this is a wrap and whilst the daily updates are already available at the above site^, I ll quickly mention the important points and links here.
Continuation of GSoC for other Ruby related stuff!
Whilst working on Rubocop::Packaging, I contributed to more Ruby projects, refactoring their library a little bit and mostly fixing RuboCop issues and fixing issues that the Packaging extension reports as offensive .
Following are the PRs that I raised:
Debian (E)LTS
Debian Long Term Support (LTS) is a project to extend the lifetime of all Debian stable releases to (at least) 5 years. Debian LTS is not handled by the Debian security team, but by a separate group of volunteers and companies interested in making it a success.
And Debian Extended LTS (ELTS) is its sister project, extending support to the Jessie release (+2 years after LTS support).
This was my eleventh month as a Debian LTS and my second as a Debian ELTS paid contributor.
I was assigned 21.75 hours for LTS and 14.25 hours for ELTS and worked on
the following things:
Started working on uwsgi update for CVE-2020-11984. It seems that src:apache2 wasn t affected by that, but src:uwsgi was.
ELTS CVE Fixes and Announcements:
Issued ELA 255-1, fixing CVE-2020-14344, for libx11.
For Debian 8 Jessie, these problems have been fixed in version 2:1.6.2-3+deb8u3.
Issued ELA 259-1, fixing CVE-2020-10177, for pillow.
For Debian 8 Jessie, these problems have been fixed in version 2.6.1-2+deb8u5.
Issued ELA 269-1, fixing CVE-2020-11985, for apache2.
For Debian 8 Jessie, these problems have been fixed in version 2.4.10-10+deb8u17.
Started working on clamAV update, it s a major bump from v0.101.5 to v0.102.4. There were lots of movings parts. Contacted upstream maintainers to help reduce the risk of regression. Came up with a patch to loosen the libcurl version requirement. Hopefully, the update could be rolled out soon!
Other (E)LTS Work:
I spent an additional 11.15 hours working on compiling the responses of the LTS survey and preparing a gist of it for its presentation during the Debian LTS BoF at DebConf20.
Here is my transparent report for my work on the Debian Long Term Support (LTS) and Debian Extended Long Term Support (ELTS), which extend the security support for past Debian releases, as a paid contributor.
In August, the monthly sponsored hours were split evenly among contributors depending on their max availability - I was assigned 21.75h for LTS (out of my 30 max; all done) and 14.25h for ELTS (out of my 20 max; all done).
We had a Birds of a Feathervideoconfsession at DebConf20, sadly with varying quality for participants (from very good to unusable), where we shared the first results of the LTS survey.
There were also discussions about evaluating our security reactivity, which proved surprisingly hard to estimate (neither CVE release date and criticality metrics are accurate nor easily available), and about when it is appropriate to use public naming in procedures.
Interestingly ELTS gained new supported packages, thanks to a new sponsor -- so far I'd seen the opposite, because we were close to the EOL.
As always, there were opportunities to de-dup work through mutual cooperation with the Debian Security team, and LTS/ELTS similar updates.
ELTS - Jessie
Fresh build VMs
rails/redmine: investigate issue, initially no-action as it can't be reproduced on Stretch and isn't supported in Jessie; follow-up when it's supported again
ghostscript: global triage: identify upstream fixed version, distinguish CVEs fixed within a single patch, bisect non-reproducible CVEs, reference missing commit (including at MITRE)
Here s my (tenth) monthly update about the activities I ve done in the F/L/OSS world.
Debian
This was my 17th month of contributing to Debian.
I became a DM in late March last year and a DD last Christmas! \o/
Well, this month I didn t do a lot of Debian stuff, like I usually do, however, I did a lot of things related to Debian (indirectly via GSoC)!
Anyway, here are the following things I did this month:
Also, I log daily updates at gsocwithutkarsh2102.tk.
Whilst the daily updates are available at the above site^, I ll breakdown the important parts of the later half of the second month here:
Marc Andre, very kindly, helped in fixing the specs that were failing earlier this month. Well, the problem was with the specs, but I am still confused how so. Anyway..
Finished documentation of the second cop and marked the PR as ready to be reviewed.
David reviewed and suggested some really good changes and I fixed/tweaked that PR as per his suggestion to finally finish the last bits of the second cop, RelativeRequireToLib.
Merged the PR upon two approvals and released it as v0.2.0!
We had our next weekly meeting where we discussed the next steps and the things that are supposed to be done for the next set of cops.
Introduced rubocop-packaging to the outer world and requested other upstream projects to use it! It is being used by 13 other projects already!
Started to work on packaging-style-guide but I didn t push anything to the public repository yet.
Worked on refactoring the cops_documentation Rake task which was broken by the new auto-corrector API. Opened PR #7 for it. It ll be merged after the next RuboCop release as it uses CopsDocumentationGenerator class from the master branch.
Whilst working on autoprefixer-rails, I found something unusual. The second cop shouldn t really report offenses if the require_relative calls are from lib to lib itself. This is a false-positive. Opened issue #8 for the same.
Continuation of GSoC for other Ruby related stuff!
Whilst working on rubocop-packaging, I contributed to more Ruby projects, refactoring their library a little bit and mostly fixing RuboCop issues and fixing issues that the Packaging extension reports as offensive .
Following are the PRs that I raised:
Debian (E)LTS
Debian Long Term Support (LTS) is a project to extend the lifetime of all Debian stable releases to (at least) 5 years. Debian LTS is not handled by the Debian security team, but by a separate group of volunteers and companies interested in making it a success.
And Debian Extended LTS (ELTS) is its sister project, extending support to the Jessie release (+2 years after LTS support).
This was my tenth month as a Debian LTS and my first as a Debian ELTS paid contributor.
I was assigned 25.25 hours for LTS and 13.25 hours for ELTS and worked on
the following things:
Other(s)
Sometimes it gets hard to categorize work/things into a particular category.
That s why I am writing all of those things inside this category.
This includes two sub-categories and they are as follows.
Personal:
This month I did the following things:
Released v0.2.0 of rubocop-packaging on RubyGems!
It s open-sourced and the repository is here.
Bug reports and pull requests are welcomed!
Released v0.1.0 of get_root on RubyGems!
It s open-sourced and the repository is here.
Wrote max-word-frequency, my Rails C1M2 programming assignment.
And made it pretty neater & cleaner!
Refactored my lts-dla and elts-ela scripts entirely and wrote them in Ruby so that there are no issues and no false-positives!
Check lts-dla here and elts-ela here.
And finally, built my first Rails (mini) web-application!
The repository is here. This was also a programming assignment (C1M3).
And furthermore, hosted it at Heroku.
Open Source:
Again, this contains all the things that I couldn t categorize earlier.
Opened several issues and PRs:
Issue #8273 against rubocop, reporting a false-positive auto-correct for Style/WhileUntilModifier.
Issue #615 against http reporting a weird behavior of a flaky test.
PR #3791 for rubygems/bundler to remove redundant bundler/setup require call from spec_helper generated by bundle gem.
Issue #3831 against rubygems, reporting a traceback of undefined method, rubyforge_project=.
Issue #238 against nheko asking for enhancement in showing the font name in the very font itself.
PR #2307 for puma to constrain rake-compiler to v0.9.4.
And finally, I joined the Cucumber organization! \o/
Thank you for sticking along for so long :)
Until next time. :wq for today.
Here s my (ninth) monthly update about the activities I ve done in the F/L/OSS world.
Debian
This was my 16th month of contributing to Debian.
I became a DM in late March last year and a DD last Christmas! \o/
This month was a little intense. I did a lot of different kinds of things in Debian this month. Whilst most of my time went on doing security stuff, I also sponsored a bunch of packages.
Here are the following things I did this month:
Uploads and bug fixes:
rails (2:5.2.4.3+dfsg-1) - fix a bunch of CVEs in Sid and Bullseye.
Sponsored ruby-ast for Abraham, libexif for Hugh, djangorestframework-gis and karlseguin-ccache for Nilesh, and twig-extensions, twig-i18n-extension, and mariadb-mysql-kbs for William.
GSoC Phase 1, Part 2!
Last month, I got selected as a Google Summer of Code student for Debian again! \o/
I am working on the Upstream-Downstream Cooperation in Ruby project.
The first half of the first month is blogged here, titled, GSoC Phase 1.
Also, I log daily updates at gsocwithutkarsh2102.tk.
Whilst the daily updates are available at the above site^, I ll breakdown the important parts of the later half of the first month here:
Spread the word/usage about this tool/library via adding them in the official RuboCop docs.
We had our third weekly meeting where we discussed the next steps and the things that are supposed to be done for the next set of cops.
Wrote more tests so as to cover different aspects of the GemspecGit cop.
Opened PR #4 for the next Cop, RequireRelativeToLib.
Introduced rubocop-packaging to the outer world and requested other upstream projects to use it! It is being used by 6 other projects already
Had our fourth weekly meeting where we pair-programmed (and I sucked :P) and figured out a way to make the second cop work.
Found a bug, reported at issue #5 and raised PR #6 to fix it.
And finally, people loved the library/tool (and it s outcome):
(for those who don t know, @bbatsov is the author of RuboCop, @lienvdsteen is an amazing fullstack engineer at GitLab, and @pboling is the author of some awesome Ruby tools and libraries!)
Continuation of GSoC for other Ruby related stuff!
Whilst I have already mentioned it multiple times but it s still not enough to stress how amazing Antonio Terceiro and David Rodr guez are!
They re more than just mentors to me!
Well, only they know how much I trouble them with different things, which are not only related to my GSoC project but also extends to the projects they maintain! :P
David maintains rubygems and bundler and Antonio maintains debci.
So on days when I decide to hack on rubygems or debci, only I know how kind and nice David and Anotonio are to me!
They very patiently walk me through with whatever I am stuck on, no matter what and no matter when.
Thus, with them around, I contributed to these two projects and more, with regards to working on rubocop-packaging.
Following are a few things that I raised:
Debian LTS
Debian Long Term Support (LTS) is a project to extend the lifetime of all Debian stable releases
to (at least) 5 years. Debian LTS is not handled by the Debian security team, but by a separate group
of volunteers and companies interested in making it a success.
This was my ninth month as a Debian LTS paid contributor. I was assigned 30.00 hours and worked on
the following things:
Uploaded a fix for CVE-2020-11082, for ruby-kaminari.
This upload was for Sid and Bullseye and this CVE was fixed in version 1.0.1-6.
Uploaded a fix for CVE-2020-10663, for ruby-json, ruby2.1, and ruby2.5.
These uploads were for Stretch and Buster and were fixed in the version 2.3.3-1+deb9u8, 2.1.0+dfsg-2+deb10u1, 2.3.3-1+deb9u8, and 2.5.5-3+deb10u2.
Other(s)
Sometimes it gets hard to categorize work/things into a particular category.
That s why I am writing all of those things inside this category.
This includes two sub-categories and they are as follows.
Personal:
This month I did the following things:
Wrote and published v0.1.0 of rubocop-packaging on RubyGems!
It s open-sourced and the repository is here.
Bug reports and pull requests are welcomed!
Integrated a tiny (yet a powerful) hack to align images in markdown for my blog.
Commit here.
Here s my (eighth) monthly update about the activities I ve done in the F/L/OSS world.
Debian
This month marks my 15 months of contributing to Debian.
And 6th month as a DD! \o/
Whilst I love doing Debian stuff, I have started spending more time on the programming
side now. And I hope to keep it this for some time now.
Of course, I ll keep doing the Debian stuff, but just lesser in amount.
Anyway, the following are the things I did in May.
Experimenting and improving Ruby libraries FTW!
I have been very heavily involved with the Debian Ruby team for over an year now.
Thanks to Antonio Terceiro (and GSoC), I ve started experimenting and taking more
interest in upstream development and improvement of these libraries.
This has the sole purpose of learning. It has gotten fun since I ve started doing Ruby.
And I hope it stays this way.
This month, I opened some issues and proposed a few pull requests. They are:
Issue #802 against whenever for Ruby2.7 test failures.
Issue #8 against aggregate asking upstream for a release on rubygems.
Issue #104 against irb for asking more about Array.join("\n").
Issue #1391 against mail asking upstream to cut a new release.
Issue #1655 against rack reporting test failures in the CVE fix.
Debian LTS
Debian Long Term Support (LTS) is a project to extend the lifetime of all Debian stable releases
to (at least) 5 years. Debian LTS is not handled by the Debian security team, but by a separate group
of volunteers and companies interested in making it a success.
This was my eighth month as a Debian LTS paid contributor. I was assigned 17.25 hours and worked on
the following things:
CVE Fixes and Announcements:
Issued DLA 2191-1, fixing CVE-2020-10683, for dom4j.
For Debian 8 Jessie , this problem has been fixed in version 1.6.1+dfsg.3-2+deb8u2.
Issued DLA 2192-1, fixing CVE-2020-10663, for ruby2.1.
For Debian 8 Jessie , this problem has been fixed in version 2.1.5-2+deb8u10.
Issued DLA 2210-1, fixing CVE-2020-3810, for apt.
This update was prepared by the maintainer, Julian. I just took care of the paperwork.
For Debian 8 Jessie , this problem has been fixed in version 1.0.9.8.6.
Other(s)
Sometimes it gets hard to categorize work/things into a particular category.
That s why I am writing all of those things inside this category.
This includes two sub-categories and they are as follows.
Personal:
This month I could get the following things done:
Wrote and published my first Ruby gem/library/tool on RubyGems!
It s open-sourced and the repository is here.
Bug reports and pull requests are welcomed!
Wrote a small Ruby script (available here) to install Ruby gems from Gemfile(.lock).
Needed this when I hit a bug while using ruby-standalone, which Antonio fixed pretty quickly!
Here is my transparent report for my work on the Debian Long Term Support (LTS) and Debian Extended Long Term Support (ELTS), which extend the security support for past Debian releases, as a paid contributor.
In April, the monthly sponsored hours were split evenly among contributors depending on their max availability - I was assigned 28.75h for LTS (out of 30 max; all done) and 7.75h for ELTS (out of 20 max; I did 2.75).
Escalation procedures were (internally) documented with a focus on discussing issues with team coordinator(s) first.
Debian LTS had its first team meeting through IRC and lots of workflow question were discussed. This should help discuss questions that are a bit hard to bring up, and ensure everybody participates. There were lots of topics and it was a bit rushed, but this is something we want to repeat monthly now, possibly with audio/video in a couple months.
Remarks from last month's report were discussed, strengthening the Front-Desk role.
10% of the global funding is now reserved for infrastructure work. What kind of work, and who (LTS or external) will do the work, will be discussed further.
A fellow DD suggested (in a private conversation) that LTS may be taking time from the Debian Security team, due to additional commits to review. Conversely, this is another opportunity to mention all the global, non-LTS-specific work that LTS provides, which I usually highlight in my reports, and maybe I should be even more ELTS - Wheezy
CVE-2020-11612/netty: triage: ignored (deceptively hard to backport, OOM mitigation only)
mysql-connector-java: triage: in-progress (subscription-only update from Oracle, attempt to find more detail, waiting for public version)
CVE-2020-11868/ntp: global triage: identify and reference missing patch, coordinate with uploader
LTS - Jessie
netty, mysql-connector-java, ntp: common triage (see above)
CVE-2019-20637/varnish: global triage: attempt to reproduce, attempt to get PoC/vulnerable versions from upstream, update BTS
ansible: jessie triage: reset ignore->no-dsa old vulnerabilites after discussing with initial triager
ansible: global triage: identify more affected version ranges, locate more patches
ansible: prepare jessie upload (work-in-progress)
tiff: suites harmonization: offer to work on a tiff/stretch update, follow-up on maintainer's questions, who eventually did the update
dsa-needed.txt: identify stale entries from inactive LTS contributor, check for status
Here s my (seventh) monthly update about the activities I ve done in the F/L/OSS world.
Debian
It s been 14 months since I ve started contributing to Debian.
And 4 months since I ve been a Debian Developer. And in this beautiful time,
I had this opprotunity to do and learn lots of new and interesting things. And most
importantly, meet and interact with lots of lovely people!
Debian is $home.
Sponsored a lot of uploads for William Desportes and Adam Cecile.
Mentoring for newcomers.
FTP Trainee reviewing.
Moderation of -project mailing list.
Applied for DUCI project for Google Summer of Code 2020.
Ruby2.7 Migration:
Ruby2.7 was recently released on 25th December, 2019. Santa s gift. Believe it or not.
We, the Debian Ruby team, have been trying hard to make it migrate to testing. And it finally happened.
The default version in testing is ruby2.7. Here s the news! \o/
Here s what I worked on this month for this transition.
Upstream:
Opened several issues and proposed patches (in the form of PRs):
Issue #35 against encryptor for Ruby2.7 test failures.
Issue #28 against image_science for removing relative paths.
Issue #106 against ffi-yajl for Ruby2.7 test failures.
Debian LTS
Debian Long Term Support (LTS) is a project to extend the lifetime of all Debian stable releases
to (at least) 5 years. Debian LTS is not handled by the Debian security team, but by a separate group
of volunteers and companies interested in making it a success.
This was my seventh month as a Debian LTS paid contributor. I was assigned 24.00 hours and worked on
the following things:
Other(s)
Sometimes it gets hard to categorize work/things into a particular category.
That s why I am writing all of those things inside this category.
This includes two sub-categories and they are as follows.
Personal:
This month I could get the following things done:
Most importantly, I finally migrated to a new website. Huge UI imporvement! \o/
From Jekyll to Hugo, it was not easy. But it was worth it! Many thanks to Luiz for writing hugo-coder, Clement, and Samyak!
If you find any flaws, issues and pull requests are welcomed at utkarsh2102/utkarsh2102.com
Wrote battery-alert, a mini-project of my own to show battery alerts at <10% and >90%.
Written in shell, it brings me all the satisfaction as it has saved my life on many occasions.
And guess what? It has more users than just myself!
Reviews and patches are welcomed \o/
Mentored in HackOn Hackathon. Thanks to Manvi for reaching out!
It was fun to see people developing some really nice projects.
Thanks to Ray and John, I became a GitLab Hero!
(I am yet to figure out my role and responibility though)
Atteneded Intro Sec Con and had the most fun!
Heard Ian s keynote and attended other talks and learned how to use WireShark!
Open Source:
Again, this contains all the things that I couldn t categorize earlier.
Opened several issues and pull requests:
Issue #297 against hugo-coder, asking to enable RSS feed for blogs.
PR #316 for hugo-coder for fixing the above issue myself.
Issue #173 against arbre for requesting a release.
Issue #104 against combustion, asking to relax dependency on rubocop. Fixed in this commit.
Issue #16 against ffi-compiler for requesting to fix homepage and license.
Issue #57 against gographviz for requesting a release.
Issue #14 against crb-blast, suggesting compatability with bio 2.0.x.
Issue #58 against uniform_notifier for asking to drop the use of ruby-growl.
PR #2072 for polybar, adding installation instructions on Debian systems.
Like each month, here comes a report about the work of paid contributors to Debian LTS.
Individual reports
In February, 226 work hours have been dispatched among 14 paid contributors. Their reports are available:
Abhijith PA gave back 12 out of his assigned 14h, thus he is carrying over 2h for March.
Ben Hutchings did 19.25h (out of 20h assigned), thus carrying over 0.75h to March.
Evolution of the situation
February began as rather calm month and the fact that more contributors have given back
unused hours is an indicator of this calmness and also an indicator that contributing
to LTS has become more of a routine now, which is good.
In the second half of February Holger Levsen (from LTS)
and Salvatore Bonaccorso (from the Debian Security Team)
met at SnowCamp in Italy and discussed
tensions and possible improvements from and for Debian LTS.
The security tracker currently lists 25 packages with a known CVE and the dla-needed.txt file has 21 packages needing an update.
Thanks to our sponsors
New sponsors are in bold.
Recently there was another bind9 security update released by the Debian Security Team. I thought that was odd, so I've scanned my mailbox:
11 January 2017
DSA-3758 - bind9
26 February 2017
DSA-3795-1 - bind9
14 May 2017
DSA-3854-1 - bind9
8 July 2017
DSA-3904-1 - bind9
So in the year to date there have been 7 months, in 3 of them nothing happened, but in 4 of them we had bind9 updates. If these trends continue we'll have another 2.5 updates before the end of the year.
I don't run a nameserver. The only reason I have bind-packages on my system is for the dig utility.
Rewriting a compatible version of dig in Perl should be trivial, thanks to the Net::DNS::Resolver module:
These are about the only commands I ever run:
dig -t a steve.fi +short
dig -t aaaa steve.fi +short
dig -t a steve.fi @8.8.8.8
Debian 9 Stretch , the latest stable version of the venerable Linux distribution, will be released in a few days. I pushed a last-minute change to get the latest security and feature update of WebKitGTK+ (packaged as webkit2gtk 2.16.3) in before release.
Carlos Garcia Campos discusses what s new in 2.16, but there are many, many more improvements since the 2.6 version in Debian 8.
Like many things in Debian, this was a team effort from many people. Thank you to the WebKitGTK+ developers, WebKitGTK+ maintainers in Debian, Debian Release Managers, Debian Stable Release Managers, Debian Security Team, Ubuntu Security Team, and testers who all had some part in making this happen.
As with Debian 8, there is no guaranteed security support for webkit2gtk for Debian 9. This time though, there is a chance of periodic security updates without needing to get the updates through backports.
If you would like to help test the next proposed update, please contact me so that I can help coordinate this.
My monthly report covers a large part of what I have been doing in the free software world. I write it for my donors (thanks to them!) but also for the wider Debian community because it can give ideas to newcomers and it s one of the best ways to find volunteers to work with me on projects that matter to me.
Debian LTS
I was allocated 10 hours to work on security updates for Debian 7 Wheezy and had 1.5 hours remaining from March. During this time I did the following:
I released DLA-905-1 on ghostscript fixing 3 CVE. I also triaged two other ghostscript CVE that were not relevant to the version in wheezy.
I started to look into CVE-2016-10209 for libarchive but was not able to reproduce the segfault and marked it as not worth an update (same decision as security team).
After many tries to get more details from upstream of libxml-twig-perl on CVE-2016-9180, I decided that the low severity of the issue was not worth spending more time on it (same decision as RedHat and Debian security team).
I released DLA-921-1 on slurm-llnl fixing 1 high-severity CVE.
I investigated CVE-2016-8686 on potrace and marked it as not requiring an update because the impact is very low. I documented the fact that it s fixed in unstable and asked the upstream author for the specific patch (no answer yet though).
Kali and pkg-security
I updated the britney instance that we are using in Kali and spotted two small documentation mistakes that I fixed.
We had a long-standing bug in Kali where extensions would stay visible on the lock screen. It was hard to reproduce and this month we finally managed to nail down the conditions required to reproduce it. It turns out that EasyScreenCast was the culprit. We paid Emilio Pozuelo Monfort to work on a patch and he fixed the problem in EasyScreenCast and also in gnome-shell, as a buggy extension should not have resulted in this behavior.
I responded to multiple queries of new contributors in the pkg-security team. The team is rather active and it would be great if we could have a few more Debian developers to help review and sponsor the work our enthusiastic new members.
Thanks
See you next month for a new summary of my activities. Hopefully, I will be more active again between kids vacations, French elections and Zelda Breadth of the Wild, I got very much distracted from Debian last month.
There is much to like about Docker. Much has been written about it, and about how secure the containerization is.
This post isn t about that. This is about keeping what s inside each container secure. I believe we have a fundamental problem here.
Earlier this month, a study on security vulnerabilities on Docker Hub came out, and the picture isn t pretty. One key finding:
Over 80% of the :latest versions of official images contained at least on high severity vulnerability!
And it s not the only one raising questions.
Let s dive in and see how we got here.
It s hard to be secure, but Debian makes it easier
Let s say you want to run a PHP application like WordPress under Apache. Here are the things you need to keep secure:
WordPress itself
All plugins, themes, customizations
All PHP libraries it uses (MySQL, image-processing, etc.)
MySQL
Apache
All libraries MySQL or Apache use: OpenSSL, libc, PHP itself, etc.
The kernel
All containerization tools
On Debian (and most of its best-known derivatives), we are extremely lucky to have a wonderful security support system. If you run a Debian system, the combination of unattended-updates, needrestart, debsecan, and debian-security-support will help one keep a Debian system secure and verify it is. When the latest OpenSSL bug comes out, generally speaking by the time I wake up, unattended-updates has already patched it, needrestart has already restarted any server that uses it, and I m protected. Debian s security team generally backports fixes rather than just say here s the new version , making it very safe to automatically apply patches. As long as I use what s in Debian stable, all layers mentioned above will be protected using this scheme.
This picture is much nicer than what we see in Docker.
Problems
We have a lot of problems in the Docker ecosystem:
No built-in way to know when a base needs to be updated, or to automatically update it
Diverse and complicated vendor security picture
No way to detect when intermediate libraries need to be updated
Complicated final application security picture
Let s look at them individually.
Problem #1: No built-in way to know when a base needs to be updated, or to automatically update it
First of all, there is nothing in Docker like unattended-updates. Although a few people have suggested ways to run unattended-updates inside containers, there are many reasons that approach doesn t work well. The standard advice is to update/rebuild containers.
So how do you know when to do that? It is not all that obvious. Theoretically, official OS base images will be updated when needed, and then other Docker hub images will detect the base update and be rebuilt. So, if a bug in a base image is found, and if the vendors work properly, and if you are somehow watching, then you could be protected. There is work in this area; tools such as watchtower help here.
But this can lead to a false sense of security, because:
Problem #2: Diverse and complicated vendor security picture
Different images can use different operating system bases. Consider just these official images, and the bases they use: (tracking latest tag on each)
nginx: debian:stretch-slim (stretch is pre-release at this date!)
mysql: debian:jessie
mongo: debian:wheezy-slim (previous release)
apache httpd: debian:jessie-backports
postgres: debian:jessie
node: buildpack-deps:jessie, eventually depends on debian:jessie
wordpress: php:5.6-apache, eventually depends on debian:jessie
And how about a few unofficial images?
oracle/openjdk: oraclelinux:latest
robotamer/citadel: debian:testing (dangerous, because testing is an alias for different distros at different times)
docker.elastic.co/kibana: ubuntu of some sort
The good news is that Debian jessie seems to be pretty popular here. The bad news is that you see everything from Oracle Linux, to Ubuntu, to Debian testing, to Debian oldstable in just this list. Go a little further, and you ll see Alpine Linux, CentOS, and many more represented.
Here s the question: what do you know about the security practices of each of these organizations? How well updated are their base images? Even if it s Debian, how well updated is, for instance, the oldstable or the testing image?
The attack surface here is a lot larger than if you were just using a single OS. But wait, it gets worse:
Problem #3: No way to detect when intermediate libraries need to be updated
Let s say your Docker image is using a base that is updated immediately when a security problem is found. Let s further assume that your software package (WordPress, MySQL, whatever) is also being updated.
What about the intermediate dependencies? Let s look at the build process for nginx. The Dockerfile for it begins with Debian:stretch-slim. But then it does a natural thing: it runs an apt-get install, pulling in packages from both Debian and an nginx repo.
I ran the docker build across this. Of course, the apt-get command brings in not just the specified packages, but also their dependencies. Here are the ones nginx brought in:
fontconfig-config fonts-dejavu-core gettext-base libbsd0 libexpat1 libfontconfig1 libfreetype6 libgd3 libgeoip1 libicu57 libjbig0 libjpeg62-turbo libpng16-16 libssl1.1 libtiff5 libwebp6 libx11-6 libx11-data libxau6 libxcb1 libxdmcp6 libxml2 libxpm4 libxslt1.1 nginx nginx-module-geoip nginx-module-image-filter nginx-module-njs nginx-module-xslt ucf
Now, what is going to trigger a rebuild if there s a security fix to libssl1.1 or libicu57? (Both of these have a history of security holes.) The answer, for the vast majority of Docker images, seems to be: nothing automatic.
Problem #4: Complicated final application security picture
And that brings us to the last problem: Let s say you want to run an application in Docker. exim, PostgreSQL, Drupal, or maybe something more obscure. Who is watching for security holes in it? If you re using Debian packages, the Debian security team is. If you re using a Docker image, well, maybe it s the random person that contributed it, maybe it s the vendor, maybe it s Docker, maybe it s nobody. You have to take this burden on yourself, to validate the security support picture for each image you use.
Conclusion
All this adds up to a lot of work, which is not taken care of for you by default in Docker. It is no surprise that many Docker images are insecure, given this picture. The unfortunate reality is that many Docker containers are running with known vulnerabilities that have known fixes, but just aren t, and that s sad.
I wonder if there are any practices people are using that can mitigate this better than what the current best-practice recommendations seem to be?
On CVE-2016-4484, a (security)? bug in the cryptsetup initramfs integration
On November 4, I was made aware of a security vulnerability in the integration
of cryptsetup into initramfs. The vulnerability was discovered by security
researchers Hector Marco and Ismael Ripoll of CyberSecurity UPV Research
Group and got
CVE-2016-4484
assigned.
In this post I'll try to reflect a bit on
What CVE-2016-4484 is all about
Basically, the vulnerability is about two separate but related issues:
1. Initramfs rescue shell considered harmful
The main topic that Hector Marco and Ismael Ripoll address in their
publication
is that Debian exits into a rescue shell in case of failure during initramfs,
and that this can be triggered by entering a wrong password ~93 times in a
row.
Indeed the Debian initramfs implementation as provided by initramfs-tools
exits into a rescue shell (usually a busybox shell) after a defined amount of
failed attempts to make the root filesystem available. The loop in question
is in local_device_setup() at the local initramfs script
In general, this behaviour is considered as a feature: if the root device
hasn't shown up after 30 rounds, the rescue shell is spawned to provide the
local user/admin a way to debug and fix things herself.
Hector Marco and Ismael Ripoll argue
that in special environments, e.g. on public computers with password protected
BIOS/UEFI and bootloader, this opens an attack vector and needs to be regarded
as a security vulnerability:
It is common to assume that once the attacker has physical access to the
computer, the game is over. The attackers can do whatever they want. And
although this was true 30 years ago, today it is not.
There are many "levels" of physical access. [...]
In order to protect the computer in these scenarios: the BIOS/UEFI has one
or two passwords to protect the booting or the configuration menu; the GRUB
also has the possibility to use multiple passwords to protect unauthorized
operations.
And in the case of an encrypted system, the initrd shall block the maximum
number of password trials and prevent the access to the computer in that
case.
While Hector and Ismael have a valid point in that the rescue shell might
open an additional attack vector in special setups, this is not true for
the vast majority of Debian systems out there: in most cases a local attacker
can alter the boot order, replace or add boot devices, modify boot options in
the (GNU GRUB) bootloader menu or modify/replace arbitrary hardware parts.
The required scenario to make the initramfs rescue shell an additional attack
vector is indeed very special: locked down hardware, password protected
BIOS and bootloader but still local keyboard (or serial console) access are
required at least.
Hector and Ismael argue
that the default should be changed for enhanced security:
[...] But then Linux is used in more hostile environments, this helpful
(but naive) recovery services shall not be the default option.
For the reasons explained about, I tend to disagree to Hectors and Ismaels
opinion here. And after discussing this topic with several people I find my
opinion reconfirmed: the Debian Security Team disputes the security
impact of the
issue and othersagree.
But leaving the disputable opinion on a sane default aside, I don't think that
the cryptsetup package is the right place to change the default, if at all.
If you want added security by a locked down initramfs (i.e. no rescue shell
spawned), then at least the bootloader (GNU GRUB) needs to be locked down by
default as well.
To make it clear: if one wants to lock down the boot process, bootloader and
initramfs should be locked down together. And the right place to do this would
be the configurable behaviour of
grub-mkconfig.
Here, one can set a password for GRUB and the boot parameter 'panic=1' which
disables the spawning of a rescue shell in
initramfs.
But as mentioned, I don't agree that this would be sane defaults. The vast
majority of Debian systems out there don't have any security added by locked
down bootloader and initramfs and the benefit of a rescue shell for debugging
purposes clearly outrivals the minor security impact in my opinion.
For the few setups which require the added security of a locked down bootloader
and initramfs, we already have the relevant options documented in the Securing
Debian Manual:
After discussing the topic with initramfs-tools maintainers today, Guilhem and
me (the cryptsetup maintainers) finally decided to not change any defaults and
just add a 'sleep 60' after the maximum allowed attempts were reached.
2. tries=n option ignored, local brute-force slightly cheaper
Apart from the issue of a rescue shell being spawned, Hector and Ismael also
discovered a programming bug in the cryptsetup initramfs integration. This bug
in the cryptroot initramfs local-top
script
allowed endless retries of passphrase input, ignoring the tries=n option of
crypttab (and the default of 3). As a result, theoretically unlimited
attempts to unlock encrypted disks were possible when processed during
initramfs stage. The attack vector here was that local brute-force attacks are
a bit cheaper. Instead of having to reboot after max tries were reached, one
could go on trying passwords.
Even though efficient brute-force attacks are mitigated by the
PBKDF2 implementation in cryptsetup,
this clearly is a real bug.
The reason for the bug was twofold:
First, the condition in setup_mapping() responsible for making the
function fail when the maximum amount of allowed attempts is reached,
was never met:
setup_mapping()[...]# Try to get a satisfactory password $crypttries times
count=0 while[$crypttries-le 0][$count-lt $crypttries];doexport CRYPTTAB_TRIED="$count"
count=$(($count+1))[...]doneif[$crypttries-gt 0] && [$count-gt $crypttries];then
message "cryptsetup: maximum number of tries exceeded for$crypttarget"return1fi[...]
As one can see, the while loop stops when $count -lt $crypttries.
Thus the second condition $count -gt $crypttries is never met. This
can easily be fixed by decreasing $count by one in case of a successful
unlock attempt along with changing the second condition to $count -ge
$crypttries:
setup_mapping()[...]while[$crypttries-le 0][$count-lt $crypttries];do[...]# decrease $count by 1, apparently last try was successful.
count=$(($count-1))[...]doneif[$crypttries-gt 0] && [$count-ge $crypttries];then[...]fi[...]
Christian Lamparter already spotted this bug
back in October 2011 and provided a (incomplete) patch,
but back then I even managed to merge the patch in an improper way,
making it even more useless: The patch by Christian forgot to decrease
$count by one in case of a successful unlock attempt, resulting in
warnings about maximum tries exceeded even for successful attemps in
some circumstances. But instead of adding the decrease myself and
keeping the (almost correct) condition $count -eq $crypttries for
detection of exceeded maximum tries, I changed back the condition to
the wrong original $count -gt $crypttries that again was never met.
Apparently I didn't test the fix properly back then. I definitely should
do better in future!
Second, back in December 2013,
I added a cryptroot initramfs local-block script
as suggested by Goswin von Brederlow in order to fix bug #678692.
The purpose of the cryptroot initramfs local-block script is to invoke
the cryptroot initramfs local-top script again and again in a loop. This
is required to support complex block device stacks.
In fact, the numberless options of stacked block devices are one of the
biggest and most inglorious reasons that the cryptsetup initramfs
integration scripts became so complex over the years. After all we need
to support setups like rootfs on top of LVM with two separate encrypted
PVs or rootfs on top of LVM on top of dm-crypt on top of MD raid.
The problem with the local-block script is that exiting the
setup_mapping() function merely triggers a new invocation of the very
same function.
The guys who discovered the bug suggested a simple and good solution to
this bug: When maximum attempts are detected (by second condition from
above), the script sleeps for 60 seconds. This mitigates the brute-force
attack options for local attackers - even rebooting after max attempts
should be faster.
About disclosure, wording and clickbaiting
I'm happy that Hector and Ismael brought up the topic and made their argument
about the security impacts of an initramfs rescue shell, even though I have
to admit that I was rather astonished about the fact that they got a CVE
assigned.
Nevertheless I'm very happy that they informed the Security Teams of Debian and
Ubuntu prior to publishing their findings, which put me in the loop in turn.
Also Hector and Ismael were open and responsive when it came to discussing
their proposed fixes.
But unfortunately the way they advertised their finding was not very helpful.
They announced a speech about this topic at the DeepSec 2016 in Vienna with
the headline Abusing LUKS to Hack the System.
Honestly, this headline is missleading - if not wrong - in several ways:
First, the whole issue is not about LUKS, neither is it about cryptsetup
itself. It's about Debians integration of cryptsetup into the initramfs,
which is a compeletely different story.
Second, the term hack the system suggests that an exploit to break into
the system is revealed. This is not true. The device encryption is not
endangered at all.
Third - as shown above - very special prerequisites need to be met in order
to make the mere existance of a LUKS encrypted device the relevant fact
to be able to spawn a rescue shell during initramfs.
Unfortunately, the way this issue was published lead to even worse articles
in the tech news press. Topics like Major security hole found in Cryptsetup
script for LUKS disk encryption
or Linux Flaw allows Root Shell During Boot-Up for LUKS Disk-Encrypted
Systems suggest that a major security vulnerabilty
was revealed and that it compromised the protection that cryptsetup respective
LUKS offer.
If these articles/news did anything at all, then it was causing damage to the
cryptsetup project,
which is not affected by the whole issue at all.
After the cat was out of the bag, Marco and Ismael aggreed that the way the
news picked up the issue was suboptimal, but I cannot fight the feeling that
the over-exaggeration was partly intended and that clickbaiting is taking
place here. That's a bit sad.
Debian Long Term Support (LTS) is a project created to extend the life of all Debian stable releases to (at least) 5 years.
Thanks to the LTS sponsors, Debian's buildd maintainers and the Debian FTP Team are excited to announce that two new architectures, armel and armhf, are going to be supported in Debian 7 Wheezy LTS. These architectures along with i386 and amd64 will receive two additional years of extended security support.
Security updates for Debian LTS are not handled by the native Debian Security Team, but instead by a separate group of volunteers and companies interested in making it a success.
Wheezy's LTS period started a few weeks ago and more than thirty updates have been announced so far. If you use Debian 7 Wheezy, you do not need to change anything in your system to start receiving those updates.
More information about how to use Debian Long Term Support and other important changes regarding Wheezy LTS is available at https://wiki.debian.org/LTS/Using
Debian Long Term Support (LTS) is a project created to extend the life of all Debian stable releases to (at least) 5 years.
Thanks to the LTS sponsors, Debian's buildd maintainers and the Debian FTP Team are excited to announce that two new architectures, armel and armhf, are going to be supported in Debian 7 Wheezy LTS. These architectures along with i386 and amd64 will receive two additional years of extended security support.
Security updates for Debian LTS are not handled by the native Debian Security Team, but instead by a separate group of volunteers and companies interested in making it a success.
Wheezy's LTS period started a few weeks ago and more than thirty updates have been announced so far. If you use Debian 7 Wheezy, you do not need to change anything in your system to start receiving those updates.
More information about how to use Debian Long Term Support and other important changes regarding Wheezy LTS is available at https://wiki.debian.org/LTS/Using
Last month was relatively quiet for me in terms of uploads, as the
"squeeze" LTS period was over and "wheezy" is still in the hands of
the regular Debian security team. I carried over 7.25 hours from
Feburary and was assigned another 11 hours of work
by Freexian's
Debian LTS initiative, and worked a total of 12.75 hours.
As Debian 7 "wheezy" uses Linux 3.2.y, I took on maintenance of that
stable branch at kernel.org
from May 2012 until wheezy's EOL. (This currently makes it both the
oldest of the kernel.org
supported releases and the one with the latest projected EOL!)
I will now be maintaining it as part of my Debian LTS work, and then
taking on Linux 3.16.y in my own time starting next month. Each
update takes me around 10 hours to prepare, so Linux
3.2.79 accounted for most of my work this month.
Aside from that, I backported an additional security fix for
the kernel (that was not yet suitable for a kernel.org update)
to the wheezy-security branch, rebased the wheezy branch on
3.2.79, and pulled upstream updates to the PREEMPT_RT patchset.
While the details about how to join the set of paid contributors have always been public (here) we did not advertise this fact very much outside of the people already interested in LTS (and thus subscribed to debian-lts@lists.debian.org). But right now we would like to have a few more paid contributors on board and I m thus posting this call for volunteers.
Who can apply?
You need to meet those requirements:
you are Debian Developer or a Debian Maintainer;
you have some prior experience with providing security updates in Debian (at least on your own packages);
you have good programming skills and know multiple languages (to be able to backport security fixes);
you can emit invoices to Freexian;
you accept the rules defined for this project:
you must respect the privacy of any customer data;
you must prepare a public monthly report of the work done on paid time;
you must respect the Debian code of conduct and respond to queries about your work from fellow community members;
you must do your best to meet the high-quality standards set by the Debian security team.
Even though Freexian is located in France and requires you to provide invoice in EUR, there are no conditions on your nationality or country of residence. For contributors outside of the Euro zone, Freexian is using Transferwise to pay them with minimal currency conversion costs (Paypal is also possible if nothing else works).
The rate offered to paid contributors is the same for all (75 EUR/hour), it s based on a correct rate for independent contractors in western Europe. If the rate is very high for your own country, then be happy to be able to invoice Freexian at this rate and use this opportunity to work less (for money) and contribute more to Debian on your (now copious) free time.
How does the work look like?
If you apply, you will have to send us an SSH key so that you can have access to the internal git repository used for work. It contains a ledger file to track the hours funded by sponsors and how they have been dispatched to the various contributors. You can always know how many hours are assigned to you, how many can be invoiced, and so on. You will have to update it once a month to record the work you did (and indicate us where the report has been published).
The repository also contains a README with many explanations about the workflow (how hours are dispatched, the delay you have to publish your report, etc) and a small helper script (./find-work) to match up the pending updates (registered in dla-needed.txt) with the popularity of the package among the sponsors.
Now the work itself is relatively well documented in the LTS wiki. You will have to provide updates for packages that need an update.
You have some freedom in selecting the packages but at some point you will have to work on packages that you don t know that are written in a language that you have almost not used. So you must be able to go out of your comfort zone and still do a good work. You must also be able to multi-task because in some cases you will get stuck on a particular update and you will have to seek help from the upstream developer (or from the Debian package maintainer). Don t expect to be able to do all your work hours in a single run thus don t wait until the last days of the month. Start early and dispatch your work hours over the month.
From time to time, you will also have to handle the LTS frontdesk for one week. During this week, you need to spend a bit of time every day to triage the new CVE, to respond to questions on the mailing list, and to sponsor updates prepared by volunteers who do not have upload rights.
Questions?
Ask your questions in the comments and I will update this section with your questions and our answers.
What if I have no prior experience with security updates?
Start getting some experience. The LTS and security teams are open for anyone to join. Read their documentation and provide some updates that other contributors can sponsor.
Before accepting you as paid contributor, we generally ask you to prepare one or two DLA on your free time just to make sure that you know the workflow and that you are up to the task.
What if I have only X hours available for paid LTS work?
In the git repository there s a file where you document how many work hours you can handle. You might get less than this amount, but we generally never assign less than 8 hours (to make sure that you can handle one complicated update from start to end, or your possible week of LTS frontdesk).
You can adjust it each month or even opt-out if you are not available for whatever reason. But once you have been assigned work hours, it s important to actually do the work that you requested!
How do I apply?
Get in touch with me (as documented).
My monthly report covers a large part of what I have been doing in the free software world. I write it for my donators (thanks to them!) but also for the wider Debian community because it can give ideas to newcomers and it s one of the best ways to find volunteers to work with me on projects that matter to me.
Debian LTS
This month I have been paid to work 26.25 hours on Debian LTS. In that time I did the following:
CVE triage: I pushed 52 commits to the security tracker. I finished a new helper script (bin/lts-cve-triage.py) that builds on the JSON output that Holger implemented recently. It helps to triage more quickly some issues based on the triaging work already done by the Debian Security team.
I filed #783005 to clarify the situation of libhtp and suricata in unstable (discovered this problem while triaging issues affecting those packages).
I reviewed and sponsored DLA-197-1 for Nguyen Cong fixing 5 CVE on libvncserver.
I released DLA-199-1 fixing one CVE on libx11. I also used codesearch.debian.net to identify all packages that had to be rebuilt with the fixed macro and uploaded them all (there was 11 of them).
I sponsored DLA-207-1 for James McCoy fixing 7 CVE on subversion.
I released DLA-214-1 fixing 1 CVE on libxml-libxml-perl.
I released DLA-215-1 fixing 1 CVE on libjson-ruby. This backport was non-trivial but luckily included some non-regression tests.
I filed #783800 about the security-tracker not handling correctly squeeze-lts/non-free.
Now, still related to Debian LTS, but on unpaid hours I did quite a few other things:
I wrote a talk on Debian LTS that I gave during the Mini-DebConf in Lyon. I took quite some time to collect some statistics about the last 10 months of work within the team.
I ensured that the Jessie press release will include a sentence saying that it would be supported for 5 years too.
Other Debian work
Feature request in update-alternatives. After a discussion with Josselin Mouette during the Mini-DebConf in Lyon, I filed #782493 to request the possibility to override at a system-wide level the default priority of alternatives recorded in update-alternatives. This would make it easier for derivatives to make different choices than Debian.
Sponsored a dnsjava NMU. This NMU introcuded a new upstream version which is needed by jitsi. And I also notified the MIA team that the dnsjava maintainers have disappeared.
python-crcmod bug fix and uploads to *-backports. A member of the Google Cloud team wanted this package (with its C extension) to be available to Wheezy users so I NMUed the package in unstable (to fix #782379) and prepared backports for wheezy-backports and jessie-backports (the latter only once the release team rejected a fix in jessie proper, see #782766).
Old and new PTS updates for Jessies s release. I took care to update tracker.debian.org and packages.qa.debian.org to take into account Jessie s release (which, most notably, introduced the oldoldstable suite as the new name for Squeeze until its end of life).
Received thanks with pleasure. This is not something that I did but I enjoyed reading so many spontaneous thanks in response to Guillem s terse and thankless notification of me stepping down from dpkg maintenance. I love the Debian community. Thank you.
Thanks
See you next month for a new summary of my activities.
Previously I posted a short article about the WordPress package for Debian and how that SID was getting the updated WordPress 4.0.1 which had some security fixes.
The question a lot of people were asking was: What about stable (or Wheezy). After way too much time due to other pressing issues, I have just uploaded the patched WordPress debian package for stable. The fixed version has the catchy number of 3.6.1~deb7u5. This package has all of the relevant patches that went in from WordPress 3.7.4 to 3.7.5 and there are even CVE IDs for this package (and 4.0.1 which all this stems from).
Stolen from the 3.6.1 changelog, these are the fixes:
CVE-2014-9031 XSS in wptexturize() via comments or posts
CVE-2014-9033 CSRF in the password reset process
CVE-2014-9034 Denial of service for giant passwords
CVE-2014-9035 XSS in Press This
CVE-2014-9036 XSS in HTML filtering of CSS in posts
CVE-2014-9037 Hash comparison vulnerability in old passwords
CVE-2014-9038 SSRF: Safe HTTP requests did not sufficiently block the loopback IP address space
CVE-2014-9039 Email address change didn t invalidate previously sent password reset
I d like to thank the Debian security team especially Salvatore for their assistance and checking the package looked ok.
Backporting and Git
Part of the delay in getting the wordpress stable package out is that backporting is fiddly. I m currently using pdebuild with a custom pbuilderrc file that points to wheezy. Getting things to that point took a lot of trial and error; with one of the errors being that the pbuilder puts the files in a result directory, not the parent.
This also means that the wheezy backports are out of the git repository. I see that there is a git-pbuild but to me it looks like yet another workflow which will slow me right down. Anyone got some good and simple suggestions on having a wheezy track (branch?) and requiring backporting that doesn t get complicated or broken quick? sbuild died in a wave of permission denieds within the chroot.
Very old Debian releases like woody (3.0), sarge (3.1), etch (4.0) and lenny (5.0) are not supported anymore by the Debian Security Team and do not get security updates. Since some of our customers still have servers running these version, I have built bash packages with the fix for CVE-2014-6271 (the "shellshock" bug) and Florian Weimer's patch which restricts the parsing of shell functions to specially named variables:
http://ftp.linux.it/pub/People/md/bash/
This work has been sponsored by my employer Seeweb, an hosting, cloud infrastructure and colocation provider.
In May, I got selected as a Google Summer of Code student for Debian again! \o/
ELTS - Wheezy
Like 
Recently there was another bind9 security update released by the Debian Security Team. I thought that was odd, so I've scanned my mailbox:
My monthly report covers a large part of what I have been doing in the free software world. I write it for 
Last month was relatively quiet for me in terms of uploads, as the
"squeeze" LTS period was over and "wheezy" is still in the hands of
the regular Debian security team. I carried over 7.25 hours from
Feburary and was assigned another 11 hours of work
by 
My monthly report covers a large part of what I have been doing in the free software world. I write it for 
Very old Debian releases like woody (3.0), sarge (3.1), etch (4.0) and lenny (5.0) are not supported anymore by the Debian Security Team and do not get