Bear's Feed

New year means new keys

The only New Years resolution I've ever made and follow each year is this - rotate your keys!

In the security realm long-lived keys are a bane - it allows any unknown comprimise to persist over time. In a perfect world we would be able to have keys with very very short lifespans, but unless that is very automated it can become a chore - and any security practice that is onorous will become one that is skipped.

Instead what I do for most of my keys is rotate them yearly, the exception to my rule is my Ops related keys, those are rotated much much more often than yearly. I'm talking about things like personal servers and the like as the holiday break is a good time for these types of personal infra cleanups.

My process for rotation involves a research step and then the implementation step.

First I take a few minutes to review the best practices to see if anything new has changed and my goto place for that is the Mozilla InfoSec wiki. Which is where I double check my nginx config but also my sshd config.

Once I have those notes I rename/move all of my current keys to "backup" names and then generate new keys for GitHub, personal servers and my local Git server. Having the old keys around in backup form allows me to still be able to get into the servers that I invariably forget I needed (or had) access to, not to mention that you do need the old key long enough to update a server to the new one ;)

ssh-keygen -t ed25519 -f ~/.ssh/name_of_new_key

That's it - nothing fancy or complicated, just a good simple process to help make things less easy for hackers.

A good writeup on what the latest SSH keytypes are and their adoption: https://chealion.ca/2016/06/20/ssh-key-types-and-cryptography-the-short-notes/

My 2017 IndieWeb Commitment

Each year some of the IndieWeb folk make a commitment to launch a new feature or item on their personal sites by the start of the new year, here is the current 2017 list.

My list this year will be to close the loop for posts-replies by implementing a simple Twitter feed page where I can view my Twitter feed and then POSSE replies or new posts.

This will need me to do:

  • Create a python-twitter agent that gathers the twitter feed and generates a Kaku event
  • Create a template for the twitter posts that allow for replies to be created for a Twitter post
  • Create a new post event in kaku that allows for POSSE

The good thing is that most of this may be implementable using the micropub endpoint work I was working on earlier!

time to get coding!

Kaku now supports Micropub via JSON

I was in need of some serious distracting today and I also wanted to get my Micropub handling within Kaku cleaned up and further tested because I just know that Aaron will soon have Micropub Rocks! active soon.

So yea, after about 6 hrs of refactoring and thinking and testing... Kaku now supports:

  • Micropub CREATE using old-school params
  • Micropub CREATE using JSON
  • Micropub UPDATE (replace) using JSON for content

Soon I'll have UPDATE (replace) working with other fields and also UPDATE (add|delete).

Also need to look into DELETE now - gotta go read the specs...

Thoughts on what is normal

Thoughts on what is normal

I'm back from a week in West Virginia which started as a visit to see how my dad was doing after his recent heart attack and then quickly turned into what Carolyn, the lovely lady who was taking care of him, calls an "adult panties" event. His health quickly declined and we decided that Hospice care was required and then two days later he passed in his sleep.

I'm wanting to do a proper post about my dad soon, to be honest I'm still dealing with all of the "adult panties" required activities that being the executor of his will requires -- also I'm just not handling it well so i'm not handling it at all :/

Normal used to be me watching multiple online feeds and streams, clucking and shaking my head at the silliness and absurdity of how folks act, and working on keeping my small part of the internets sane and comfortable for others.

In the part of West Virginia where my dad retired you are lucky to get cell coverage at all. My carrier plan had me roaming so data coverage was not found. My dad also didn't need or want wireless so his fast internet-via-cable was useless.

This meant that I spent my week away from tech and the subsequent turmoil and/or drama -- something which I (re)discovered was very calming ... except for what I was having to do :/

I'm extremely grateful for the family that adopted my dad and then myself and my brother as they were so warm and thoughtful and caring the entire time, hugs and pokes to Carolyn, Brad, Jennifer, Sam, Jesse and Jessica.

I'm already missing them mightily and we are all missing my dad terribly.

I'm glad I was able to be there for his birthday and give him a big hug and say that I loved him.

Thoughts on a distributed Indieweb chat

The other night while talking to some of the Indieweb community I had one of those aha! moments you think only happen in movies :)

I was describing how I use XMPP to have a lot of different streams of data flow to a terminal client that I pretty much use as a dashboard - different bots and agents listen to Twitter feeds, poll the few atom feeds I still follow and other sources of notifications and then they are sent to different Multi-User-Chat (MUC) rooms on my XMPP server (Prosody) based on filters.

This type of setup is something i've been working on for decades and i've always had a few different iterations going as I learn about new tech or even new languages: the first version of it was in Perl and now most of it is in Python. I have tried to envision what this would require before but always got bogged down in the translations required to move messages from one service (silo) to another.

Then it struck me that we could now use some of the core Indieweb protocols to enable a distributed chat environment that doesn't (necessarily) require a central server or hub.

Now I'm wondering if we couldn't use simple text with some HTML+MF2 for the required metadata - this would allow a lot of the things that we in the Indieweb community have been working to be used to handle the publication (micropub, syndicate-to), notification (webmention, PuSH) and consumption (h-feed)!

Encouraged by Tantek I captured on the Indieweb Wiki most of the brainstorming from that night and I started to work getting my own site to syndicate notes to a prototype distribution hub that will allow me to see if it's realistic to have many people syndicate their own chat messages to a topic and then enable consumption of that topic in a way that feels like a chat room.

Pretty cool stuff!