I added dh to debhelper a decade ago, and now Debian is considering
making use of dh mandatory. Not being part of Debian anymore, I'm in
the position of needing to point out something important about it anyway.
So this post is less about pointing in a specific direction as giving a
different angle to think about things.

debhelper was intentionally designed as a 100% solution for
simplifying building Debian packages. Any package it's used with gets
simplified and streamlined and made less a bother to maintain. The way
debhelper succeeds at 100% is not by doing everything, but by being usable
in little pieces, that build up to a larger, more consistent whole, but
that can just as well be used sparingly.

dh was intentionally not designed to be a 100% solution, because it is
not a collection of little pieces, but a framework. I first built
an 80% solution, which is the canned sequences of commands it runs plus
things like dh_auto_build that guess at how to build any software. Then I
iterated to get closer to 100%. The main iteration was override targets in
the debian/rules file, to let commands be skipped or run out of order or
with options. That closed dh's gap by a further 80%.

So, dh is probably somewhere around a 96% solution now. It may have crept
closer still to 100%, but it seems likely there is still a gap, because it
was never intended to completely close the gap.

Starting at 100% and incrementally approaching 100% are very different
design choices. The end results can look very similar, since in both cases
it can appear that nearly everyone has settled on doing things in the same
way. I feel though, that the underlying difference is important.

PS: It's perhaps worth re-reading the original debhelper email
and see how much my original problems with debstd would also apply to dh if
its use were mandatory!

For three years my work on git-annex had major support from Dartmouth's
DataLad project, pushing it into use in the
sciences, and driving large improvements in git-annex's API, concurrency
support, etc. But that relied on government funding which has been drying up.
Increasingly I have been relying on croudfunding from git-annex's users.

Now I'm entering a new phase, where DataLad users may also want to support
git-annex. So far, McGill's NeuroHub project has committed to supporting
its development (funded by the Canada First Research Excellence Fund,
for the Healthy Brains for Healthy Lives initiative), but I hope others
will too. A diversity of funding sources is best.

A survey of git-annex users
is now underway, the first in three years. If you've not already, please
participate in it to help direct my newly funded work.

I've proven that it works. I've not gotten food poisoning, though I did lose
half a gallon of milk on one super rainy week. I have
piles of data, and
a whole wiki documenting how I built
it. I've developed 3 thousand lines of control software. It purrs along
without any assistance.

This isn't going to solve global warming or anything, but it does seem
much less expensive than traditional offgrid fridge systems, and
it ties in with thinking on renewable power such as Low Tech magazine's
Redefining Energy Security
"To improve energy security, we need to make infrastructures less reliable."

I mostly wanted to share the wiki,
in case someone wants to build something like this. And to post some data.
Here's the summer and fall temperature data.

I want to be upfront that this is not guaranteed to work in every situation.
Here's that time that the milk spoiled. A tropical storm was involved.
Most of the time milk stays good 2 to 3 weeks in my fridge.

Some things I might get around to doing eventually:

Using a supercapacitor to provide power while shutting down on loss of solar
power, instead of the current few minutes of use of batteries.

Also running a freezer, dividing up solar power between them.

A self-contained build with its own solar panels and electronics, instead of
the current build that uses my house's server and solar panels.

A full BOM or kit, just add solar panels and chest freezer
to quickly build your own.

I probably won't be devoting much time to this in the upcoming year,
but if anyone wants to build one I'm happy to help you.

I'm pleased to have teamed up with AT&T
to bring you this illustrated guide to effective bug tracking.

The original issue description was "noise / static on line", and as we
can see, AT&T have very effectively closed the ticket:
There is no longer any noise, of any kind, on the phone line.

No electrons == no noise, so this is the absolute simplest and most
effective fix possible. Always start with the simplest such fix, and be
sure to close the problem ticket immediately on fixing. Do not followup with the
issue reporter, or contact them in any way to explain how the issue was
resolved.

While in the guts of the system fixing such a bug report, you'll probably
see something that could be improved by some light refactoring. It's always
a good idea to do that right away, because refactoring can often just
solves an issue on its own somehow. (Never use your own issue tracking
system to report issues to yourself to deal with later, because that would
just be bonkers.)

But don't go overboard with refactoring. As we see here, when AT&T decided
to run a new line between two poles involved in my bug report, they simply
ran it along the ground next to my neighbor's barn. A few festive loops and
bows prevent any possible damage by tractor. Can always refactor more later.

The only other information included in my bug report was
"house at end of loong driveway". AT&T helpfully limited the size
of the field to something smaller than 1 (old-style) tweet,
to prevent some long brain dump being put in there.

You don't want to hear that I've lived here for 7 years and the buried line
has never been clean but's been getting a bit more noisy lately, or that I
noticed signs of water ingress at two of the junction boxes, or that it got
much much worse after a recent snow storm, to the point that I was
answering the phone by yelling "my phone line is broken" down the line
consumed with static.

Design your bug tracking system to not let the user really communicate with
you. You know what's wrong better than them.

And certianly don't try to reproduce the circumstances of the bug report.
No need to visit my house and check the outside line when
you've already identified and clearly fixed the problem at the pole.

My second bug report is "no dial tone" with access information "on porch
end of long driveway". With that, I seem to be trying to solicit some kind
of contact outside the bug tracking system. That is never a good idea
though, and AT&T should instruct their linemen to avoid any possible
contact with the user, or any attempts to convey information outside the
issue tracking system.

For a long time I've not had any network attached storage at home, because
it's offgrid and power budget didn't allow it. But now I have 16
terabytes of network attached storage, that uses no power at all when
it's not in use, and automatically spins up on demand.

I used a USB hub with per-port power control. But even with a USB drive's
port powered down, there's a parasitic draw of around 3 watts per drive.
Not a lot, but with 4 drives that's more power wasted than leaving a couple
of ceiling lights on all the time. So I put all the equipment behind a
relay too, so it can be fully powered down.

I'm using systemd for automounting the drives, and have it configured to
power a drive's USB port on and off as needed using
uhubctl.
This was kind of tricky to work out how to do, but it works very well.

The combination of PartOf with Requires and After in these units makes
systemd start the port 4 service before mounting the drive, and
stop it after unmounting. This was the hardest part to work out.

The sleep 20 is a bit unfortunate, it seems that it can take a few seconds for
the drive to power up enough for the kernel to see it, and so without that the
mount can fail, leaving the drive powered on indefinitely. Seems there
ought to be a way to declare an additional dependency and avoid needing that sleep?
Update: See my comment below for a better way.

Finally, the automount unit for the drive, media-joey-passport.automount:

The TimeoutIdleSec makes it unmount after around 5 minutes of not being used,
and then its USB port gets powered off.

I decided to not automate the relay as part of the above, instead I
typically turn it on for 5 hours or so, and use the storage whenever I want
during that window. One advantage to that is cron jobs can't spin up
the drives in the early morning hours.

For the past week and a half, I've been working on embargoed
security holes.
The embargo is over, and git-annex 6.20180626 has been
released,
fixing those holes. I'm also announcing a new Haskell library,
http-client-restricted, which could be used to avoid
similar problems in other programs.

Working in secret under a security embargo is mostly new to me, and I
mostly don't like it, but it seems to have been the right call in this
case. The first security hole I found in git-annex turned out to have a
wider impact, affecting code in git-annex plugins (aka external special
remotes) that uses HTTP. And quite likely beyond git-annex to unrelated
programs, but I'll let their developers talk about that. So quite a lot of
people were involved in this behind the scenes.

And then there was the second security hole in git-annex, which took
several days to notice, in collaboration with Daniel Dent. That one's
potentially very nasty, allowing decryption of arbitrary gpg-encrypted
files, although exploiting it would be hard. It logically
followed from the first security hole, so it's good that the first
security hole was under embagro long enough for us to think it all
though.

These security holes involved HTTP servers doing things to exploit
clients that connect to them. For example, a HTTP server that a client asks
for the content of a file stored on it can redirect to a file://
on the client's disk, or to http://localhost/ or a private web server on
the client's internal network. Once the client is tricked into downloading
such private data, the confusion can result in private data being exposed.
See the_advisory
for details.

Fixing this kind of security hole is not necessarily easy, because we use
HTTP libraries, often via an API library, which may not give much
control over following redirects. DNS rebinding attacks can be
used to defeat security checks, if the HTTP library doesn't expose
the IP address it's connecting to.

I faced this problem in git-annex's use of the Haskell
http-client library.
So I had to write a new library, http-client-restricted. Thanks
to the good design of the http-client library, particularly its Manager
abstraction, my library extends it rather than needing to replace it,
and can be used with any API library built on top of http-client.

I get the impression that a lot of other language's HTTP libraries need
to have similar things developed. Much like web browsers need to enforce
same-origin policies, HTTP clients need to be able to reject certain
redirects according to the security needs of the program using them.

I kept a private journal while working on these security holes, and am
publishing it now: