I forked acme-tiny the other day and replaced http-01 with dns-01. The dns-01 implementation is pretty simple and crude for now, I'll probably add dynamic dns update support at some point. All it does is print the records out and wait for you to add them manually.
The court order refers to the need to load the custom OS image via DFU (device firmware upgrade) mode. I am not an iPhone user but I'm assuming that is exactly what the name implies. (some pre-boot recovery environment)
Basically for many years now glibc has been knowingly doing the wrong thing just to keep malloc_set_state/malloc_get_state working. Which as far as anyone knows, is used only by emacs. Keeping this interface alive for the sole benefit of an emacs optimization when it is blocking the fixes for fairly serious bugs is a pretty big bar to meet for justification.
In the end this is largely a non-issue as an Emacs developer noted that their configure script probes for the special glibc malloc API and if it doesn't exist then emacs will use its own malloc implementation. The conclusion is that once the glibc devs get their changes up, everyone can meet up again to make sure existing emacs binaries still run and that the API detection in the emacs configure script works right.
So props to Paul Eggert for being the only sane man in the room and pointing out that the drama was all for nothing.
The distributed form of a project (especially one based on GNU autotools) is often not merely a tarball of the upstream repository. Often the author has pre-run some stages of the build that she feels would impose unnecessary or esoteric dependencies. Typically this involves pre-generating Makefile.in from Makefile.am and configure from configure.ac. Another common one is for the maintainer to pre-generate the documentation. The user of the distributed tarball is fully capable of re-running these steps, but they have become optional.
This is a fact often forgotten when projects switch to github and just start using the automated release tarballs github will make from the repo.
You've hit on a fine point I often make about how the term "security bug" is used.
I would call this a bug fix since someone has found what is probably an unintended behavior in the cubic algorithm. The cubic algorithm itself though would be a feature improving on the original tcp algorithm (nagle, if I remember right)
Same reason unix systems typically did the same with theirs (albeit on port 111)
Its not very useful if other machines can't talk to it.
Keep in mind, the decision to do this in Windows happened back when home computers were on dialup. (Even RFC 1918 and NAT were young at the time) The real question is why didn't Windows have a firewall that blocked it by default and the answer is that it has.... since XP SP2 was released in 2004.
Since marketing and selling jamming devices is illegal, I would like to know what the FCC is going to do about the supply chain. We know these are all using well known advertised features of enterprise wireless gear. Are they working on a consent decree with Cisco/Aruba/etc to stop including this feature? Or are they going to play whack-a-mole with end users for the next decade?
