by @tf
Another post about the Valve/Collabora free games thing. This time, the bad bit – people trying to scam free games from us.
Before I start, I want to make one thing clear – there are people who have requested keys who don’t meet the criteria, but are honest and legitimate in their requests. This blogspam is not about them at all. If you’re in that category, you’re not being complained about.
So. Some numbers. At time of writing, I’ve assigned keys to 279 Debian Developers or Debian Maintainers – almost 25% of the total eligible pool of about 1200.
I’ve denied 22 requests. Of these 10 were polite requests from people who didn’t meet the conditions stated (e.g. Ubuntu developers rather than Debian). These folks weren’t at all a problem for us, and I explained politely that they didn’t meet the terms we had agreed at the time with Valve. No problem at all with those folks.
Next, we have the chancers, 7 of them, who pretended to be eligible when they clearly weren’t. For example, two people sent me signed requests pointing to their entry on the Debian New Maintainers page when challenged over the key not being in the keyring. The NM page showed that they had registered as non-uploading Debian Contributors a couple of hours previously. A few just claimed “I am a DD, here is my signature” when they weren’t DDs at all. Those requests were also binned.
And then we move onto the final category. These people tried identity theft, but did a terrible job of it. There were 5 people in this category:
From: Xxxxxxxx Xxxxxx <xxxxxxxx.xxxxxx@ieee.org> Subject: free subscription to Debian Developer 8217 A205 5E57 043B 2883 054E 7F55 BB12 A40F 862E
This is not a signature, it’s a fingerprint. Amusingly, it’s not the fingerprint for the person who sent my mail, but that of Neil McGovern – a co-worker at Collabora. Neil assured me he knew how to sign a mail properly, so I shitcanned that entry.
From: "Xxxxx, Xxxxxxxxx" <x.xxxxx@bbw-bremen.de> Subject: Incoming! Hey dude, I want to have the redemption code you are offering for the Valve Games mQGiBEVhrscRBAD4M5+qxhZUD67PIz0JeoJ0vB0hsLE6QPV144PLjLZOzHbl4H3N ...snip... Lz8An1TEmmq7fltTpQ+Y1oWhnE8WhVeQAKCzh3MBoNd4AIGHcVDzv0N0k+bKZQ=3D=3D =3Du/4R
Wat? Learn to GPG!
From: Xxxxxx-Xxxx Le Xxxxxxx Xxxx <xx.xxxxxxxxx@gmail.com> Subject: pass steam Hey me voila Merci beaucoup valve 2069 1DFC C2C9 8C47 9529 84EE 0001 8C22 381A 7594
Like the first one, a fingerprint. This one is for Sébastien Villemot. Don’t scammers know how to GPG sign?
From: "Xxxxxxxxx Xxxxxxx" <xxxxxxxx@web.de> Subject: thanks /DD/Steam gifts us finally something back 0x6864730DF095E5E4
Yet again, a fingerprint. This one is for Marco Nenciarini. I found this request particularly offensive due to the subject line – the haughty tone from an identity thief struck me as astonishingly impertinent. Still, when will scammers learn to GPG?
From: Sven Hoexter <svenhoexter@gmail.com> Subject: Valve produced games I'm would like to get the valve produced games My keyring: 0xA6DC24D9DA2493D1 Sven Hoexter <hoexter> sig:6
Easily the best scam effort, since this is the only one which both a) registered an email address under the name of a DD, and b) used a fingerprint which actually corresponds to that human. Sadly for the scammer, I’m a suspicious kind of person, so my instinct was to verify the claim via IRC.
31-01-2014 16:52:48 > directhex: Hoaxter, have you started using gmail without updating your GPG key? (note: significantly more likely is someone trying to steal your identity a little to steal valve keys from collabora) 31-01-2014 16:54:51 < Hoaxter!~sh@duckpond6.stormbind.net: directhex: I do not use any Google services and did not change my key
So… yeah. Nice try, scammer.
I’m not listing, in all of this, the mails which Neil received from people who didn’t actually read his mail to d-d-a.
I’m also not listing a story which I’ve only heard second ha… actually no, this one is too good not to share. Someone went onto db.debian.org, did a search for every DD in France, and emailed every Jabber JID (since they look like email addresses) asking them to forward unwanted keys.
All in all, the number of evildoers is quite low, relative to the number of legitimate claims – 12 baddies to 279 legitimate keys issued. But still, this is why the whole key issuing thing has been taking me so long – and why I have the convoluted signature-based validation system in place.
Enjoy your keys, all 279 of you (or more by the time some of you read this). The offer has no explicit expiry on it – Valve will keep issuing keys as long as there is reason to, and Collabora will continue to administer their allocation as long as they remain our clients. It’s a joint gift to the community – thousands of dollars’ worth of games from Valve, and a significant amount of my time to administer them from Collabora.
There is one thing in the current init system debate that irritates me. It is about the portability of init systems. The new init systems are evaluated by how portable they are. This is one of the arguments that is most often brought against systemd, which is understandable given the polarizing attitude of one of systemd's authors. In this context, the currently used sysvinit is considered portable. But in my book, it is not portable at all.
But why can we use sysvinit to boot Debian/{kFreeBSD,Hurd}?
Debian/kFreeBSD uses linprocfs for /proc to provide a familiar Linux-like environment for the userspace tools available in Debian (say, pgrep). linprocfs was originally written by the FreeBSD folks to support running Linux binaries using the Linux Binary Compatibility layer.
Debian/Hurd uses procfs to provide /poc. This procfs translator is written mainly to provide a Linux-compatible /proc filesystem for the same reason linprocfs is used by Debian/kFreeBSD.
So sysvinit works on those system not because it is portable, but because the environment has been made Linux-like enough for sysvinit. We (most likely anyone not using Linux) often do this, because it is the easiest way to run popular software developed (mainly) for Linux. This is often the path of the least resistance, as opposed to getting the upstream project to support the native way of doing things on platform X.
During gsoc last year I had to patch our procfs to finally be able to safely shut down Debian/Hurd systems using sysvinit. The problem was, that sysvinit at certain runlevel transitions (like shutting down, or I guess, switching to single user mode), sysvinit assumes that it is okay to stop and kill (almost) all processes on the system (that's what killall5 does). This might be okay on monolithic systems, but on (multiserver) microkernel systems like the Hurd, where your root filesystem and your network driver and stack are running as userspace processes, it is clearly not. I wonder how Linux systems using a FUSE-based root filesystem get away with this.
This highlights that not only sysvinit depends on a Linux-specific kernel interface (/proc), but it also hard-codes assumptions about the system architecture.
Amusingly, systemd get's this right (ok, I'm not sure if it does, but it could get this right...). systemd organizes processes in cgroups, one for each service it starts and one for each login session or something like that. It can (could?) kill only those processes in it was responsible for, leaving all essential translators (system servers) alone. In fact, even my tiny cgroupfs prototype can keep track of translators that are started by the root filesystem translator.
Hallelujah, thanks! It'll reduce archive size and cut traffic, download time, too :-)dpkg (1.17.0) unstable; urgency=low
.
[ Guillem Jover ]
(snip)
* Switch dpkg-deb default compressor from gzip to xz. Build dpkg.deb using
gzip to make debootstrap life easier on non-Debian based systems.