My (Finnish) wife and I have now relocated from Edinburgh, Scotland, to Helsinki, Finland.
I've been here for 13 days at the moment, and am still settling in. But so far things are going well. So, yeah, that happened.
Reproducible Builds is another example of the kind of audacious project that I celebrated in my last blog post.
It's a fun way to learn a little bit about different parts of the archive, and to help on an incrementally-improving process. My workflow below is meant to encourage folks to join in. The documentation on the wiki is certainly more authoritative (and will be more up-to-date in the future).
My usual workflow is this:
debcheckout clocIf that failed for some reason, I would use:
apt-get source cloc
Source: packagename Version: packageversion Tags: patch Severity: wishlist User: email@example.com Usertags: closest-usertag X-Debbugs-CC: firstname.lastname@example.orgWhen choosing the closest usertag, i look at the "Usertagged bugs" block on the R-B continuous integration dashboard or the wiki documentation to see what makes sense.
The information at the R-B wiki page is quite detailed if you want more info.
Finally, many many thanks to all of the people involved in the project, and particularly to h01ger and Lunar^, who have both contributed a ton of work, and have also made it easy to plug in and help as a less-involved contributor. The nice automatically-updated statistics provided by the team's continuous integration work makes it a fun game to help out.
I've just realized that the last version of GNOME (the one shipped with Jessie) allows to start the session under Wayland instead of the classic X. I think it's a only a preview to start collecting some feedback and bug reports from the field, and that it shouldn't be considered a mature, workable option.
On my admittedly underpowered system (an Atom-based netbook) the usability approaches zero, with xwayland taking up 99% of the CPU and several seconds of lag between action (mouse clicks, key presses) and feedback. In addition, synaptics options like tap-to-click are not recognized -- or not obeyed, I'm not sure.
I'd be curious about other users' experience, if any have been brave enough to try it out!
I always find that kind of task a little off-putting and difficult to tackle, but I was happy to see someone driving the project, since it does need to get done. Debian is potentially also in a position to help the upstream python community, because we have a pretty good view of what things are being used, at least within our own ecosystem.
I'm happy to say that i also missed one of the other great benefits of paultag's audacious proposal, which is how it has engaged people who already knew about debian but who aren't yet involved. Evidence of this engagement is already visible on the py3porters-devel mailing list. But if that wasn't enough, I ran into a friend recently who told me, "Hey, I found a way to contribute to debian finally!" and pointed me to the py3-porters project. People want to contribute to the project, and are looking for ways in.
So cheers to the people who propose audacious projects and make them inviting to everyone, newcomers included. And cheers to the people who step up to potentially daunting work, stake out a task, roll up their sleeves, and pitch in. Even if the py3porters project doesn't move all of debian's python infrastructure to pyt3 as fast as paultag wants it to, i think it's already a win for the project as a whole. I am looking forward to seeing what comes out of it (and it's reminding me i need to port some of my own python work, too!)
The next time you stumble over something big that needs doing in debian, even something that might seem impossible, please make it inviting, and dive in. The rest of the project will grow and improve from the attempt.
The basic gist is that i like to use git-buildpackage (gbp) with the upstream source included in the repo, both as tarballs (with pristine-tar branches) and including upstream's native VCS history (Joey's arguments about syncing with upstream git are worth reading if you're not already convinced this is a good idea).
I also started using gbp-pq recently -- the patch-queue feature is really useful for at least three things:
My preferred packaging practices document is a work in progress. I'd love to improve it. If you have suggestions, please let me know.
Also, if you've written up your own preferred packaging practices, send me a link! I'm hoping to share and learn tips and tricks around this kind of workflow at debconf 15 this year.
The Problem: Vendor software we were looking to evaluate did not compile correctly using the lastest version of wheezy(7.8 at the time of writing).
The Solution: We had a to build a new server using snapshot.debian.org. This allowed us to build the server at a point in time after 7.1 was released but prior to the 7.2 release. Below are the settings we use.
cat /etc/apt/sources.list deb http://snapshot.debian.org/archive/debian/20130802T034916Z/ wheezy main deb http://snapshot.debian.org/archive/debian-security/20130802T202345Z/ wheezy/updates main
For more details head on over to the site.
I'm using grub version 2.02~beta2-2.
I want to make a USB stick that's capable of booting Intel architecture EFI machines, both 64-bit (x86_64) and 32-bit (ia32). I'm starting from a USB stick which is attached to a running debian system as /dev/sdX. I have nothing that i care about on that USB stick, and all data on it will be destroyed by this process.
I'm also going to try to make it bootable for traditional Intel BIOS machines, since that seems handy.
I'm documenting what I did here, in case it's useful to other people.
Set up the USB stick's partition table:
parted /dev/sdX -- mktable gpt parted /dev/sdX -- mkpart biosgrub fat32 1MiB 4MiB parted /dev/sdX -- mkpart efi fat32 4MiB -1 parted /dev/sdX -- set 1 bios_grub on parted /dev/sdX -- set 2 esp onAfter this, my 1GiB USB stick looks like:
0 root@foo:~# parted /dev/sdX -- print Model: USB FLASH DRIVE (scsi) Disk /dev/sdX: 1032MB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 4194kB 3146kB fat32 biosgrub bios_grub 2 4194kB 1031MB 1027MB efi boot, esp 0 root@foo:~#make a filesystem and mount it temporarily at /mnt:
mkfs -t vfat -n GRUB /dev/sdX2 mount /dev/sdX2 /mntensure we have the binaries needed, and add three grub targets for the different platforms:
apt install grub-efi-ia32-bin grub-efi-amd64-bin grub-pc-bin grub2-common grub-install --removable --no-nvram --no-uefi-secure-boot \ --efi-directory=/mnt --boot-directory=/mnt \ --target=i386-efi grub-install --removable --no-nvram --no-uefi-secure-boot \ --efi-directory=/mnt --boot-directory=/mnt \ --target=x86_64-efi grub-install --removable --boot-directory=/mnt \ --target=i386-pc /dev/sdXAt this point, you should add anything else you want to /mnt here! For example:
umount /mnt sync
Recently a friend asked me about SPF and DKIM. I was vaguely aware of them and their generally perceived uselessness. I've never bothered with them but thought I'd look into them for him. SPF was trivial to set up using my Bytemark DNS, and easy to testing using of many on-line email tools.
The challenge is DKIM, I found several sites that explained what to do - they were all variation around a theme and seemed easy enough. Generate a key pair (check), put the public half into your DNS (check), tweak Exim4 (ARGH!!!).
As far as I tell I followed what the web site said and reloaded the Exim config and it looks like it's all loaded into place, the key is readable by Exim, the path is correct but no matter what I do Exim wont add the DKIM signature to my outgoing emails...!
I wanted to say a word of thanks for the awesome work done by debian localization teams. I speak English, and my other language skills are weak. I'm lucky: most software I use is written by default in a language that I can already understand.
The debian localization teams do great work in making sure that packages in debian gets translated into many other languages, so that many more people around the world can take advantage of free software.
I was reminded of this work recently (again) with the great patches submitted to GnuPG and related packages. The changes were made by many different people, and coordinated with the debian GnuPG packaging team by David Prévot.
This work doesn't just help debian and its users. These localizations make their way back upstream to the original projects, which in turn are available to many other people.
If you use debian, and you speak a language other than english, and you want to give back to the community, please consider joining one of the localization teams. They are a great way to help out our project's top priorities: our users and free software.
Thank you to all the localizers!
(this post was inspired by gregoa's debian advent calendar. i won't be posting public words of thanks as frequently or as diligently as he does, any more than i'll be fixing the number of RC bugs that he fixes. This are just two of the ways that gregoa consistently leads the community by example. He's an inspiration, even if living up to his example is a daunting challenge.)
GnuPG 2.1 offers many new and interesting features, but one of the most important changes is the introduction of elliptic curve crypto (ECC). While GnuPG 2.1 discourages the creation of ECC keys by default, it's important that we have the ability to verify ECC signatures and to encrypt to ECC keys if other people are using this tech. It seems likely, for example, that Google's End-To-End Chrome OpenPGP extension will use ECC. GnuPG users who don't have this capability available won't be able to communicate with End-To-End users.
There are many other architectural changes, including a move to more daemonized interactions with the outside world, including using dirmngr to talk to the keyservers, and relying more heavily on gpg-agent for secret key access. The gpg-agent change is a welcome one -- the agent now holds the secret key material entirely and never releases it -- as of 2.1 gpg2 never has any asymmetric secret key material in its process space at all.
One other nice change for those of us with large keyrings is the new keybox format for public key material. This provides much faster indexed access to the public keyring.
I've been using GnuPG 2.1.0 betas regularly for the last month, and i think that for the most part, they're ready for regular use.
Timing for debian
The timing between the debian freeze and the GnuPG upstream is unfortunate, but i don't think i'm prepared to push for this as a jessie transition yet, without more backup. I'm talking to other members of the GnuPG packaging team to see if they think this is worth even bringing to the attention of the release team, but i'm not pursuing it at the moment.
If you really want to see this in debian jessie, please install the experimental package and let me know how it works for you.
Long term migration concerns
GnuPG upstream is now maintaining three branches concurrently: modern (2.1.x), stable (2.0.x), and classic (1.4.x). I think this is stretches the GnuPG upstream development team too thin, and we should do what we can to help them transition to supporting fewer releases concurrently.
In the long-term, I'd ultimately like to see gnupg 2.1.x to replace all use of gpg 1.4.x and gpg 2.0.x in debian, but unlikely to to happen right now.
In particular, the following two bugs make it impossible to use my current, common monkeysphere workflow:
Call for testing
Anyway, if you use debian testing or unstable, and you are interested in these features, i invite you to install `gnupg2` and its friends from experimental. If you want to be sensibly conservative, i recommend backing up `~/.gnupg` before trying to use it:
cp -aT .gnupg .gnupg.bak sudo apt install -t experimental gnupg2 gnupg-agent dirmngr gpgsm gpgv2 scdaemonIf you find issues, please file them via the debian BTS as usual. I (or other members of the pkg-gnupg team) will help you triage them to upstream as needed.
Originally the code behind this site as 100% open, but during the course of some of the earlier migrations it was closed by accident - jumping from CVS to hg, and now to git things moved around a lot.
Nothing was ever intended to be secret, private, or closed, it was just an aspect I've failed to pay attention to.
Anyway the code behind this site is called YAWNS and once again it is open to the public:
The code behind this site is badly in need of another overhaul.
At the moment it runs on a set of ropy CGI scripts that are neither efficient nor pleasant.
My current plan is to record the basics from scratch, then port over functionality as time goes on. As part of that I think I'll be coming up with some toy-servers:
With that structure in mind the core of the site can just mediate between requests and the actual backend - without worrying about actual implementation-details.
In terms of features the only thing I think I'm going to remove is the comment-feed RSSs.
There is a feed for the comments on every article - and that feed gets spidered like mad, for articles that are many years old.
I'm open to the idea of collaboration if there are users who wish to help - and the code will be on github in due course.
I resigned from the debian project a few years ago, but I'm currently going through the process to un-retire.
(I have more free time now that I'm happily married and my wife works as a Doctor in A&E - having a few late-night shifts in local hospitals.)
So I accidentally released a service which will give you resilient, low-latency, DNS-hosting (which uses Amazons route53 on the backend).
If you'd like to use Git to store your DNS-data, and add/update DNS-entries via a simple "git push" then you should check it out:
A previous entry from 2011 on the subject on using SES and Exim still comes up in web searches. As with the 2011 config, this assumes a standard Debian/Ubuntu exim4 deployment using a split-file config.
SES now allows authenticated relay via port 25, but also submission (port 587). Logically it makes more sense to think of SES as a Submission host since it uses ESMTPSA and makes modifications to the mail in transit, so I explicitly create a submission transport at /etc/exim4/conf.d/transport/40_local_submission
remote_submission: debug_print = "T: remote_submission for $local_part@$domain" driver = smtp port = 587 hosts_require_auth = * hosts_require_tls = *Then I add in a router which activates based on the sender at /etc/exim4/conf.d/router/180_local_aws-ses
aws_ses: debug_print = "R: send_via_ses for mail from $sender_address" driver = manualroute host_find_failed = freeze domains = ! +local_domains senders = AWS_SES_SENDER transport = remote_submission route_list = * AWS_SES_SERVERThe site specific configuration /etc/exim4/conf.d/main/00_local_aws-ses
## sender email addresses to be routed via SES, one-per-line AWS_SES_SENDER = lsearch*@;/etc/exim4/ses_senders ## nearest SES ingress point AWS_SES_SERVER = email-smtp.eu-west-1.amazonaws.comAnd assuming the standard auth handling is in place, add a line to /etc/exim4/passwd.client
*.amazonaws.com:Yourusername:YourpasswordNote, these are SMTP specific credentials and not the AWS credentials previously used. Run update-exim4.conf and then restart exim.
If you're looking for a system administrator, who is very very familiar with Debian GNU/Linux, please do consider getting in touch.
I'm an ex-member of the Debian project, and was a member of the Debian Security Team, which involved handling security updates for the distribution. (This came about as a result of my interest in auditing software, a process which lead to the discovery, and fixing, of numerous flaws in popular open-source applications and servers.)
I'm based in Edinburgh, but I have had many years working remotely, and would be happy to repeat that.
As you can see from my prior submissions I'm very familiar with system administration, including (but not limited to):
In the past I've written and posted articles upon this site about my own software.
Over time I've become a little less keen on doing so, on the basis that people might think it is too Steve-centric. That said I'd always created this site to document things of interest to myself, and the fact that others enjoy them is a good bonus.
In summary I wrote a mail client, it is console-based like mutt, but it has a real scripting language you can use to do fun things (Lua).
You can find details here, should you have any interest:
Relatedly I've been pondering a "Hire Steve" banner on the top of the site. I've resisted the temptation for the moment, but give it a couple more weeks of unemployment and I may well change my mind..
I recently had an incident where Dovecot didn't start properly and then the following day it did. Yesterday I had the same scenario and it was really annoying. The core process starts but none of the actual worker children do.
The problem turns out to be a NFS mount to a box that went away, which meant when Dovecot started went looking for email mbox files on the home directory of the users (not NFS mounted) it got stuck. I eventually spotted this by starting Dovecot under strace and it was instantly obvious what the problem was, and a quick force umount of the now-absent filesystem allowed Dovecot to carry on.
If the plain ASCII text below is mangled beyond verification, you can retrieve a copy of it from my web site that should be able to be verified.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OTR Key Replacement for XMPP email@example.com =========================================== Date: 2014-04-14 My main XMPP account is firstname.lastname@example.org. I prefer OTR  conversations when using XMPP for private discussions. I was using irssi to connect to XMPP servers, and irssi relies on OpenSSL for the TLS connections. I was using it with versions of OpenSSL that were vulnerable to the "Heartbleed" attack . It's possible that my OTR long-term secret key was leaked via this attack. As a result, I'm changing my OTR key for this account. The new, correct OTR fingerprint for the XMPP account at email@example.com is: F8953C5D 48ABABA2 F48EE99C D6550A78 A91EF63D Thanks for taking the time to verify your peers' fingerprints. Secure communication is important not only to protect yourself, but also to protect your friends, their friends and so on. Happy Hacking, --dkg (Daniel Kahn Gillmor) Notes:  OTR: https://otr.cypherpunks.ca/  Heartbleed: http://heartbleed.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJTTBF+XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcYwkQAKLzEnTV1lrK6YrhdvRnuYnh Bh9Ad2ZY44RQmN+STMEnCJ4OWbn5qx/NrziNVUZN6JddrEvYUOxME6K0mGHdY2KR yjLYudsBuSMZQ+5crZkE8rjBL8vDj8Dbn3mHyT8bAbB9cmASESeQMu96vni15ePd 2sB7iBofee9YAoiewI+xRvjo2aRX8nbFSykoIusgnYG2qwo2qPaBVOjmoBPB5YRI PkN0/hAh11Ky0qQ/GUROytp/BMJXZx2rea2xHs0mplZLqJrX400u1Bawllgz3gfV qQKKNc3st6iHf3F6p6Z0db9NRq+AJ24fTJNcQ+t07vMZHCWM+hTelofvDyBhqG/r l8e4gdSh/zWTR/7TR3ZYLCiZzU0uYNd0rE3CcxDbnGTUS1ZxooykWBNIPJMl1DUE zzcrQleLS5tna1b9la3rJWtFIATyO4dvUXXa9wU3c3+Wr60cSXbsK5OCct2KmiWY fJme0bpM5m1j7B8QwLzKqy/+YgOOJ05QDVbBZwJn1B7rvUYmb968yLQUqO5Q87L4 GvPB1yY+2bLLF2oFMJJzFmhKuAflslRXyKcAhTmtKZY+hUpxoWuVa1qLU3bQCUSE MlC4Hv6vaq14BEYLeopoSb7THsIcUdRjho+WEKPkryj6aVZM5WnIGIS/4QtYvWpk 3UsXFdVZGfE9rfCOLf0F =BGa1 -----END PGP SIGNATURE-----
After having several people poke me in different contexts about why inline cleartext PGP signatures are a bad idea, i got sufficiently tired of repeating myself, and finally documented some of the problems explicitly.
The report includes a demonstration of a content-tampering attack that changes the meaning of a signed inline-PGP message without breaking the signature, which i first worked out on the notmuch mailing list, but hadn't gotten around to demonstrating until recently.
The attack is demonstrated against clearsigned messages, but also works against inline encrypted messages (but is harder to demonstrate since a demonstration would require sharing secret key material for the decryption step).
Please don't generate Inline-PGP messages. And if you must parse and accept them, please consider carefully the risks you expose your users to and think about ways to mitigate the problems.
I've just about completed a new toy project:
This is basically a markdown-using pastebin site.
You can paste in your random markdown text, and once you've done so you receive a link you can share with your boss, your friends, or whoever.
Feedback welcome, either here, via mail, or via the github tracker.
I'm pretty pleased with the project, and it is already proving useful.
Contributions and feedback welcome, on my new site:
Much like this one in nature, but much more succinct and focussed.
On Monday (tomorrow) I'll be starting a new job, once again working from home - something I was keen to avoid.
Still it won't be so bad, the only potential concern is that I'll be starting on my home desktop, and at some point during the day I'm expecting a delivery of a new Macbook which I need to switch over to using.
I've never used a Mac, not since system 7, so that'll be "fun".