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/emailAddressfirstname.lastname@example.org 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/emailAddressemail@example.com ... X509v3 Subject Alternative Name: email:firstname.lastname@example.org
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...
The state from back then is still the current state on up-to-date Debian unstable:
- Microphone button does nothing.
- USB 3.0 docking station's display does not work thanks to the content mafiaa with an admittedly small petition trying to fix this. Obviously it is going to be ignored.
- No one using Debian seems to care about the fingerprint reader.
- UMTS/WWAN modem works fine on Windows, but Linux loses connection to the USB device all the time. As a result, UMTS does not work
The last item has the most impact on me. The need to tether when you have a dedicated SIM card, built-in modem, and good antennas in your laptop is... infuriating. Especially as it's working as intended on Windows.
As an added benefit, even though I saved the PIN in network manager, it asks me for the PIN every time I log in and every time after hibernating. For a device which I can't use in the first place. Argh!
In February, Linux Magazine contacted me, asking if I would be willing to accept the Linux New Media Award 2014 in the main category "Outstanding Contribution to Open Source/Linux/Free Software" on behalf of the Git community due to my involvement with evangelizing and vcsh. Needless to say, I was thrilled.
I managed to poke Junio via someone at
Google and he agreed. We also reached out within the German Git
community and two maintainers of
git submodule, Jens
Lehmann and Heiko Voigt, joined in as well. While we didn't manage
to hammer out interoperability issues of
git submodule due to time constraints and too much
beer, we are planning to follow up on that.
Git beat OpenStack, Python, and Ubuntu by a huge margin; sadly I don't have exact numbers (yet).
More details and a rather crummy photo can be found in Linux Magazine's article. A video of the whole thing will uploaded to this page soonish. If it appears that we kept our "speech" very short, that was deliberate after the somewhat prolonged speeches beforehand ;)
The aftershow event was nice even though the DJ refused to turn
down the music down to tolerable levels; his reaction to people
moving father away, and asking him to turn down the volume a bit,
was to turn it up... Anyway, given the mix of people present during
the award ceremony, very interesting discussions ensued. While I
failed to convert Klaus Knopper to
git, at least there's a chance
Schuhmacher will start using
maybe even push for a separation of
configuration and state in KDE.
The most interesting tidbits of the evening were shared by Abhisek Devkota of cyanogenmod fame. Without spilling any secrets it's safe to say that the future of cyanogenmod is looking extremely bright and that there are surprises in the works which will have quite the impact.
Last but not least, here's the physical prize:
There's a German joke about Germans:
Q: How can you find Germans abroad? A: You stand outside a bakery and wait until someone starts cussing.
I am constantly reminded of this joke, abroad and back home, as we do tend to take our bread seriously...
As an additional data point supporting this, the German local team just spent 20 minutes discussing bread. I somehow doubt you could make an off-hand comment about bread and garner much interest in most communities; in a German one, this works.
In mildly related news, this is what bits.debian.org will pick up soon:
During the DebConf committee meeting, it has been decided that the 16th annual Debian Conference, DebConf15, will be held in Germany next year.
Thanks to the Belgian and Swedish teams; we are looking forward to their renewed bids for future DebConfs!
Specifics as to location and date are still being nailed down and we will keep Debian as a whole informed about our progress.
A dedicated (English-language) mailing list has been created for the organization and we welcome interested people to subscribe and join the discussion.
Here's to a happy, successful, and overall quite awesome DebConf15 in Germany.
Details to follow :)
while there seem to be good GUI tools to enable facial recognition with FLOSS, they all fall short of my requirements. And while there seem to be a lot of research projects with open code, they seem to be lacking in the "usable in real life" department.
It seems as if there should be something to scratch that itch, but I couldn't find it...
Thus, my wishlist for facial recognition software
- MUST NOT send any data to any third parties!
- Must run on Linux
- GUI and CLI are both fine as long as the rest of the specs are met, but good CLI-integration would be a huge plus
- Should offer batch-verification of detected faces like so
- Must not rely on duplicating files in its own data structure/DB/directory; symlinks are fine
- Should cope with source files disappearing
- Should be able to list/diff files which are new or not yet tagged
- Must not require being able to write to any picture files
- Must be able to store data outside of the original pictures
- Should not modify the source directories without being told to; temp files, face DB, and similar should all be located in a place I decide upon
- Should offer batch-processing
- Must be able to trigger a command or script for all verified identifications i.e. the ones I manually set to matching the person; alternatively, at least be able to export data in a way I can build scripts upon
- Should be able to cope with faces changing over time, people growing older, getting a beard, etc
- Should be FLOSS if at all possible
- MUST NOT send any data to any third parties!
- I consider tags to be permanent, the DB for the program should ideally be ephemeral but I am aware that this may not be possible
- If the DB needs to be retained, it should ideally be in a merge-friendly text format not binary but that may be asking too much ;)
- MUST NOT send any data to any third parties!
I will gladly follow up with a workflow blog post assuming I end up with useful feedback.
Qouth Rogério Brito:
Russ, thank you for your exemplary role.
And that's all that was left to say.