Search Results: "Debian Security Team"

1 May 2020

Utkarsh Gupta: FOSS Activites in April 2020

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.

Uploads:

Other $things:
  • Attended Ruby team meeting. Logs here.
  • Attended Perl team LHF. Report here.
  • 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.
  • PR #5 against aggregate for simply using require.
  • PR #6 against aggregate for modernizing CI and adding Ruby 2.5 and 2.7 support.
  • Issue #13 against espeak-ruby for Ruby2.7 test failures.
  • Issue #4 against tty-which for test failures in general.
  • Issue #11 against packable for Ruby2.7 test failures. PR #12 has been proposed.
  • Issue #10 against growl for test failures and proposed an initial patch.

Downstream: I fixed and uploaded the following packages in Debian:

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:

CVE Fixes and Announcements:

Other LTS Work:

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.

Until next time.
:wq for today.

25 March 2020

Rapha&#235;l Hertzog: Freexian s report about Debian Long Term Support, February 2020

A Debian LTS logo 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: 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.

No comment Liked this article? Click here. My blog is Flattr-enabled.

10 July 2017

Steve Kemp: bind9 considered harmful

Recently there was another bind9 security update released by the Debian Security Team. I thought that was odd, so I've scanned my mailbox: 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
I should do that then. Yes.

15 June 2017

Jeremy Bicha: #newinstretch : Latest WebKitGTK+

GNOME Web (Epiphany) in Debian 9 "Stretch" 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.

3 May 2017

Rapha&#235;l Hertzog: My Free Software Activities in April 2017

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: 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.

One comment Liked this article? Click here. My blog is Flattr-enabled.

29 April 2017

John Goerzen: Is there any way to truly secure Docker container contents?

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: 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:
  1. No built-in way to know when a base needs to be updated, or to automatically update it
  2. Diverse and complicated vendor security picture
  3. No way to detect when intermediate libraries need to be updated
  4. 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) And how about a few unofficial images? 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?

7 December 2016

Jonas Meurer: On CVE-2016-4484, a (securiy)? bug in the cryptsetup initramfs integration

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 others agree. 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 ]; do export CRYPTTAB_TRIED="$count" count=$(( $count + 1 )) [...] done if [ $crypttries -gt 0 ] && [ $count -gt $crypttries ]; then message "cryptsetup: maximum number of tries exceeded for $crypttarget" return 1 fi [...]
    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 ))
          [...]
      done
      if [ $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.

2 June 2016

Bits from Debian: Debian 7 Wheezy LTS now supporting armel and armhf

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

Bits from Debian: Debian 7 Wheezy LTS now supporting armel and armhf

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

1 April 2016

Ben Hutchings: Debian LTS work, March 2016

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.

14 January 2016

Rapha&#235;l Hertzog: Working as a paid LTS contributor

A Debian LTS logoWhile 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: 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).

One comment Liked this article? Click here. My blog is Flattr-enabled.

5 May 2015

Rapha&#235;l Hertzog: My Free Software Activities in April 2015

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: Now, still related to Debian LTS, but on unpaid hours I did quite a few other things: 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.

No comment Liked this article? Click here. My blog is Flattr-enabled.

3 December 2014

Craig Small: WordPress 4.0.1 fixes for Debian stable

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: 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.

29 September 2014

Marco d'Itri: CVE-2014-6271 fix for Debian woody, sarge, etch and lenny

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.

20 August 2014

Holger Levsen: 20140819-lts-july-2014

Debian LTS - impressions and thoughts from my first month involvement About LTS - we want feedback and more companies supporting it financially Squeeze LTS, and even more Debian LTS, is a pretty young project, started in May 2014, so it's still a bit unclear where exactly we'll be going :) One purpose of this post is to spread some information about the initiative and invite you to tell us what you think about it or what your needs are. LTS stands for "Long Term Support" and the goal of the project is to extend the security support for Squeeze (aka the current oldstable distribution) by two years. If it weren't for Squeeze LTS, the security support for it would have been stopped in May 2014 (=one year after the release of the current stable distribution), which for many is a too short timespan after it's release in February 2011. It's an experiment, we hope that there will be a similar Wheezy LTS initiative in future, but the future is unwritten and things will change based on our experiences and your needs. If you have feedback on the direction LTS should take (or anything else LTS related), please comment on the lts mailing list. For immediate feedback there is also the #debian-lts IRC channel. Another quite pragmatic way to express your needs is to read more about how to financially contribute to LTS and then doing exactly that - and unsurprisingly we are prioritizing the updates based on the needs expressed from our paying customers. My LTS work in July 2014 So, "somehow" I started working for money on Debian LTS in July, which means there were 10h I got paid, and probably another 10h where I did LTS related work unpaid. I used those to release four updates for squeeze-lts (linux-2.6, file, munin and reportbug) fixing 22 CVEs in total. The unpaid work was mostly spent on unsuccessfully working on security updates and on adding support for LTS to the security team tracker, which I improved but couldn't fully address and which I haven't properly shared / committed yet... but at least I have a local instance of the tracker now, which - for LTS - is more useful than the .debian.org one. Hopefully during DebConf14 we'll manage to fix the tracker for good. Without success I've looked at libtasn1-3 (where the first fixes applied easily but then the code had changed too much from what was in squeeze compared to the available patches that I gave up) and libxstream-java (which is at version 1.3, while patches exist for upstream branches 1.4 and 2.x, but those need newer java to build and maybe if I'll spend two more hours I'll can get it build and then I'll have to find a useful test case, which looked quite difficult on a brief look.. so maybe I give up on libxstream-java too.... OTOH, if you use it and can do some testing, please do tell me. Working on all these updates turned out to be more team work than expected and a lot of work involving code (which I did expect), and often code which I'd normally not look at... similarily with tools: one has to deal with tools one doesnt like, eg I had to install cdbs... :-) And as I usually like challenges, this has actually been a lot of fun! Though it's also pretty cool to use common best practices, easy and understandable workflows. I love README.Source (or better yet, when it's not needed). And while git is of course really really great, it's still very desirable if your package builds twice (=many times) in a row, without resetting it via git. Some more observations The first 16 updates (until July 19th) didn't have a DLA ID, until I suggested to introduce them and insisted until we agreed. So now we agreed to put the DLA ID in the subject of the announcement mails and there is also some tool support for generating the templates/mails, but enforcing proper subjects is not done, as silent bounces are useless (and non silent ones can be abused too easily). I'm not really happy about this, but who is happy with the way email works today? And I agree, it's not the end of the world if an LTS announcement is done without a proper ID, but it looks unprofessional and could be avoided, but we have more important work to do. But one day we should automate this better. Another detail I'm not entirely happy is the policy/current decision that "almost everything is fine to upload if deemed sensible by the uploader" (which is everyone in the Debian upload keyring(s)). In discussions before actually having the archive some people suggested the desire to upload new upstream versions too (eg newer kernels, iceweasel or other software to keep running a squeeze desktop in the modern world were discussed). I sincerely hope for most intrusive new upstream versions squeeze-(sloppy-)backports is used instead, and squeeze-lts rather not. Luckily so far all uploads were (IMHO) sensible and so, right now, I will just say that I hope it will stay this way. And it's true, one also has to install these upgrades in the first place. But people do that blindly all the time... So by design/desire currently there is no gatekeeping mechanism whatsover (no NEW, no proposed updates), except that only some selected "few" can upload. What is uploaded (and signed correctly), gets pushed to archive, buildds and the mirrors, and hopefully maybe someone will send an announcement. So far this has worked remarkedly well - and it's also the way the Debian Security team works, as I'm told. Looking at this from a process quality / automatisation perspective, all this manual and errorprone labour seems very strange to me. ;-) And then there is another thing: as already mentioned, the people working paid hours for this, are prioritizing their work based on customer requests. So we did two updates (python-scipy and file), which are not fixed in wheezy yet. I think this is unfortunate and while I could probably prepare the wheezy DSA for file, I don't really want to join the Security Team... or maybe I want/should join the Security Team and be a seldomly active member (eg fixing file in wheezy now....) A note related to this: out of those 37 uploads done until today, 16 were done by those two people being paid, while the other 21 uploads were done by 10 volunteers (or at least not paid by Debian LTS). It will be interesting to see how this statistics evolves over time. Last, but not least, there is also this can of worms (aka: the discussion) about paying people to work on Debian... I do agree it's work we didnt find volunteers for and I also see how the (financial side of the) setup is done outside of Debian (and well too, btw!), but... then we also use Debian ressources like buildds, the archive itself and official mailing lists. Also I'm currently biased in this discussion, as I directly (and happily) profit from it. I'm mentioning this here, because I believe it's important we discuss this and come to both good and practical conclusions. FWIW, we have also discussed this on the list, feel free to search the archives for it. To bring this post to an end: for those attending DebConf14 (directly or thanks to some ninjas), there will be an event about LTS in Portland, though I'm not sure yet what I will have to talk about what hasn't been already covered here :-) But this probably means that will be a good opportunity for you to do lots of talking instead! I'm curious what you will have to say! Thanks for reading this far. I think I can promise that my next LTS report will be shorter :-D

1 April 2014

Thorsten Glaser: Sorry about the MediaWiki-related breakage in wheezy

I would like to publicly apologise for the inconvenience caused by my recent updates to the mediawiki and mediawiki-extensions source packages in Debian wheezy (stable-security). As for reasons I m doing Mediawiki-related work at my dayjob, as part of FusionForge/Evolvis development, and try to upstream as much as I can. Our production environment is a Debian wheezy-based system with a selection of newer packages, including MediaWiki from sid (although I also have a test system running sid, so my uploads to Debian are generally better tested). I haven t had experience with stable-security uploads before, and made small oversights (and did not run the full series of tests on the final , permitted-to-upload, version, only beforehand) which led to the problems. The situation was a bit complicated by the need to update the two packages in lockstep, to fight an RC bug file/symlink conflict, which was hard enough to do in sid already, plus the desire to fix other possibly-RC bugs at the same time. I also got no external review, although I cannot blame anyone since I never asked anyone explicitly, so I accept this as my fault. The issues with the updates are: My unfamiliarity with some of the packaging concepts used here, combined with this being something I do during $dayjob (which can limit the time I can invest, although I m doing much more work on Mediawiki in Debian than I thought I could do on the job), can cause some of those oversights. I guess I also should install a vanilla wheezy environment somewhere for testing I do not normally do stable uploads (jmw did them before), so I was not prepared for that. And, while here: thanks to the Debian Security Team for putting up with me (also in this week s FusionForge issue), and thanks to Mediawiki upstream for agreeing to support releases shipped in Debian stable for longer support, so we can easily do stable-security updates.

20 March 2014

Bits from Debian: Working in a possible LTS for Debian Squeeze

The Debian Security Team announced in the bits from their last meeting that they're considering to ask for the addition of a new suite to provide long term support (LTS) for Squeeze. Quoting their announcement: This means this is still not something settled and if you or your company is insterested in joining this effort, you should contact the security team ASAP. So they can see if there is enough people and resources to launch the LTS.

5 March 2014

H ctor Or n Mart nez: Debian build system

There are many ways to build Debian distributions from source. None of them are trivial enough for beginners and all of them require complex setups. For instance, the Debian official setup uses the following software components: Around the core components, there are other software components needed to run the Debian distribution: Thanks to Debian ftp-master and buildd team, all software is built for several architectures and several ports. Most Debian infrastructure is managed and maintained by Debian System Administration team.

Simplified Debian build infrastructure

Debian Wiki has been growing different random pages trying to ease the setup and configuration problems concerning to Debian build system infrastructure. The above infrastructure barely documents what it is involved to create and generate Debian unstable ( sid ) distribution suite. In order to produce Debian stable distribution suite, there are software transitions to happen and yet another Debian team gets involved in the process, our beloved Debian release team. Once distribution reaches its maturity level and gets released as in its stable version, it gets updates also lead by release team and security related updates, which yet another team is responsible for them, the Debian security team. and there are lots of Debian teams doing many other things you might enjoy, have a byte

4 March 2014

H ctor Or n Mart nez: Debian build system

There are many ways to build Debian distributions from source. None of them are trivial enough for beginners and all of them require complex setups. For instance, the Debian official setup uses the following software components: Around the core components, there are other software components needed to run the Debian distribution: Thanks to Debian ftp-master and buildd team, all software is built for several architectures and several ports. Most Debian infrastructure is managed and maintained by Debian System Administration team.

Simplified Debian build infrastructure

Debian Wiki has been growing different random pages trying to ease the setup and configuration problems concerning to Debian build system infrastructure. The above infrastructure barely documents what it is involved to create and generate Debian unstable ( sid ) distribution suite. In order to produce Debian stable distribution suite, there are software transitions to happen and yet another Debian team gets involved in the process, our beloved Debian release team. Once distribution reaches its maturity level and gets released as in its stable version, it gets updates also lead by release team and security related updates, which yet another team is responsible for them, the Debian security team. and there are lots of Debian teams doing many other things you might enjoy, have a byte

9 June 2012

Stefano Zacchiroli: bits from the DPL for May 2012

Just posted to d-d-a, here are the monthly DPL bits.
Dear project members,
here's the periodic report of what has happened in DPL land, this time during May 2012. It's briefer than usual, as this year I've enjoyed the lovely French habit of frequent holidays during the month of May. Highlight First highlight for this month is an invitation to us all. We're now in June and the Wheezy freeze is literally a few days away. The RC bugs count is moving in the right direction, but it's still stellar if we want to ensure a short freeze. And a short freeze is of paramount importance: it'll reduce the time during which we can't implement great plans for the future, increase the "freshness" of software we'll ship with Wheezy, and reduce the inconveniences for those who run the testing suite due to its nice "rolling" feature. So please set out some regular time to do RC bug squashing, by providing patches and doing NMUs. Releasing Wheezy is not something that could be outsourced to the Release Team, it's a collective responsibility that kicks in as soon as our own packages are RC bug free (which they already are, right? :-)) The second highlight is more on the internal structure camp. As mentioned last month, I've discussed with the tech-ctte insisting a bit to set up periodic IRC meetings, to ensure outstanding issues get periodically reviewed. At the end of May the first IRC meeting has happened, and has been very productive. See the minutes. Another one has been scheduled, trying to setup a monthly cadence, for the end of June. Many thanks to all tech-ctte members who have took part in and helped with the meeting organization. Communication I've given an interview to iTWire, answering a number of questions about several past and future Debian challenges. Discussions The ongoing discussion to harmonize packaging of multimedia software between the official Debian archive and the unofficial debian-multimedia.org archive (dmo) has progressed. I've tried to help the two groups reaching an agreement on which packages belong where, so that both duplicate packaging efforts and user inconveniences are minimized. That seems not to have worked and dmo maintainers have simply announced that they will move away from the current domain name to a new one that does not include "debian" in its name. Sprints There will be a Debian Science sprint in June, co-located with the broader Debian Science event organized by European Synchrotron Radiation Facility (ESRF) in Grenoble. I've confirmed my attendance for the opening talk of the conference day. ESRF organizers have kindly sponsored travel for all Debian attendees, many thanks to them! Another sprint will happen next week-end in Paris, this time by the i18n/l10n team. I've approved the corresponding tentative budget for travel sponrship for ~2'000 EUR. Other expenses Hardware replacement plans go on. We've ordered SSDs (for ~3'000 CAD) for recently bought machines meant to replace bugs-mirror, bugs-master, and udd. On the "small emergencies" front, we also had to replace failing disks on wagner (1/2 of alioth), for as little as 100 GBP. Miscellanea Happy Wheezy freeze,
and RC bugs squashing!
PS the boring day-to-day activity log for May is available at master:/srv/leader/news/bits-from-the-DPL.txt.201205

Next.

Previous.