10 years ago I first blogged about getting glasses [1]. I ve just ordered my 4th pair of glasses. When you buy new glasses the first step is to scan your old glasses to use that as a base point for assessing your eyes, instead of going in cold and trying lots of different lenses they can just try small variations on your current glasses. Any good optometrist will give you a print-out of the specs of your old glasses and your new prescription after you buy glasses, they may be hesitant to do so if you don t buy because some people get a prescription at an optometrist and then buy cheap glasses online. Here are the specs of my new glasses, the ones I m wearing now that are about 4 years old, and the ones before that which are probably about 8 years old:

	New	4 Years Old	Really Old
R-SPH	0.00	0.00	-0.25
R-CYL	-1.50	-1.50	-1.50
R-AXS	180	179	180
L-SPH	0.00	-0.25	-0.25
L-CYL	-1.00	-1.00	-1.00
L-AXS	5	10	179

The Specsavers website has a good description of what this means [2]. In summary SPH is whether you are log-sighted (positive) or short-sighted (negative). CYL is for astigmatism which is where the focal lengths for horizontal and vertical aren t equal. AXS is the angle for astigmatism. There are other fields which you can read about on the Specsavers page, but they aren t relevant for me. The first thing I learned when I looked at these numbers is that until recently I was apparently slightly short-sighted. In a way this isn t a great surprise given that I spend so much time doing computer work and very little time focusing on things further away. What is a surprise is that I don t recall optometrists mentioning it to me. Apparently it s common to become more long-sighted as you get older so being slightly short-sighted when you are young is probably a good thing. Astigmatism is the reason why I wear glasses (the Wikipedia page has a very good explanation of this [3]). For the configuration of my web browser and GUI (which I believe to be default in terms of fonts for Debian/Unstable running KDE and Google-Chrome on a Thinkpad T420 with 1600 900 screen) I can read my blog posts very clearly while wearing glasses. Without glasses I can read it with my left eye but it is fuzzy and with my right eye reading it is like reading the last line of an eye test, something I can do if I concentrate a lot for test purposes but would never do by choice. If I turn my glasses 90 degrees (so that they make my vision worse not better) then my ability to read the text with my left eye is worse than my right eye without glasses, this is as expected as the 1.00 level of astigmatism in my left eye is doubled when I use the lens in my glasses as 90 degrees to it s intended angle. The AXS numbers are for the angle of astigmatism. I don t know why some of them are listed as 180 degrees or why that would be different from 0 degrees (if I turn my glasses so that one lens is rotated 180 degrees it works in exactly the same way). The numbers from 179 degrees to 5 degrees may be just a measurement error.

• [1] https://etbe.coker.com.au/2006/09/20/vision/
• [2] https://www.specsavers.com.au/glasses/your-prescription
• [3] https://en.wikipedia.org/wiki/Astigmatism_(eye)

Previously: v4.6. Onward to security things I found interesting in Linux v4.7: KASLR text base offset for MIPS Matt Redfearn added text base address KASLR to MIPS, similar to what s available on x86 and arm64. As done with x86, MIPS attempts to gather entropy from various build-time, run-time, and CPU locations in an effort to find reasonable sources during early-boot. MIPS doesn t yet have anything as strong as x86 s RDRAND (though most have an instruction counter like x86 s RDTSC), but it does have the benefit of being able to use Device Tree (i.e. the /chosen/kaslr-seed property) like arm64 does. By my understanding, even without Device Tree, MIPS KASLR entropy should be as strong as pre-RDRAND x86 entropy, which is more than sufficient for what is, similar to x86, not a huge KASLR range anyway: default 8 bits (a span of 16MB with 64KB alignment), though CONFIG_RANDOMIZE_BASE_MAX_OFFSET can be tuned to the device s memory, giving a maximum of 11 bits on 32-bit, and 15 bits on EVA or 64-bit. SLAB freelist ASLR Thomas Garnier added CONFIG_SLAB_FREELIST_RANDOM to make slab allocation layouts less deterministic with a per-boot randomized freelist order. This raises the bar for successful kernel slab attacks. Attackers will need to either find additional bugs to help leak slab layout information or will need to perform more complex grooming during an attack. Thomas wrote a post describing the feature in more detail here: Randomizing the Linux kernel heap freelists. (SLAB is done in v4.7, and SLUB in v4.8.) eBPF JIT constant blinding Daniel Borkmann implemented constant blinding in the eBPF JIT subsystem. With strong kernel memory protections (CONFIG_DEBUG_RODATA) in place, and with the segregation of user-space memory execution from kernel (i.e SMEP, PXN, CONFIG_CPU_SW_DOMAIN_PAN), having a place where user-space can inject content into an executable area of kernel memory becomes very high-value to an attacker. The eBPF JIT was exactly such a thing: the use of BPF constants could result in the JIT producing instruction flows that could include attacker-controlled instructions (e.g. by directing execution into the middle of an instruction with a constant that would be interpreted as a native instruction). The eBPF JIT already uses a number of other defensive tricks (e.g. random starting position), but this added randomized blinding to any BPF constants, which makes building a malicious execution path in the eBPF JIT memory much more difficult (and helps block attempts at JIT spraying to bypass other protections). Elena Reshetova updated a 2012 proof-of-concept attack to succeed against modern kernels to help provide a working example of what needed fixing in the JIT. This serves as a thorough regression test for the protection. The cBPF JITs that exist in ARM, MIPS, PowerPC, and Sparc still need to be updated to eBPF, but when they do, they ll gain all these protections immediatley. Bottom line is that if you enable the (disabled-by-default) bpf_jit_enable sysctl, be sure to set the bpf_jit_harden sysctl to 2 (to perform blinding even for root). fix brk ASLR weakness on arm64 compat There have been a few ASLR fixes recently (e.g. ET_DYN, x86 32-bit unlimited stack), and while reviewing some suggested fixes to arm64 brk ASLR code from Jon Medhurst, I noticed that arm64 s brk ASLR entropy was slightly too low (less than 1 bit) for 64-bit and noticeably lower (by 2 bits) for 32-bit compat processes when compared to native 32-bit arm. I simplified the code by using literals for the entropy. Maybe we can add a sysctl some day to control brk ASLR entropy like was done for mmap ASLR entropy. LoadPin LSM LSM stacking is well-defined since v4.2, so I finally upstreamed a small LSM that implements a protection I wrote for Chrome OS several years back. On systems with a static root of trust that extends to the filesystem level (e.g. Chrome OS s coreboot+depthcharge boot firmware chaining to dm-verity, or a system booting from read-only media), it s redundant to sign kernel modules (you ve already got the modules on read-only media: they can t change). The kernel just needs to know they re all coming from the correct location. (And this solves loading known-good firmware too, since there is no convention for signed firmware in the kernel yet.) LoadPin requires that all modules, firmware, etc come from the same mount (and assumes that the first loaded file defines which mount is correct , hence load pinning ). That s it for v4.7. Prepare yourself for v4.8 next!

2016, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

Review: Winds of Fury, by Mercedes Lackey

Series:	Mage Winds #3
Publisher:	DAW
Copyright:	August 1994
ISBN:	0-88677-612-0
Format:	Mass market
Pages:	427

This is the concluding book of the Mage Winds trilogy and a direct sequel to Winds of Change. This series doesn't make sense to read out of order. In traditional fantasy trilogies of this type, the third book is often the best. The author can stop developing characters, building the world, and setting the scene and can get to the meat of the story. All the guns on the mantles go off, all the twists the author has been saving can be used, and there's usually a lot more action than in the second book of a trilogy. That is indeed the case here. I'm not sure Winds of Fury rises to the level of a good book, but if you're invested in the Valdemar story, it works better than the previous books of this series. As one might expect, the protagonists do return to Valdemar, finally. The method of that return makes sense of some things that happened in Winds of Change and is an entertaining surprise, although I wish more had been done with it through the rest of the book and we'd gotten more world-building details. I also like how Lackey handles the Valdemar reactions to the returning protagonists, and their own reactions to Valdemar. Lackey's characters might fit some heavy-handed stereotypes a bit too neatly, but they do grow and change over the course of a series, and the return home is a good technique for showing that. Lackey also throws in her final twist for the villains of this series at the start of this book, and it's a good one (if typical Lackey; she does love her abused youth characters). The villains are still far too one-dimensional and far too stereotyped evil, but the twist (which I'll avoid spoiling) does make that dynamic a bit more interesting. And she manages to get the reader to root for one evil over another, since one of them is at least competent. You'd think from the direction the series was taking that Winds of Fury would culminate in another epic war of magic, but not this book. Lackey takes a more personal and targeted approach, heavier on characterization and individual challenge. This gives Firesong a chance to grow into an almost-likable character and earn some of that empathy and insight that he'd gotten for free. Unfortunately, it sidelines Nyara a lot, and pushes her back into a stereotyped role, which made me sad. The series otherwise emphasizes the importance of magic users who know their own limitations and can thoughtfully use the power they have, but rarely extends that to Nyara herself. I would have much rather seen her play a role like that in the final climax instead of the one she played. This is partly made up for by centering Need in the story and having her play the key connecting role between two different threads of effort. Those are probably the best parts of this book. I wish the entire series had been told from Need's perspective, with a heavy helping of exasperated grumbling, although I don't think Lackey could have written that series. But what we get of her is a delight. The gryphons, sadly, are relegated to fairly minor roles, but we get a few more tantalizing hints about the Companions to make up for it. (Although not enough to figure out their great mystery, which isn't revealed until future books.) This series is nowhere near as good as I remembered, sadly, but I did enjoy bits of it. If you like Valdemar in general, the world building is fairly important and reveals quite a lot about the underpinnings and power dynamics of Lackey's universe. I'm not sure that makes up for some tedious characters, poor communication, and some uncomfortable and dragging sections, but if you're trying to get the whole Valdemar story, the events here are rather important. And this ending was at least entertaining, if not great fiction. Rating: 6 out of 10

FTP assistant This month I was rather busy with other stuff and only marked 191 packages for accept and rejected 21 packages. I also sent 6 emails to maintainers asking questions. Debian LTS This was my twenty-seventh month that I did some work for the Debian LTS initiative, started by Raphael Hertzog at Freexian. This month my all in all workload has been 12.25h. During that time I did an upload of php5 fixing 17 CVEs and two additional bugs, I uploaded mactelnet and fixed one CVE. I also prepared a package for testing of zendframework, which will fix one CVE. Unfortunately my bind9 upload needed to be postponed as Florian Weimer found an incomplete patch of a previous CVE. I am trying to fix that as well. I also had some progress with the asterisk CVEs and of course the next round of php5 patches is waiting This month I also had a few days of frontdesk work at the beginning of the month and a few days at the end. Other stuff For the Alljoyn framework I uploaded alljoyn-services-1604 and as I forgot a Conflict:, I had to take care of RC-bugs: #836717, #836718 and #836719. Thanks a lot to Ralf Treinen for his automatic installation tests. As mentioned earlier, openzwave is on its way to the Debian archive. While it is still in non-free, the author of a used library gave his permission to relicense this code, so the way to main is paved now.

the last two weeks have seen the migration of perl 5.24 into testing, most of the bugs I worked on were related to it. additionally a few more build dependencies on tzdata werde needed. here's the list:

• #784845 libdevel-gdb-perl: "libdevel-gdb-perl: FTBFS: t/expect.t #8 sometimes fails"
  skip brittle test (pkg-perl)
• #825629 src:libgd-perl: "libgd-perl: FTBFS: Could not find gdlib-config in the search path. "
  add patch to use pkg-config instead of the removed gdlib-config (pkg-perl)
• #832840 src:license-reconcile: "license-reconcile: FTBFS: dh_auto_test: perl Build test --verbose 1 returned exit code 255"
  sponsor upload prepared by gfa (pkg-perl)
• #838310 keyboard-configuration: "keyboard-configuration: user configuration lost + error message from setupcon"
  propose a patch
• #838851 libcoro-perl: "libcoro-perl: FTBFS with Perl 5.24: panic: corrupt saved stack index -144185424"
  resurrect parts of the removed patch (pkg-perl)
• #838933 libio-compress-lzma-perl: "libio-compress-lzma-perl: uninstallable and unbuildable with Perl 5.24"
  fix dependencies (pkg-perl)
• #838934 libperl-apireference-perl: "libperl-apireference-perl: FTBFS with Perl 5.24.1"
  add support for 5.24.1 (pkg-perl)
• #839187 sa-compile: "sa-compile: failed make after perl upgraded to 5.24.1~rc3-3 on testing"
  close on suggestion of submitter after investigation
• #839442 src:libtime-parsedate-perl: "libtime-parsedate-perl: FTBFS: Tests failures"
  add build dependency on tzdata (pkg-perl)
• #839477 src:libposix-strftime-compiler-perl: "libposix-strftime-compiler-perl: FTBFS: dh_auto_test: perl Build test --verbose 1 returned exit code 5"
  add build dependency on tzdata (pkg-perl)
• #839513 src:libapache-logformat-compiler-perl: "libapache-logformat-compiler-perl: FTBFS: dh_auto_test: perl Build test --verbose 1 returned exit code 8"
  add build dependency on tzdata (pkg-perl)
• #839516 src:libclass-date-perl: "libclass-date-perl: FTBFS: Tests failures"
  add build dependency on tzdata (pkg-perl)

If you just install the snmp package out of the box, you won't get the MIBs, so it's pretty much useless for anything vendor without some setup. I'm sure this is documented somewhere, but I have to figure it out afresh every single time, so this time I'm writing it down; I can't possibly be the only one getting confused. First, install snmp-mibs-downloader from non-free. You'll need to work around bug #839574 to get the Cisco MIBs right:

# cp /usr/share/doc/snmp-mibs-downloader/examples/cisco.conf /etc/snmp-mibs-downloader/
# gzip -cd /usr/share/doc/snmp-mibs-downloader/examples/ciscolist.gz > /etc/snmp-mibs-downloader/ciscolist

Now you can download the Cisco MIBs:

# download-mibs cisco

However, this only downloads them; you will need to modify snmp.conf to actually use them. Comment out the line that says mibs : , and then add:

mibdirs +/var/lib/snmp/mibs/cisco/

Voila! Now you can use snmpwalk with e.g. -m AIRESPACE-WIRELESS-MIB to get the full range of Cisco WLC objects (and the first time you do so as root or the Debian-snmp user, the MIBs will be indexed in /var/lib/snmp/mib_indexes/.)

I was asked whether it would be safe to open a link in a spam message with wget. So here are some thoughts about wget security and web browser security in general. Wget Overview Some spam messages are designed to attack the recipient s computer. They can exploit bugs in the MUA, applications that may be launched to process attachments (EG MS Office), or a web browser. Wget is a very simple command-line program to download web pages, it doesn t attempt to interpret or display them. As with any network facing software there is a possibility of exploitable bugs in wget. It is theoretically possible for an attacker to have a web server that detects the client and has attacks for multiple HTTP clients including wget. In practice wget is a very simple program and simplicity makes security easier. A large portion of security flaws in web browsers are related to plugins such as flash, rendering the page for display on a GUI system, and javascript features that wget lacks. The Profit Motive An attacker that aims to compromise online banking accounts probably isn t going to bother developing or buying an exploit against wget. The number of potential victims is extremely low and the potential revenue benefit from improving attacks against other web browsers is going to be a lot larger than developing an attack on the small number of people who use wget. In fact the potential revenue increase of targeting the most common Linux web browsers (Iceweasel and Chromium) might still be lower than that of targeting Mac users. However if the attacker doesn t have a profit motive then this may not apply. There are people and organisations who have deliberately attacked sysadmins to gain access to servers (here is an article by Bruce Schneier about the attack on Hacking Team [1]). It is plausible that someone who is targeting a sysadmin could discover that they use wget and then launch a targeted attack against them. But such an attack won t look like regular spam. For more information about targeted attacks Brian Krebs article about CEO scams is worth reading [2]. Privilege Separation If you run wget in a regular Xterm in the same session you use for reading email etc then if there is an exploitable bug in wget then it can be used to access all of your secret data. But it is very easy to run wget from another account. You can run ssh otheraccount@localhost and then run the wget command so that it can t attack you. Don t run su otheraccount as it is possible for a compromised program to escape from that. I think that most Linux distributions have supported a switch user functionality in the X login system for a number of years. So you should be able to lock your session and then change to a session for another user to run potentially dangerous programs. It is also possible to use a separate PC for online banking and other high value operations. A 10yo PC is more than adequate for such tasks so you could just use an old PC that has been replaced for regular use for online banking etc. You could boot it from a CD or DVD if you are particularly paranoid about attack. Browser Features Google Chrome has a feature to not run plugins unless specifically permitted. This requires a couple of extra mouse actions when watching a TV program on the Internet but prevents random web sites from using Flash and Java which are two of the most common vectors of attack. Chrome also has a feature to check a web site against a Google black list before connecting. When I was running a medium size mail server I often had to determine whether URLs being sent out by customers were legitimate or spam, if a user sent out a URL that s on Google s blacklist I would lock their account without doing any further checks. Conclusion I think that even among Linux users (who tend to be more careful about security than users of other OSs) using a separate PC and booting from a CD/DVD will generally be regarded as too much effort. Running a full featured web browser like Google Chrome and updating it whenever a new version is released will avoid most problems. Using wget when you have to reason to be concerned is a possibility, but not only is it slightly inconvenient but it also often won t download the content that you want (EG in the case of HTML frames).

• [1] https://www.schneier.com/blog/archives/2016/04/how_hacking_tea.html
• [2] https://krebsonsecurity.com/2016/04/fbi-2-3-billion-lost-to-ceo-email-scams/

Review: Winds of Change, by Mercedes Lackey

Series:	Mage Winds #2
Publisher:	DAW
Copyright:	August 1993
ISBN:	0-88677-563-9
Format:	Mass market
Pages:	475

Winds of Change is a direct sequel to Winds of Fate. This is a more closely connected trilogy than the previous Valdemar books. It's not the sort of thing you want to read out of order. The events of Winds of Fate predictably left the multiple protagonists united and with some breathing space, but none of their problems are resolved. The Heartstone is still a mess; in fact, it may be getting worse. Elspeth needs to learn how to wield the magical power she apparently has. And there are a lot of interpersonal tensions, lingering hurt feelings, and (in the case of Elspeth and Darkwind) a truly prodigious quantity of whining that has to be worked through before the protagonists can feel safe and happy. Winds of Change is the training montage book, and wow did my memory paper over a lot of flaws in this series. This is 475 pages of not much happening, occasionally in very irritating ways. Yes, we do finally meander to a stronger conclusion than the last book, and there is much resolving of old hurts and awkward interactions, as well as a bit of discovery of true love (this is Lackey, after all). But far, far too much of the book is Elspeth and Darkwind sniping at each other, being immature, not communicating, and otherwise being obnoxious while all the people around them try to gently help. Lackey's main characterization flaw for me is that she tends to default into generating characters who badly need to be smacked upside the head, and then does so in ways and for things at odd angles to the reasons why I think they should be smacked. It can make for frustrating reading. The introduction of Firesong as a character about halfway through this book does not help. Firesong is a flamboyant, amazingly egotistical, and stunningly arrogant show-off who also happens to be a magical super-genius and hence has "earned" his arrogance. This is an intentional character design, not my idiosyncratic reaction to the character, since every other character in the book finds him insufferable as well at first. But he's also a deeply insightful healing Adept by, honestly, authorial fiat, so by the end of the novel he's helped patch up everyone's problems and the other characters have accepted his presentation as a character quirk. Sigh. So, okay, one doesn't read popcorn fantasy for its deep characterization or realistic grasp of human subtlety. But this is just way more than I can swallow. Lackey's concept of a healing Adept (which I like a great deal as a bit of world-building) necessarily involves both deep knowledge and deep empathy and connection with other people. Firesong is so utterly full of himself that there's simply no way that he could have the empathy required to do what he is shown to do here. (Lackey does try to explain this away in the book, but the explanation didn't work for me.) Every time he successfully intervenes in other people's emotional lives, he does so with a sudden personality change, some stunning insight that he previously showed no evidence of ability to understand, and somehow only enough arrogance in his presentation to prickle but not to close people's mind to whatever he's trying to say. That's not how this works. That's not how any of this works. Lackey always treats psychology as a bit of a blunt instrument, and one either learns to tolerate that or gives up on her series, but Firesong is flatly the most unbelievable emotional mentor figure in any of her books I've read. (One of the more satisfying, if slight, bits of this series comes up in the next book, where Firesong runs into someone else who can do the same thing but has actually earned the empathy the hard way, and is a bit taken aback by it.) My other complaint with this book is that Lackey adds more chapters from the viewpoint of the big bad of the series. These are deeply unpleasant, since he's a deeply unpleasant person, and seem largely unnecessary. It's vaguely interesting to follow the magical maneuverings from both sides, but there are more of these scenes than strictly necessary for that purpose, and the sheer unmitigated evil of Lackey's evil characters is a bit hard to take. Also, he somehow has vast resources of staff and assistants, and much suspension of disbelief is required to believe that anyone would continue working for this person. It's one thing to imagine people being drawn to a charismatic Hitler type; it's quite another when the boss is a brooding, imperious asshole who roams the hallways and tortures random people to death whenever he's bored. Fear and magic only go so far in maintaining a large following when you do that, and he generates dead bodies at a remarkable rate. The best characters in this series continue to be Nyara, Need, and the gryphons. I'd rather read a book just about them. Need does use a bit too much of Lackey's tough love technique (another recurring theme of this larger series), but from Need that's wholly believable; her gruff and dubious empathy is in line with her character and history and fits a talking sword extremely well. But they, despite having a bit of their own training montage, are a side story here. The climax of the story is moderately satisfying, but the book takes far too long to get to it. I remember liking this series when I first read it, and I still like some aspects of Lackey's world-building and a few of the characters, but it's much weaker than I had remembered. I can't really recommend it. Followed by Winds of Fury. Rating: 5 out of 10

An new version 0.0.8 of RcppAnnoy, our Rcpp-based R integration of the nifty Annoy library by Erik, is now on CRAN. Annoy is a small, fast, and lightweight C++ template header library for approximate nearest neighbours. This release pulls in a few suggested changes which had piled up since the last release. Changes in this version are summarized here:

Changes in version 0.0.8 (2016-10-01)

• New functions getNNsByItemList and getNNsByVectorList, by Michael Phan-Ba in #12
• Added destructor (PR #14 by Michael Phan-Ba)
• Extended templatization (PR #11 by Dan Dillon)
• Switched to run.sh for Travis (PR #17)
• Added test for admissible value to addItem (PR #18 closing issue #13)

Courtesy of CRANberries, there is also a diffstat report for this release.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

I sent this email to debian-private a few days ago, on the 10th anniversary of my Debian account creation:

Date: Fri, 14 Aug 2015 19:37:20 +0200
From: David Moreno 
To: debian-private@lists.debian.org
Subject: Retiring from Debian
User-Agent: Mutt/1.5.23 (2014-03-12)
[-- PGP output follows (current time: Sun 23 Aug 2015 06:18:36 PM CEST) --]
gpg: Signature made Fri 14 Aug 2015 07:37:20 PM CEST using RSA key ID 4DADEC2F
gpg: Good signature from "David Moreno "
gpg:                 aka "David Moreno "
gpg:                 aka "David Moreno (1984-08-08) "
[-- End of PGP output --]
[-- The following data is signed --]
Hi,
Ten years ago today (2005-08-14) my account was created:
https://nm.debian.org/public/person/damog
Today, I don't feel like Debian represents me and neither do I represent the
project anymore.
I had tried over the last couple of years to retake my involvement but lack of
motivation and time always got on the way, so the right thing to do for me is
to officially retire and gtfo.
I certainly learned a bunch from dozens of Debian people over these many years,
and I'm nothing but grateful with all of them; I will for sure carry the project
close to my heart   as I carry it with the Debian swirl I still have tattooed
on my back ;)
http://damog.net/blog/2005/06/29/debian-tattoo/
I have three packages left that have not been updated in forever and you can
consider orphaned now: gcolor2, libperl6-say-perl and libxml-treepp-perl.
With all best wishes,
David Moreno.
http://damog.net/
[-- End of signed data --]

I received a couple of questions about my decision here. I basically don t feel like Debian represents my interests and neither do I represent the project this doesn t mean I don t believe in free software, to the contrary. I think some of the best software advancements we ve made as society are thanks to it. I don t necessarily believe on how the project has evolved itself, whether that has been the right way, to regain relevancy and dominance, and if it s remained primarily a way to feed dogmatism versus pragmatism. This is the perfect example of a tragic consequence. I was very happy to learn that the current Debian Conference being held in Germany got the highest attendance ever, hopefully that can be utilized in a significant and useful way. Regardless, my contributions to Debian were never noteworthy so it s also not that big of a deal. I just need to close cycles myself and move forward, and the ten year anniversary looked like a significant mark for that. Poke me in case you wanna discuss some more. I ll always be happy to. Specially over beer :) Peace.

There has been a great deal of comment among my friends recently about a particularly British cookery program called "The Great British Bake Off". There has been some controversy as the program is moving from the BBC to a commercial broadcaster.

Part of this discussion comes from all the presenters, excepting Paul Hollywood, declining to sign with the new broadcaster and partly because of speculation the BBC might continue with a similar format show with a new name.

Rob Kendrick provided the start to this conversation by passing on a satirical link suggesting Samuel L Jackson might host "cakes on a plane"

This caused a large number of suggestions for alternate names which I will be reporting but Rob Kendrick, Vivek Das Mohapatra, Colin Watson, Jonathan McDowell, Oki Kuma, Dan Alderman, Dagfinn Ilmari Manns ke, Lesley Mitchell and Daniel Silverstone are the ones to blame.

• Strictly come baking
• Stars and their pies
• Baking with the stars
• Bake/Off.
• Blind Cake
• Cake or no cake?
• The cake is a lie
• Bake That.
• Bake Me On
• Bake On Me
• Bakin' Stevens.
• The Winner Bakes It All
• Bakerloo
• Bake Five
• Every breath you bake
• Every bread you bake
• Unbake my heart
• Knead and let prove
• Bake me up before you go-go
• I want to bake free
• Another bake bites the dust
• Cinnamon whorl is not enough
• The pie who loved me
• The yeast you can do.
• Total collapse of the tart
• Bake and deliver
• You Gotta Bake
• Bake's Seven
• Natural Born Bakers
• Bake It Or Leaven It
• Driving the last pikelet
• Pie crust on the dancefloor
• Tomorrow never pies
• Murder on the pie crust
• The pie who came in from the cold.
• You only bake twice (Every body has to make one sweet and one savoury dish).

So that is our list, anyone else got better ideas?

Categories:

• Debian-Blog
• Computing
• Tools

Keywords:

• GNOME Shell Extensions
• Chromium
• Chrome
• Browser

Like:

Debian LTS Report for September 2016 September 2016 was my first month as a payed Debian LTS Team member. After doing two small uploads to wheezy-security in August and got to know the LTS Team workflow, this month I was allocated 9 hours by Freexian. I spent all 9 hours on working on security updates to Debian Wheezy. In particular, I worked on the following issues:

• DLA 612-1: libtomcrypt PKCS#1 RSA signature verification
• DLA 617-1: libarchive out of bounds and denial of service
• DLA 625-1: libcurl escape/unescape integer overflows
• DLA 627-1: pdns qname's length>255b, missing zone size limits
• worked on mat issue with embeded images in PDFs (#826101)

For reference, these were the issues I worked on in August:

• DLA 584-1: libsys-syslog-perl opportunistic loading of optional modules
• DLA 589-1: mupdf out of bounds write access to memory locations

Links

• Debian Wiki: Debian Long Term Support
• Freexian: Debian Long Term Support

Previously: v4.5. The v4.6 Linux kernel release included a bunch of stuff, with much more of it under the KSPP umbrella. seccomp support for parisc Helge Deller added seccomp support for parisc, which including plumbing support for PTRACE_GETREGSET to get the self-tests working. x86 32-bit mmap ASLR vs unlimited stack fixed Hector Marco-Gisbert removed a long-standing limitation to mmap ASLR on 32-bit x86, where setting an unlimited stack (e.g. ulimit -s unlimited ) would turn off mmap ASLR (which provided a way to bypass ASLR when executing setuid processes). Given that ASLR entropy can now be controlled directly (see the v4.5 post), and that the cases where this created an actual problem are very rare, means that if a system sees collisions between unlimited stack and mmap ASLR, they can just adjust the 32-bit ASLR entropy instead. x86 execute-only memory Dave Hansen added Protection Key support for future x86 CPUs and, as part of this, implemented support for execute only memory in user-space. On pkeys-supporting CPUs, using mmap(..., PROT_EXEC) (i.e. without PROT_READ) will mean that the memory can be executed but cannot be read (or written). This provides some mitigation against automated ROP gadget finding where an executable is read out of memory to find places that can be used to build a malicious execution path. Using this will require changing some linker behavior (to avoid putting data in executable areas), but seems to otherwise Just Work. I m looking forward to either emulated QEmu support or access to one of these fancy CPUs. CONFIG_DEBUG_RODATA enabled by default on arm and arm64, and mandatory on x86 Ard Biesheuvel (arm64) and I (arm) made the poorly-named CONFIG_DEBUG_RODATA enabled by default. This feature controls whether the kernel enforces proper memory protections on its own memory regions (code memory is executable and read-only, read-only data is actually read-only and non-executable, and writable data is non-executable). This protection is a fundamental security primitive for kernel self-protection, so making it on-by-default is required to start any kind of attack surface reduction within the kernel. On x86 CONFIG_DEBUG_RODATA was already enabled by default, but, at Ingo Molnar s suggestion, I made it mandatory: CONFIG_DEBUG_RODATA cannot be turned off on x86. I expect we ll get there with arm and arm64 too, but the protection is still somewhat new on these architectures, so it s reasonable to continue to leave an out for developers that find themselves tripping over it. arm64 KASLR text base offset Ard Biesheuvel reworked a ton of arm64 infrastructure to support kernel relocation and, building on that, Kernel Address Space Layout Randomization of the kernel text base offset (and module base offset). As with x86 text base KASLR, this is a probabilistic defense that raises the bar for kernel attacks where finding the KASLR offset must be added to the chain of exploits used for a successful attack. One big difference from x86 is that the entropy for the KASLR must come either from Device Tree (in the /chosen/kaslr-seed property) or from UEFI (via EFI_RNG_PROTOCOL), so if you re building arm64 devices, make sure you have a strong source of early-boot entropy that you can expose through your boot-firmware or boot-loader. zero-poison after free Laura Abbott reworked a bunch of the kernel memory management debugging code to add zeroing of freed memory, similar to PaX/Grsecurity s PAX_MEMORY_SANITIZE feature. This feature means that memory is cleared at free, wiping any sensitive data so it doesn t have an opportunity to leak in various ways (e.g. accidentally uninitialized structures or padding), and that certain types of use-after-free flaws cannot be exploited since the memory has been wiped. To take things even a step further, the poisoning can be verified at allocation time to make sure that nothing wrote to it between free and allocation (called sanity checking ), which can catch another small subset of flaws. To understand the pieces of this, it s worth describing that the kernel s higher level allocator, the page allocator (e.g. __get_free_pages()) is used by the finer-grained slab allocator (e.g. kmem_cache_alloc(), kmalloc()). Poisoning is handled separately in both allocators. The zero-poisoning happens at the page allocator level. Since the slab allocators tend to do their own allocation/freeing, their poisoning happens separately (since on slab free nothing has been freed up to the page allocator). Only limited performance tuning has been done, so the penalty is rather high at the moment, at about 9% when doing a kernel build workload. Future work will include some exclusion of frequently-freed caches (similar to PAX_MEMORY_SANITIZE), and making the options entirely CONFIG controlled (right now both CONFIGs are needed to build in the code, and a kernel command line is needed to activate it). Performing the sanity checking (mentioned above) adds another roughly 3% penalty. In the general case (and once the performance of the poisoning is improved), the security value of the sanity checking isn t worth the performance trade-off. Tests for the features can be found in lkdtm as READ_AFTER_FREE and READ_BUDDY_AFTER_FREE. If you re feeling especially paranoid and have enabled sanity-checking, WRITE_AFTER_FREE and WRITE_BUDDY_AFTER_FREE can test these as well. To perform zero-poisoning of page allocations and (currently non-zero) poisoning of slab allocations, build with:

CONFIG_DEBUG_PAGEALLOC=n
CONFIG_PAGE_POISONING=y
CONFIG_PAGE_POISONING_NO_SANITY=y
CONFIG_PAGE_POISONING_ZERO=y
CONFIG_SLUB_DEBUG=y

and enable the page allocator poisoning and slab allocator poisoning at boot with this on the kernel command line:

page_poison=on slub_debug=P

To add sanity-checking, change PAGE_POISONING_NO_SANITY=n, and add F to slub_debug as slub_debug=PF . read-only after init I added the infrastructure to support making certain kernel memory read-only after kernel initialization (inspired by a small part of PaX/Grsecurity s KERNEXEC functionality). The goal is to continue to reduce the attack surface within the kernel by making even more of the memory, especially function pointer tables, read-only (which depends on CONFIG_DEBUG_RODATA above). Function pointer tables (and similar structures) are frequently targeted by attackers when redirecting execution. While many are already declared const in the kernel source code, making them read-only (and therefore unavailable to attackers) for their entire lifetime, there is a class of variables that get initialized during kernel (and module) start-up (i.e. written to during functions that are marked __init ) and then never (intentionally) written to again. Some examples are things like the VDSO, vector tables, arch-specific callbacks, etc. As it turns out, most architectures with kernel memory protection already delay making their data read-only until after __init (see mark_rodata_ro()), so it s trivial to declare a new data section ( .data..ro_after_init ) and add it to the existing read-only data section ( .rodata ). Kernel structures can be annotated with the new section (via the __ro_after_init macro), and they ll become read-only once boot has finished. The next step for attack surface reduction infrastructure will be to create a kernel memory region that is passively read-only, but can be made temporarily writable (by a single un-preemptable CPU), for storing sensitive structures that are written to only very rarely. Once this is done, much more of the kernel s attack surface can be made read-only for the majority of its lifetime. As people identify places where __ro_after_init can be used, we can grow the protection. A good place to start is to look through the PaX/Grsecurity patch to find uses of __read_only on variables that are only written to during __init functions. The rest are places that will need the temporarily-writable infrastructure (PaX/Grsecurity uses pax_open_kernel()/pax_close_kernel() for these). That s it for v4.6, next up will be v4.7!

2016, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

It is the first of October and that means the transition freeze is roughly one month away (Nov 5th 2016). In other words, this is the final boarding call for transitions . Other milestone dates:

• If you want new packages into Stretch, you have about 3 months (Jan 5th 2017). This includes auto removed packages.
• Automatic updates of existing packages stop in 4 months (Feb 5th 2017)

Filed under: Debian, Release-Team

Review: Sailing to Sarantium, by Guy Gavriel Kay

Series:	Sarantine Mosaic #1
Publisher:	HarperPrism
Copyright:	1998
Printing:	January 2000
ISBN:	0-06-105990-0
Format:	Mass market
Pages:	533

Crispin is a well-respected mosaicist, a Rhodian, heir to a long tradition of artistic accomplishment. Rhodias is largely in ruins, and the kings that fight over its land are far removed from the emperors of Rhodias at its height, but there's still demand for skilled craftsmanship. Crispin has a partner, assistants, and the opportunity to do at least adequate work. It's not a bad life, or at least wasn't before plague took his wife and daughters while he watched, helpless. Now, he's closed off, angry, and consumed by fatalism and futility. His partner, Martinian, could never say why, when the imperious and obnoxious courier came from the far-off and half-legendary of Sarantium to summon him to assist with the rebuilding of the Sanctuary of Jad, he pretended not to be himself and pointed the courier at Crispin instead. Nor was Crispin entirely sure why he played along, although the courier was so arrogant and officious that he invited such treatment. He had no intention of going in Martinian's place and name until his friends intervened, united in their conviction that he needed something to focus on and a reason to live. But nothing about Sarantium is simple. Even before Crispin leaves, the local queen, precariously balancing between warring factions, reveals her own reason to send Crispin to the capital of the far-off empire: using him as a desperate messenger to propose an alliance through marriage. And when he finally arrives, after unexpected perils on the road, he tumbles immediately into the deep complexities of the Sarantine court and its remarkable rulers. Most of Guy Gavriel Kay's work is historical fiction with the serial numbers partly filed off and some magic added. The degree to which the serial numbers are removed varies by work; here, the history is obvious. Sarantium is Byzantium, fallen Rhodias is Rome, and the emperor Valerius and his former dancer empress Alixana are clearly Justinian and Theodora. Knowing that will provide a lot of context, but can also be distracting, since the temptation to scramble for Wikipedia and line things up with real history is strong. I read this book the first time without knowing the history and this second time knowing it. I think I enjoyed it a bit more on its own terms, instead of as a reflection and reinterpretation. Either way, though, it's one of Kay's best novels, which is saying quite a bit. Sailing to Sarantium has two very different parts: Crispin's journey to Sarantium, and then what happens when he arrives. The first is a fairly linear travel narrative mixed with old religion, magic, and an experience in the woods that's a little disconnected from the rest of the story. The second is the fast-entangling politics and factionalism of the city itself, which wastes no time pulling Crispin into meetings with the most influential people at court. In my memory, I liked the Sarantium narrative the best, and found the travel story less significant. Re-reading, I'm not sure I agree with my earlier self. Kay does write some of the best conversations in fiction; if you want to see careful verbal maneuvering or gut reactions with wide-ranging consequences, I can't think of any author who shows both the words and the nuances as well as Kay. He makes the court maneuvering feel truly epic. Watching Crispin's blunt competence cut through the Sarantine court, and seeing him stay focused on his life work despite all those distractions, is a truly rewarding experience. But that second part of the book also has some structural problems, and a few characterization problems. The structural problem is that Kay wants to tell the same story from multiple angles, viewpoints, and timelines to show the reader every implication of the hornet's nest that Crispin kicks over, since quite a lot happens in the course of one day and night. This mostly works, but it is so laden with flashbacks, foreshadowing, and rewinds that I started losing track of the time relationship between the scenes. Kay is a very skilled author, so he avoids confusing the reader entirely, but I think he still tried too complex of a temporal structure here. The characterization problem is that I previously wasn't paying as close of attention to Kay's portrayal of women and of male sexual reactions to women. It didn't bother me before; this time, it started getting on my nerves. Yes, this is historical fiction (although limitations on roles for women in history is rather overstated in fiction), and to give Kay credit it does feature a very strong female character in Alixana. But the male protector and female seducer dynamic is very strong, and all the women in this book seem to get shoehorned into it. And perhaps I'm missing some weakness that other men have, but I have never had the sort of overwhelming, thought-destroying reaction to the presence of a seductive woman as Kay's men seem to routinely have in this book. To give Crispin credit, he maneuvers his way through those conversations without doing anything stupid. (Kay's characters very rarely do stupid things, which is refreshing.) But the effort required started undermining my suspension of disbelief. Even making allowances for a culture that might consider a woman with her hair down the equivalent of an entirely nude woman, I simply don't believe that a man who had been married with two daughters, had a long career, and had the life experience Crispin had would have that much difficulty with an aggressively seductive woman that he already doesn't trust. As a result, as much as I love Kay's political conversational fencing, I enjoyed the travel portion of the book more on this re-read. Crispin is a type of character Kay writes extremely well: an honest, honorable man trying to navigate unfamiliar waters without a lot of context, but with a firm sense of internal morality, a lot of natural intelligence, and a true passion for something. At one point in this book, another character decides to walk away from his current job and follow Crispin wherever he goes. Kay makes you believe that and want to do it yourself. It's a very rewarding experience as a reader to watch a character you can trust find careful, courageous, and tricky solutions to complicated problems. But I think the best part of this book is Kay's ability to put Crispin's art, the creation of mosaics, on the page in a way that lets the reader viscerally appreciate it. Crispin is passionate about mosaics, about how to make them and how to think about them, and the passion is contagious and forms the heart and soul of this novel. Kay manages to make mosaics overshadow some of the most dramatic politics in history, which says quite a lot. There is almost nothing I love more than reading about talented, passionate people doing things they are extremely good at. I know nothing about mosaic that I haven't read in this book and its sequel, so I have no basis from which to judge the accuracy of Kay's portrayal, but he made me feel like I could appreciate some of the nuance, skill, and design constraints of the art form. It's a wonderful reading experience. Sailing to Sarantium is best thought of half of a long book that was divided for publication reasons, so don't expect much of an ending here. It can only be read in combination with Lord of Emperors, which you'll want to have on hand when you finish this book so that you can continue the story. Followed by Lord of Emperors. Rating: 9 out of 10

Here is my monthly update covering what I have been doing in the free software world (previous month):

• Fixed a number of instances in the Django web development framework where methods had mutable defaults arguments such as lists or dictionaries. (#7253)
• Made a large number of improvements to travis.debian.net, my hosted service for projects that host their Debian packaging on GitHub to use the Travis CI continuous integration platform to test builds on every update:
  • Worked with Evgeni Golov to run autopkgtest and autodep8 tests after builds. (#23, #24 & #25)
  • Ensured that all remote branches are created locally so that packages that specify options such as pristine_tar=True in debian/gbp.conf work as expected. (commit)
  • Fixed an issue where checking out other branches did not reliably not work due to Travis cloning the repository with --depth=50. (#21)
  • Updated the documentation after prompting from Valerie Young. (db7238 & 470d24)
• Improved my Chrome extension for the FastMail web interface to collapse whitespace when appending to the subject. (#9)
• Submitted a pull request for the Handbrake video transcoder to make the build reproducible. (#320)
• Updated the configuration for my OpenWRT-based router (a device I use as a range extender and to save tedious reconfiguration of all my wifi devices in new locales) to enter a "fallback" mode if it cannot connect to the client network. This works around a longstanding "wontfix" upstream issue. (diff)
• Updated django-agpl, my reusable Django application to assist in releasing projects under the GNU Affero General Public License:
  • Merged support from defivelo to support Django 1.8. (#1)
  • Improved the code quality & testability throughout the package. (diff)
• Filed in issue in Mailvelope (a browser extension for OpenPGP encryption) to support composing/viewing messages in a fixed-width font. (#422)
• Blogged about how to write your first Lintian check as well as on the progress bar I added to Diffoscope.

---

At the end of August 2012, I announced my Early Retirement from HP. Two years later, my friend and former boss Martin Fink successfully recruited me to return to what later became Hewlett Packard Enterprise, as an HPE Fellow working on open source strategy in his Office of the CTO. I'm proud of what I was was able to accomplish in the 25 months since then, but recent efforts to "simplify" HPE actually made things complicated for me. Between the announcement in late June that Martin intended to retire himself, and the two major spin-merger announcements involving Enterprise Services and Software... well... The bottom line is that today, 30 September 2016, is my last day at HPE. My plan is to "return to retirement" and work on some fun projects with my wife now that we are "empty nesters". I do intend to remain involved in the Free Software and open hardware worlds, but whether that might eventually involve further employment is something I'm going to try and avoid thinking about for a while... There is a rocket launch scheduled nearby this weekend, after all!

A pure maintenance release 0.2.6 of the gcbd package is now on CRAN. The gcbd proposes a benchmarking framework for LAPACK and BLAS operations (as the library can exchanged in a plug-and-play sense on suitable OSs) and records result in local database. Recent / upcoming changes to DBMI and RSQLite let me to update the package; there are no actual functionality changes in this release. CRANberries also provides a diffstat report for the latest release.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

A new version of the RcppCNPy package arrived on CRAN a few days ago. RcppCNPy provides R with read and write access to NumPy files thanks to the cnpy library by Carl Rogers. This new release reflects all the suggestions and comments I received during the review process for the Journal of Open Source Software submission. I am happy to say that about twenty-nine days after I submitted, the paper was accepted and is now published.

Changes in version 0.2.6 (2016-09-25)

• Expanded documentation in README.md
• Added examples to help page
• Added CITATION file for JOSS paper

CRANberries also provides a diffstat report for the latest release. As always, feedback is welcome and the best place to start a discussion may be the GitHub issue tickets page.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.