The following contributors got their Debian Developer accounts in the last two months:
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
This month I was allocated 12h but I only spent 10.5h. During this time, I continued my work on exiv2. I finished reproducing all the issues and then went on doing code reviews to confirm that vulnerabilities were not present when the issue was not reproducible. I found two CVE where the vulnerability was present in the wheezy version and I posted patches in the upstream bug tracker: #57 and #55.
Then another batch of 10 CVE appeared and I started the process over I m currently trying to reproduce the issues.
While doing all this work on exiv2, I also uncovered a failure to build on the package in experimental (reported here).
Misc Debian/Kali work
Debian Live. I merged 3 live-build patches prepared by Matthijs Kooijman and added an armel fix to cope with the the rename of the orion5x image into the marvell one. I also uploaded a new live-config to fix a bug with the keyboard configuration. Finally, I also released a new live-installer udeb to cope with a recent live-build change that broke the locale selection during the installation process.
Debian Installer. I prepared a few patches on pkgsel to merge a few features that had been added to Ubuntu, most notably the possibility to enable unattended-upgrades by default.
More bug reports. I investigated much further my problem with non-booting qemu images when they are built by vmdebootstrap in a chroot managed by schroot (cf #872999) and while we have much more data, it s not yet clear why it doesn t work. But we have a working work-around
While investigating issues seen in Kali, I opened a bunch of reports on the Debian side:
No comment Liked this article? Click here. My blog is Flattr-enabled.
SOURCE_DATE_EPOCHSOURCE_DATE_EPOCH) (Closes: #792202)SOURCE_DATE_EPOCH also to luatexSOURCE_DATE_EPOCH. Original patch by akiraSOURCE_DATE_EPOCHSOURCE_DATE_EPOCHSOURCE_DATE_EPOCHfile(GLOB ...)sudo add-apt-repository ppa:dank/dpkg && sudo apt-get update && sudo apt-get install dpkg should be enough to get reproducible builds on Ubuntu 16.04.
This week's edition was written by Ximin Luo and Holger Levsen and reviewed by a bunch of Reproducible builds folks on IRC.
What happened in the reproducible
builds effort this week:
Toolchain fixes
groovydoc.
Ben Hutchings submitted a patch to add support for SOURCE_DATE_EPOCH in linux-kbuild as an alternate way to specify the build timestamp.
Reiner Herrman has sent a patch adding support for SOURCE_DATE_EPOCH in docbook-utils.
Packages fixed
The following packages became reproducible due to changes in their
build dependencies:
commons-csv.
fest-reflect,
sunxi-tools,
xfce4-terminal,
The following packages became reproducible after getting fixed:
SOURCE_DATE_EPOCH in debian/rules.amd64 builders now use two different kernel versions: 3.16 from stable and 4.1 from backports on the other. (h01ger)
We now graph the number of packages which needs to be fixed. (h01ger)
Munin now creates graphs on how many builds were performed by build nodes (example). (h01ger)
A migration plan has been agreed with DSA on how to turn Jenkins into an official Debian service. A backport of jenkins-job-builder for Jessie is currently missing. (h01ger)
Package reviews
119 reviews have
been removed, 103 added and 45 updated this week.
16 fail to build from source issues were reported by Chris Lamb and Mattia Rizzolo.
New issue this week: timestamps_in_manpages_generated_by_docbook_utils.
Misc.
Allan McRae has submitted a patch to make ArchLinux pacman record a .BUILDINFO file.
What happened about the reproducible
builds effort for this week:
Toolchain fixes
contrib:
Thanks to the reproducible-build team for running a buildd from hell. gregor herrmannMattia Rizzolo modified the script added last week to reschedule a package from Alioth, a reason can now be optionally specified. Holger Levsen splitted the package sets page so each set now has its own page. He also added new sets for Java packages, Haskell packages, Ruby packages, debian-installer packages, Go packages, and OCaml packages. Reiner Herrmann added locales-all to the set of packages installed in the build environment as its needed to properly identify variations due to the current locale. Holger Levsen improved the scheduling so new uploads get tested sooner. He also changed the
.json output that is used by
tracker.debian.org to lists FTBFS issues again
but only for issues unrelated to the toolchain or our test setup. Amongst many
other small fixes and additions, the graph colors should now be
more friendly to red-colorblind people.
The fix for pbuilder given in
#677666 by Tim Landscheidt is now used. This
fixed several FTBFS for OCaml packages.
Work on rebuilding with different CPU has continued, a kvm-on-kvm build host
has been set been set up for this purpose.
debbindiff development
Version 19 of
debbindiff included a fix for a
regression when handling info files.
Version 20 fixes a bug when diffing
files with many differences toward a last line with no newlines. It also now
uses the proper encoding when writing the text output to a
pipe, and detects info files better.
Documentation update
Thanks to Santiago Vila, the unneeded -depth option used with find when
fixing mtimes has been removed from the examples.
Package reviews
113 obsolete
reviews have
been removed this week while 77 has been added.
What happened about the reproducible
builds effort for this week:
Media coverage
Debian's effort on reproducible builds has been covered in the June 2015 issue of
Linux Magazin in
Germany.
Toolchain fixes
debian/changelog entry when generating documentation.debian/changelog entry to Sphinx.sed instead of grep+mv to keep correct file permissions.PERL_HASH_SEED=0 during configure to make the generated .c and .h files stable.--disable-build-date to ./configure.debian/changelog entry as build date.debian/chanelog entry as build date.reproducible.debian.net how it goes for pathological cases.
It's now possible to specify both --html and --text output. When neither of
them is specified, the default will be to print a text report on the standard
output (thanks to Paul Wise for the suggestion).
Documentation update
Nicolas Boulenguez investigated Ada
libraries.
Package reviews
451 obsolete
reviews have
been removed and 156 added this week.
New identified issues: running kernel version getting captured, random filenames in GHC debug symbols, and timestamps in headers generated by qdbusxml2cpp.
Misc.
Holger Levsen went to re:publica and talked about
reproducible builds to developers and users there.
Holger also had a chance to meet FreeBSD developers and discuss the status of
FreeBSD. Investigations have
started on how it could be made part of our current test
system.
Laurent Guerby gave Lunar access to systems in the GCC Compile
Farm. Hopefully access to these powerful
machines will help to fix packages for GCC, Iceweasel, and similar packages
requiring long build times.
On Sunday I gave a talk about Debian LTS during the Mini-DebConf in Lyon. Obviously I presented the project and the way it s organized, but I also took the opportunity to compute some statistics.
You can watch the presentation (thanks to the video team!) or have a look at the slides to learn more.
Here are some extracts of the statistics I collected:
The number of the uploads per affiliation (known affiliations are recorded in the LTS/Team wiki page) is displayed on the graph below. None corresponds to packages maintainers taking care of their own packages, Debian Security corresponds to members of the security team who also contributed to LTS, Debian LTS corresponds to individual members of the LTS team without any explicit affiliation. Freexian represents in fact 29 financial sponsors (see detail here).
Top 12 contributors (in number of uploads):
One comment Liked this article? Click here. My blog is Flattr-enabled.
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 12 hours on Debian LTS. I did the following tasks:
sbuild:
chroots:
wheezy:
architectures: [amd64, i386]
extra_dists:
- wheezy-backports
- wheezy-security
extra_aliases:
- wheezy-backports
- stable-security
- wheezy-security
jessie:
[...]
And then a simple salt-call state.highstate (I m running in standalone mode) will ensure that I have all the chroots properly setup.
Misc packaging
I packaged new upstream releases of Django in experimental and opened a pre-approval request to get the latest 1.7.x in jessie (#775892). It seems to be a difficult sell for the release team, which is a pity because we have active Debian developers, active upstream developers, and everybody is well aware of the no-new features rule to avoid regressions. Where is the risk?
I also filed an unblock request for Dolibarr (on the request of the security team which wants to see the CVE fix reach Jessie). I did small contributions to two bugs that were of special interest to some of my donators (#751339 and #774811), they were not under my responsibility but I tried to get them moving by pinging the relevant people.
I prepared a security upload for Django in Wheezy (python-django_1.4.5-1+deb7u9) and sent it to the security team. While doing this I discovered a small problem in their backported patch that I reported upstream in Django s ticket #24239.
Debian France
With the new year, it s again time to organize a general assembly with the election of a third of its board. So we solicited candidacies among the members and I m pleased to see that we got 6 candidacies for the 3 seats. It s a good sign that we still have enough persons caring about the association. One of them is even speaking of Debconf 17 in France great plans!
On my side, I announced that I would not candidate to be president for the next year. I will stay on the board though to ensure we have a smooth transition.
Thanks
See you next month for a new summary of my activities.
One comment Liked this article? Click here. My blog is Flattr-enabled.
| Symmetric | Public |
| 80 | 1024 |
| 112 | 2048 |
| 128 | 3072 |
| 256 | 15360 |
| MD5 | 2^20 |
| SHA-1 | 2^60 |
| SHA-2 | No known attack (so SHA-256 would have 1.2 * 2^128) |
| MD5 | 2^123 |
| SHA-1 | No known attack (2^160) |
| SHA-256 | No known attack (2^256) |
Today, I officially got approved by the Debian Account Managers as a Debian Developer (still waiting on keyring-maint and DSA). Over the years, I have seen many people complain about the New Member Process. The most common complaint was with regards to the (usually) long amount of time the process can take to complete. I am writing this blog post to provide one more perspective on this process. Hopefully, it will prove useful to people considering starting the New Member Process.
The most difficult part about the New Member Process for me had to do with getting my GPG key signed by Debian Developers. I have not been able to attend any large conferences, which are great places to get your key signed. I also have not been able to meet up with the few Debian Developers living in/around Chicago. As a result, I was forced to patiently wait to start the NM process. This waiting period lasted a couple of years. It wasn't until this October, at the [Association for Computing Machinery at Urbana-Champaign's Reflections Projections Conference], that this changed. Stefano Zacchiroli was present to give a talk about Debian. Asheesh Laroia was also present to lead an OpenHatch Workshop about contributing to open source projects. Both of these Developers were more than willing to sign my key when I asked. If you look at my key, you will see that these signatures were made on October 7 and October 9, 2012.
With the signatures out of the way, the next step in the process was to actually apply. Since I did not already have an account in the system, I had to send an email to the Front Desk and have them enter my information into the system. Details on this step, along with a sample email are available here.
Once I was in the system, the next step was to get some Debian Developers to serve as my advocates. Advocates should be Debian Developers you have worked closely with, and usually include your sponsor(s). If these people believe you are ready to become a Debian Developer, they write a message describing the work you have been doing with them and why they feel you are ready. Paul Tagliamonte had helped review and sponsor a number of my uploads. I had been working with him for a number of years, and he really helped encourage and help me to reach this milestone. He served as my first advocate. Gregor Herrmann is responsible for getting me started in contributing to Debian. When I first tried to get involved, I had a hard time finding sponsors for my uploads and bugs to work on. Eventually, I discovered the Debian Perl Group. This team collectively maintains most of the Perl modules that are included in the Debian repositories. Gregor and the other Debian Developers on the team were really good about reviewing and sponsoring uploads in a very timely manner. This allowed me to learn quickly and make a number of contributions to Debian. He served as my second advocate.
With my advocations taken care of, the next step in the process was for the Front Desk to assign me an Application Manager and for the Application Manager to accept the appointment. Thijs Kinkhorst was appointed as my Application Manager. He also agreed to take on this task. For those of you who might not know, the Application Manager is in charge of asking the applicant questions, collecting information, and ultimately making a recommendation to the Debian Account Managers about whether or not they should accept the applicant as a Developer. They can go about this in a variety of ways, but most choose to utilize a set of template questions that are adjusted slightly on a per-applicant basis.
Remember that period of waiting to get my GPG key signed? I had used that time to go through and prepare answers to most of the template questions. This served two purposes. First, it allowed me to prove to myself that I had the knowledge to become a Debian Developer. Second, it helped to greatly speed up the New Member process once I actually applied. There were some questions that were added/removed/modified, but by answering the template questions befrehoand, I had become quite familiar with documents such as the Debian Policy and the Debian Developer's Rerference. These documents are the basis for almost all questions that are asked. After several rounds of questions, testing my knowledge of Debian's philosophy and procedures as well as my technical knowledge and skills, some of my uploads were reviewed. This is a pretty standard step. Be prepared to explain any changes you made (or chose not to make) in your uploads. If you have any outstanding bugs or issues with your packages, you might also be asked to resolve them. Eventually, once your Application Manager has collected enough information to ensure you are capable of becoming a Debian Developer, they will send their recommendation and a brief biography about you to the debian-newmaint mailing list and forward all information and emails from you to the Debian Account Managers (after the Front Desk checks and confirms that all of the important information is present).
The Debian Account Managers have the actual authority to approve new Debian Developers. They will review all information sent to them and reach their own decision. If they approve your application, they will submit requests for your GPG key to be added to the Debian Keyring and for an account to be created for you in the Debian systems. At this point, the New Member process is complete. For me, it took exactly 1 month from the time I officially applied to become a Debian Developer until the time of my application being approved by the Debian Account Managers. Hopefully, it will not be long until my GPG key is added to the keyring and my account is created. I feel the entire process went by very quickly and was pain-free. Hopefully, this blog post will help to encourage more people to apply to become Debian Developers.
Since a couple of years we ve been handing off security issues of minor orI m happy to confirm, now that it s been announced, that I am that person: point release security co-ordinator. Affected packages If your package fulfils these criteria:
theoretical impact but for which a fix would be desirable at some point, like
certain classes of denial-of-service attacks, off to stable point updates.
We re looking for a person that wants to coordinate this: monitor the Security
Tracker for issues classified as such by the Security Team, converse with
maintainers to get such updates done and coordinate with the stable release
managers on this.
If you want to provide a wiki but want to leave the authentication to one or more external identity providers, like an identity federation, Dokuwiki and simpleSAMLphp are a good combination. However, the existing documentation is lagging behind on developments in these software packages (i.e. doesn't work anymore), so here's what worked for me.
Ingredients:
cd /usr/share/dokuwiki/inc/auth && ln -s /opt/simplesamldokuwiki/simplesamlphp.auth.class
$conf['authtype'] = 'simplesamlphp'; $conf['simplesamlphp_path'] = '/usr/share/simplesamlphp'; $conf['simplesamlphp_attr_user'] = 'urn:mace:dir:attribute-def:eduPersonPrincipalName'; $conf['simplesamlphp_attr_name'] = 'urn:mace:dir:attribute-def:cn'; $conf['simplesamlphp_attr_mail'] = 'urn:mace:dir:attribute-def:mail'; $conf['simplesamlphp_attr_grps'] = 'groups';
'session.phpsession.cookiename' => 'DokuWiki'
As I'm currently attending the EUgridPMA meeting in Zagreb I thought I'd share a bit of this project I've been working on for the past year: the TCS eScience project.
In the scientific world lots of calculations are performed on distributed computing platforms known as grid. Because users of other institutions will be using your hardware, authentication is needed and this problem has been solved with x.509 personal certificates. The problem however, is that these certificates of course have to be issued by some CA. Currently in Europe alone there are over 40 active CA's, even multiple per country, dedicated to this job. They are accredited through the EUgridPMA which meets regularly. For scientists, it's often cumbersome to obtain a certificate: find your local CA, present an ID (probably in person), and sometime later receive your certificate. The process can take days or even weeks. Scientists are not interested in CA's but just want to practice science.
Our solution is a central web portal where users can request a certificate and have it delivered in minutes. This leverages the fact that identities of scientists normally have already been vetted at their home institution: users log in to the portal via federated login. Their home institution passes a special attribute that declares "Yes, we have really seen photo ID of this person and the name is correct". This attribute must of course not be passed for guests or test users or role accounts. However, it may still be easy to mass-provision it. In the Netherlands for example, the employer is required by law to verify the identity of each employee, so all employees can be automatically assigned the attribute.
After logging in and uploading (or generating) a csr, the request is passed in the back end to the Comodo API. This also means that we do not need to perform the complex operations of running an online CA (with hardware crypto devices, crl's, etc.). The use of Comodo is part of the same deal as the TERENA Certificate Service for host SSL certificates. The Comodo API responds within two minutes with the certificate which the user can download.
Currently 10 European countries are involved with the project (nl no se fi dk at cz it fr be), and more have shown interest. The certificates we issue have been accredited by the EUgridPMA so can be used on the grid. A separate but similar service is being set up for 'regular' personal certificates for the academic community, e.g. for s/mime usage. More details are in the presentation and paper by portal software developers Henrik and Thomas at the most recent TNC.
Nobody cares about me, I thought. Whatever I say is just like throwing a bottle to the infinite ocean.
No comments, no hopes of getting any, for several days. Weeks maybe? Not even the spammers cared about me.
Until I read this mail, by Thijs Kinkhorst commenting to my yesterday post:
( )And, yes, Drupal module captcha introduced in its 2.1 release (January 2) feature #571344: Mix multiple fonts. Only... no fonts were selected. Grah.
(BTW, I was unable to comment on your blog - couldn't even read one letter of the CAPTCHA...)
In a setup where we use Apache FastCGI with PHP through mod_fcgid and suEXEC, we experienced the problem that long running scripts always resulted in a 500 Internal Server Error after exactly 40 seconds. This is due to the IPCCommTimeout setting, but changing that setting didn't seem to yield any effect.
I stumbled on a blog entry saying that they only work within the VirtualHost block. I tried this for my test-vhost but it also didn't work. It took me a while to find the complete solution (workaround): you need to specify IPCommTimeout in every VirtualHost block, because a later VirtualHost will globally reset your setting in a previous one.
So until this bug is fixed the neat workaround is to place the mod_fcgid settings in a separate configuration file and Include that file inside each VirtualHost.
Today everyone in the Netherlands received a letter about the new national electronic health record (EPD) and the possibility to object against registration. EPD aims to provide access to one's patient data to every care provider through a central information broker. I have submitted the form to disallow my data to be accessed through this system.
First of all, there's no clear benefit for me, and I think that goes for the large majority of people. The possible situation where someone has a critical condition and isn't treated by his regular doctor and is unable to inform the stand-in of this and the stand-in has the time to delve through the entire EPD and actually finds and correctly interprets the necessary information seems extremely small for anyone, let alone the big majority that doesn't suffer such critical conditions in the first place. Hence, making it the default for everyone seems very inappropriate. See also this interesting article, written in Dutch by my uncle.
Interestingly the same minister was recently opposed to a default-allow for organ donorship, which may address a problem that is much more real.
The other concern is security. I am not worried by the technical security of the system, it seems to be of acceptable standard (see this report by my friend Niels). I am more concerned about access restrictions: these are implemented post hoc, that is, anyone can access my file and I can check who accessed my it and whether they had the right to. However, this procedure involves sending in paper forms which I think in practice will not bring about much review.
Combined this project reminds me of voting computers - introducing new concerns while solving no actual problems.
Yesterday I attended a lecture by professor D.J. Bernstein, best known for his products like qmail, owner of one of the coolest domain names in the world and for his often controversial but always interesting visions.
His talk focused on why the majority of internet traffic still is not encrypted. We protect our email passwords but the 95% of other things we do is completely unprotected from a sniffer. He then narrowed it down to DNS. The problems with DNSSEC are evident and it's still a question of whether it will ever be implemented (after 15 years the design is still in flux, let alone that it's properly implemented or actually used).
On a more constructive side he presented his own solution: DNSCurve: using elliptic curve cryptography to not only sign but also encrypt DNS traffic, and do so on the fly rather than the cumbersome precomputation approach of DNSSEC. Bernstein shows that the extra cost of on the fly cryptography is, even for root servers, very minor compared to the costs of the entire system, but it does significantly reduce the administrative burden compared to DNSSEC. As usual he has made an interesting case, a worthwhile read.
Next.