Ubiquitous surveillance is a given these days, and I am not commenting on the crime or the level of stupidity of the murderer, but the fact that the iPhone even logs when you turn your flashlight on and off is scary.
Very, very scary in all its myriad of implications.
But at least it's not as if both your phone and your carrier wouldn't log your every move anyway.
Because Enhanced 911 and its ability to silently tell the authorities your position was not enough :)
I have been asked to publish bug stats from time to time. Not exactly sure about the schedule yet, but I will try and stick to Fridays, as in the past; this is for the obvious reason that it makes historical data easier to compare. "Last Friday of each month" may or may not be too much. Time will tell.
The UDD bugs interface currently knows about the following release critical bugs:
- In Total:
- Affecting Jessie:
431 That's the number we need to get down to zero
before the release. They can be split in two big categories:
- Affecting Jessie and unstable:
383 Those need someone to find a fix, or to finish the
work to upload a fix to unstable:
- 44 bugs are tagged 'patch'. Please help by reviewing the patches, and (if you are a DD) by uploading them.
- 20 bugs are marked as done, but still affect unstable. This can happen due to missing builds on some architectures, for example. Help investigate!
- 319 bugs are neither tagged patch, nor marked done. Help make a first step towards resolution!
- Affecting Jessie only: 48 Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
- Affecting Jessie and unstable: 383 Those need someone to find a fix, or to finish the work to upload a fix to unstable:
- Affecting Jessie: 431 That's the number we need to get down to zero before the release. They can be split in two big categories:
Note that recent versions of git-annex have a reinit command that makes this much simpler:
git clone /existing/repo.annex git annex info # to refresh your memory about uuid or description of lost repo git annex reinit uuid|description
Another half a blog post, half a reminder for my future self.
Turns out that pulling an external 3.5" disk off of your nightstand with the help of a tangled USB cable is a surprisingly efficient way to kill a it. On the plus side, this yields instant results and complete success.
On the other hand, I kinda lost well over one TiB of personal photographs and other data which I didn't really appreciate a whole lot.
Thankfully, all data was annexed and I always maintain at least three copies of all files at all times, so the fix is as easy as getting two new disks and running
badblocks /dev/foo -swo $manufacturer-$model-$(date '+%F--%H-%M-%S-%Z').badblocks-swo # assuming you keep a git repo of this data
followed by partitioning,
mkfs etc and
cd /existing/repo.annex git annex info # not the UUID you need cd /new/disk git clone /existing/repo.annex cd repo.annex vim .git/config # add the [annex] block and _copy over the UUID of the lost repo_ git annex get # assuming you want a full copy, which I always do for data archival repos git annex sync
and done. By running
git annex get before
annex sync, I managed to avoid (potentially) saving
information about missing data; I simply made sure it was all in
place before synching again.
The second external disk allows me to always get one local disk up to speed and another one off-site. I am able to learn from experience ;)
It's nice to see that the overall tone of some key debates is slowly changing. The stance of not securing the whole stack piece by piece because some unrelated part in the stack is leaking information as well is steadily losing ground.
Another impact of this whole mess is that you can't really be certain why some parties are arguing against pervasive encryption any more. On the plus side, that makes defaulting to safety simpler.
Trusted: NO, there were errors: The certificate does not apply to the given host The certificate authority's certificate is invalid The root certificate authority's certificate is not trusted for this purpose The certificate cannot be verified for internal reasons Signature Algorithm: md5WithRSAEncryption Issuer: C=XY, ST=Snake Desert, L=Snake Town, O=Snake Oil, Ltd, OU=Certificate Authority, CN=Snake Oil CA/emailAddressemail@example.com Validity Not Before: Oct 21 18:21:51 1999 GMT Not After : Oct 20 18:21:51 2001 GMT Subject: C=XY, ST=Snake Desert, L=Snake Town, O=Snake Oil, Ltd, OU=Webserver Team, CN=www.snakeoil.dom/emailAddressfirstname.lastname@example.org ... X509v3 Subject Alternative Name: email:email@example.com
For your own pleasure:
openssl s_client -connect www.walton.com.tw:443 -showcerts
or just run
echo ' -----BEGIN CERTIFICATE----- MIIDNjCCAp+gAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz bmFrZW9pbC5kb20wHhcNOTkxMDIxMTgyMTUxWhcNMDExMDIwMTgyMTUxWjCBpzEL MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQC554Ro+VH0dJONqljPBW+C72MDNGNy9eXnzejXrczsHs3Pc92Vaat6CpIEEGue yG29xagb1o7Gj2KRgpVYcmdx6tHd2JkFW5BcFVfWXL42PV4rf9ziYon8jWsbK2aE +L6hCtcbxdbHOGZdSIWZJwc/1Vs70S/7ImW+Zds8YEFiAwIDAQABo24wbDAbBgNV HREEFDASgRB3d3dAc25ha2VvaWwuZG9tMDoGCWCGSAGG+EIBDQQtFittb2Rfc3Ns IGdlbmVyYXRlZCBjdXN0b20gc2VydmVyIGNlcnRpZmljYXRlMBEGCWCGSAGG+EIB AQQEAwIGQDANBgkqhkiG9w0BAQQFAAOBgQB6MRsYGTXUR53/nTkRDQlBdgCcnhy3 hErfmPNl/Or5jWOmuufeIXqCvM6dK7kW/KBboui4pffIKUVafLUMdARVV6BpIGMI 5LmVFK3sgwuJ01v/90hCt4kTWoT8YHbBLtQh7PzWgJoBAY7MJmjSguYCRt91sU4K s0dfWsdItkw4uQ== -----END CERTIFICATE----- ' | openssl x509 -noout -text
At least they're secure against heartbleed.
for obvious reaons I am in the process of cycling out a lot of passwords.
For the last decade or so, I have been using openssl.vim to store less-frequently-used passwords and it's still working fine. Yet, it requires some manual work, not least of which manually adding random garbage at the start of the plain text (and in other places) every time I save my passwords. In the context of changing a lot of passwords at once, this has started to become tedious. Plus, I am not sure if a tool of the complexity and feature-set of Vim is the best choice for security-critical work on encrypted files.
Long story short, I am looking for alternatives. I did some research but couldn't come up with anything I truly liked; as there's bound to be tools which fit the requirements of like-minded people, I decided to ask around a bit.
My personal short-list of requirements is:
- Strong crypto
- Must add random padding at the front of the plain text and ideally in other places as well
- Should ideally pad the stored file to a few kB so size-based attacks are foiled
- Must not allow itself to be swapped out, etc
- Must not be hosted, cloud-based, as-a-service, or otherwise compromised-by-default
- Should offer a way to search in the decrypted plain text, nano- or vi-level of comfort are fine
- Both key-value storage or just a large free-form text area would be fine with a slight preference for free-form text
Any and all feedback appreciated. Depending on the level of feedback, I may summarize my own findings and suggestions into a follow-up post.
This is half a blog post and half a reminder for my future self.
So let's say you used the following commands:
git add foo git annex add bar git annex sync # move to different location with different remotes available git add quux git annex add quuux git annex sync
what I wanted to happen was to simply sync the already
committed stuff to the other remotes. What happened instead was
git annex sync's automagic commit feature (which you
can not disable, it seems) doing its job: Commit what was added
earlier and use "git-annex automatic sync" as commit message.
This is not a problem in and as of itself, but as this is my my master annex and as I managed to maintain clean commit messages for the last few years, I felt the need to clean this mess up.
Changing old commit messages is easy:
git rebase --interactive HEAD~3
r option for "reword" and amend the two
commit messages. I did the same on my remote and all the branches I
could find with
git branch -a. Problem is, git-annex
pulls in changes from refs which are not shown as branches; run
git annex sync and back are the old commits along with
a merge commit like an ugly cherry on top. Blegh.
I decided to leave my comfort zone and ended up with the following:
# always back up before poking refs git clone --mirror repo backup git reset --hard 1234 git show-ref | grep master # for every ref returned, do: git update-ref $ref 1234
rinse repeat for every remote,
git annex sync, et
voilà. And yes, I avoided using an actual loop on purpose;
sometimes, doing things slowly and by hand just feels safer.
For good measure, I am running
git fsck && git annex fsck
on all my remotes now, but everything looks good up to now.
And today from our ever-growing collection of what the fuck is wrong with you people?!...
This is wrong on so many levels, I can't even begin to describe it. Sadly, it seems that this will get funded. And if it does not, technology will only become cheaper over time...