This was supposed to be posted on GNUstep Meetup 2015 blog, so if you are interested, click here.
Stopping Gajim from autostarting OTR end-to-end encryption
Is Gajim auto-negotiating OTR? Does that annoy you by preventing server-side message archival and message carbons being delivered to other clients you use?
- Go to Preferences (hit ctrl+p).
- Go to Advanced tab
- Under Advanced Configuration Editor click Open.
- Use search to find ‘autonegotiate_esessions’ and ‘enable_esessions’ options
- For each account, click on value ‘Activated’ to toggle it into ‘Deactivated’.
I definitely want the option to initiate crypto via GPG and OTR. I don’t want it started automatically and preventing other useful archival that I do on my self-hosted hardware.
Streaming to YouTube Live with VLC and FFMPEG
Let’s say you’re on OS X. (If you’re not, substitute the path to VLC executable with /usr/bin/vlc
or just vlc
; you could even use cvlc
).
PATHTOFILE=/Users/ivucica/my_video.mp4 STREAMID=ivucica.aaaa-bbbb-cccc-dddd VLC=/Applications/VLC.app/Contents/MacOS/VLC if [ ! -e "${VLC}" ] ; then VLC=vlc fi "${VLC}" "${PATHTOFILE}" --sout '#transcode{vcodec=FLV1,acodec=mp3,samplerate=44100}:std{access=rtmp,mux=ffmpeg{mux=flv},dst=rtmp://a.rtmp.youtube.com/live2/'${STREAMID}
I’ve seen a variant where vcodec
is h264
, acodec
is aac
and also vb
is set to 1000.
If you want to use FFMPEG instead:
./ffmpeg -re -i "${PATHTOFILE}" -vcodec libx264 -preset veryfast -maxrate 1984k -bufsize 3968k -vf "format=yuv420p" -g 60 -acodec libmp3lame -b:a 96k -ar 44100 -f flv -s 1920x1080 rtmp://a.rtmp.youtube.com/live2/${STREAMID}
Where do you get the STREAMID
from? Create a YouTube Live event in the Creator Studio, then create a ‘custom ingestion’, then read the settings:
Let’s say you haven’t been running your stream for months. I’m only guessing about what is actually happening, but the logical explanation is that something is garbage-collecting the ingestion settings without telling the UI about it. Error as follows may happen:
VLC media player 2.2.1 Terry Pratchett (Weatherwax) (revision 2.2.1-0-ga425c42) [0000000100302968] core libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. [000000010038a3f8] avcodec access out error: Failed to open rtmp://a.rtmp.youtube.com/live2/ivucica.aaaa-bbbb-cccc-dddd [0000000100389aa8] stream_out_standard stream out error: no suitable sout access module for `rtmp/ffmpeg{mux=flv}://rtmp://a.rtmp.youtube.com/live2/ivucica.aaaa-bbbb-cccc-dddd' [0000000100389838] core stream output error: stream chain failed for `transcode{vcodec=FLV1,acodec=mp3,samplerate=44100}:std{access=rtmp,mux=ffmpeg{mux=flv},dst=rtmp://a.rtmp.youtube.com/live2/ivucica.aaaa-bbbb-cccc-dddd}' [000000010050f648] core input error: cannot start stream output instance, aborting
If that is the case, go and create a new custom ingestion. Or create a whole new stream. Then use the new ID where appropriate.
n.b. As of August 2015, if you’re just playing with streaming, Ustream seems to start streaming (and thus provide useful feedback) far faster than YT Live.
Gajim causing kernel lockup on startup
Specifically, Gajim’s use of python-crypto (or something similar) has been causing the kernel to lock up for me, months ago. 100% repro rate: I would launch Gajim, and kernel would lock up on the relevant core even before Gajim showed the first window.
Trying to pinpoint it using strace
, it was actually an attempt to read /proc/brcm_monitor0
. I have no idea why it would try to read it, but once it did, kernel would lock up on one CPU core (seen by examining dmesg
), and slowly other CPU cores would follow.
Given that I don’t actually need the Broadcom wireless card on my desktop machine (at least ever since I wired up my room), I’ve just blacklisted the wl
module:
$ cat /etc/modprobe.d/blacklist-IVUCICA.conf blacklist wl
Ubiquiti mPower PRO (EU): First steps after unpacking
I’ve been happy enough with my mid-range mPower (EU edition) that I bought an mPower PRO (again, EU edition). I finally got around to unpacking it and setting it up.
mPower mini, mPower and mPower PRO are Ubiquiti Networks’ IP power outlet product. They run Linux on them. There’s web UI, and it’s also easy to SSH into the device out of the box (username is ubnt
and password is ubnt
). This makes the device easy to script for: all power use statistics and remote control are exposed as files in /proc/power
. An app for Android exists as well.
I purchased the mPower PRO simply because I needed a few more plugs to control. Difference between mPower and mPower PRO is that the latter has six instead of three plugs, and it has both WiFi and an ethernet port (all smaller models have just WiFi).
Since my previous post) was originally written in August 2014, I discovered that a newer firmware has a nicer web UI, and changing the default username and password is not really a problem anymore either. So I ended up flashing the device, then factory-resetting it. Given how nicer web UI is important to me, this means this will be the first step with my today’s setup of mPower’s “bigger brother”.
Unboxing and connecting
The box contains the device, a wall-mount and a small manual. I’m interested in just the device, of course.
First difference is that mPower PRO will not bring up a wireless network you use to set it up. Instead, you must connect it via the ethernet port. This is fine; I’m happy that I lucked out and had an extra ethernet cable lying around.
mPower PRO picked up an IP address over DHCP immediately. To find out what to punch into the browser, I just looked at my router’s DHCP leases and saw what device is outside the statically-assigned range (I hand out IP addresses based on known devices’ MAC addresses). I then added the new MAC address to the list of known ones, and assigned a new static IP to it. (By the time I am writing these lines, the original lease expired and the device already has the new IP address.)
Upgrading firmware
This mPower PRO shipped with v1.2.6 firmware, which means I have to use the manual upgrade method. So I’ve downloaded the 2.11.1 firmware and:
scp firmware.bin ubnt@198.51.100.84:/tmp/fwupdate.bin # RFC-5737 example IP range \o/ ssh ubnt@198.51.100.84 -t /sbin/syswrapper.sh upgrade2
Password is, as previously mentioned, ubnt
. This will take a while. Don’t unplug the device while it’s being flashed. After a few minutes you’ll probably get something like Write failed: Broken pipe
. This is fine.
In future, you can use web UI to flash an upgraded firmware.
Logging in and changing password
If your device is at 198.51.100.84, then just visit http://198.51.100.84/ and log in with username ubnt
and password ubnt
. You probably don’t want others to be able to log in with the same credentials, so change them as soon as feasible.
On the System tab, next to the field ‘Administrator Username’ and its value ubnt
, there should be a small icon of a key. Click on it. Then, change the administrator username, enter the old password ubnt
, then enter the new password twice. Then click the ‘Change’ button which is above the ‘Management’ section and below the ‘NTP’ section. You’ll get asked whether to apply the changes. Do apply them.
Hooray! mPower PRO is sufficiently ready for basic use. At some point I’ll go ahead and assign port names which doesn’t seem to be doable through web UI.
Thoughts on password managers
I’ve only started looking at password managers, as recently a password that I reused as a low-importance password finally got sufficiently compromised that I have to give up on it. Yes — I finally have to seriously look at password management.
I have not actually tried out most of these. I have some experience with iCloud Keychain and Chrome’s password manager and sync. These are my notes based solely on reading about the tools. Think of them as a thought-dump; something that will help me decide over the next few days what to go with.
Context
I’m a user of:
- many locations (home + work + travel)
- many platforms (GNU/Linux, OS X, Windows, Android, iOS, plus an assortment of atypical OSes, including SailfishOS, ChromeOS)
- many browsers (Chrome, Safari for battery saving, Firefox as a speedy alternative)
- many devices and device sizes (24″ desktop touchscreen at home, smartphone, tablet)
- many games with their own account systems
I require or strongly desire:
- password autogeneration
- safe bug-free synchronization
- browser integration
- …which stays inside its browser profile
- external app, especially closed source, is a no-go for work use!
- optional self-hosting
- client side crypto
- …unlocked with long password…
- …and later unlocked with a PIN
- offline access
- easily enter passwords into games
- mobile viewing of passwords (so I can manually type it into a terminal, for example)
- two-factor auth for setting up sync
- ability to back out, and switch to another solution
Being open source and free is a strong bonus, but I’m okay with using a proprietary and/or paid solution.
Examined password managers
This is not a review. I have not actually run most of the managers.
1Password
After I commented about my quest for a password manager on Twitter, two out of two people that reached back to me have surprisingly suggested this solution which seems strongly tied to Apple platforms. True, they do Windows and Android too — but, as evidenced by the order of icons on product’s website, Mac and iOS come first.
I would have always felt greatly uneasy about this (which is a strong reason why I never fully adopted iCloud Keychain), but today it’s a total no-starter.
That is, I am not going to bother even starting to try out this manager if it focuses on Apple platforms.
I am worried about the part that states that sync happens through iCloud or Dropbox (or Wi-Fi Sync). More specificially, I’m worried about what the promo page for iOS product does not state. What happens if I change password database from two devices at the same time? iCloud Core Data on Apple platforms supports merging during sync; Dropbox has datastore API. I hope these are used; I would expect them to be. Ditto for proper crypto. But the description of how to use 1Password.html to view password does not make me confident; it looks like it’s using files. It could still be doing the right thing, but… shrug
Still, if I cannot be sure I’ll be able to access my data on GNU/Linux or some of the more “obscure” platforms that I use, this is sadly a non-starter. It’s a shame, it looks like a nice product that I’d advise readers to check out.
iCloud Keychain
It’s simple, really: it’s entirely tied to Apple platforms, and to the best of my knowledge, I cannot view passwords on any other platform, much less integrate with browsers on other platforms. (Apparently it is possible to view passwords on iOS devices… but seriously, digging through Settings app?) At least Chrome uses Keychain Access on OS X, which is nice.
I’m also not too happy with the idea of having passwords in iCloud. There have been a couple of security incidents related to Apple which may or may not have happened due to users misusing the service. The ‘may not’ part is what worries me; occasionally Apple’s customer service was social-engineered, other times there were allegations of actual breaches of Apple ID authentication.
I do like the idea of syncing not just passwords, but credit card information as well, and neatly inserting it where required. If I were an Apple-only user, this would be a sufficient solution.
Google Chrome’s password sync
Chrome has its own password store which can be synced. I use this already and am mostly happy with it.
However, it’s unusable on any other browser, password generator is experimental and doesn’t seem to be manually triggerable, and accessing passwords for use in other applications is horribly hard. If I could easily get the passwords generated manually, and if I could easily find passwords (while still locking the password store after a timeout), I’d be a very happy person.
Also, given my experience with Chrome’s Bookmark Sync, where deleted bookmarks show up later, duplicated bookmarks show up later, sometimes folders are duplicated or are created as empty folders, etc, I’m highly unlikely to rely on this.
This also does not pass the self-hosted test, and partially passes the open-source test, even though I do highly trust my current employer.
LastPass
LastPass is neat. It’s a free+paid service, without a self-hosting option. But it’s neat.
It covers all major platforms that I use, and doesn’t feel like favoring any of them (there’s even a WinRT/Metro/Windows Modern application!). It has multifactor authentication. It seems to be doing its own sync protocol (so probably doesn’t lose data when merging). Its browser integration seems very powerful. There’s a command line version which is even open source. (Yes, I almost began this section of the overview by claiming this is a proprietary offering, which is true.)
They seem not to be able to see your passwords, even if the passwords are synced to their servers. CLI tool’s open source nature lets me check that — this pleases me. I also checked how the passwords are synced. Apparently, there’s an upload queue (presumably containing unsynced passwords), and the whole database seems to be optionally and as required fetched as a single blob (yes, literally blob; see also init_all()
, used sometime during startup). This also pleases me — this is almost the way I would have implemented this.
I’m strongly, strongly leaning towards using this, and using its paid tier. Especially given the strong recommendations from colleagues.
(I am mildly amused that the sync server is apparently written in PHP. I am also slightly unamused by the lack of comments in lastpass-cli
source code. )
KeePass ecosystem
This is a strong ecosystem built around KeePass’s file format, and one that strongly supports self-hosting. KeePass2Android seems to support SFTP. The ecosystem seems to value open source, as well: see KeePassX.
Strong contender, due to its opensource values. And UI of KeePass2Android seems nice. But I can’t get around the fact that its idea of syncing is — use a single file.
Surely we can do better than that to handle conflicts in 2015? I’d rather expose my files to a third party than lose passwords to file version conflicts.
But if I was not so afraid of losing data, this would seem like the tool to use.
zx2c4 pass
(PasswordStore)
After I already posted the first iteration of this post, I got a suggestion to take a look at [pass][26]
. And this one is interesting — I got it running in minutes!
Pro:
- A simple command line tool!
- Stores one password per file
- Passwords are encrypted with GPG
- Just specify your GPG ID (e.g. email address)
- Since I store my GPG private key, PIN-protected, on my YubiKey NEO (it also does U2F, which you should use as second-factor authentication), this is awesome
- Changes are optionally tracked with Git
- I dislike Git, but a VCS seems perfect for this use case
- There’s Firefox integration and there’s an Android app which seems to use OpenKeychain (hello YubiKey!)
- The “file format” does not seem to be so much a format as just a directory with a bunch of GPG-encrypted text files in it (and optionally a git repo backing it)
Con:
- The only Chrome extension I ran into is “in early alpha”
- …even worse, it says: “It is not planned to add support for managing (adding,changing,removing) passwords to passext. That’s what the pass programm is for.”
- That statement is essentially a promise for a terrible UX
- It seems strongly oriented towards UNIX systems… what will I do on Windows?
- Firefox addon still uses the standalone app
- If I lose my YubiKey, I’ll lose passwords, unless I encrypt with multiple keys.
The last one is particularly worrying.
Even though, given enough time and considering how simple the “database” “format” is, I could put together proper extensions that manage passwords using in-browser GPG and Git implementations (or at least in-browser GPG + a web service to upload files to a trusted server), I’m not sure I want to invest that time. From the looks of it, I would also lose the ability to use YubiKey; searching for yubikey gpg chrome
does not reveal any useful results, so I would assume that only native GPG can do this.
Windows being an afterthought would be less of an issue if the in-browser experience didn’t (seemingly always) depend on the native executable…
Closing thoughts and wishes
All the tools I took a quick look at seem like quality products that, at worst, may have just made an odd choice or two that make them inappropriate for a oh-my-eyes-they-hurt-look-at-the-number-of-devices-and-browsers users, or that lack a certain good feature.
Game passwords
None of the password managers seem appropriate for storing game passwords. I’m saddened by lack of confirmation that it is possible, under Android, to create a Bluetooth service that advertises Bluetooth HID profile; that is, I can’t confirm that it is possible to get an Android phone to behave like a keyboard. (Some sources imply this is actually not possible. Others seem to suggest it “just” requires root.)
If this were realistically possible, it would make sense for me to suggest this to developer of my chosen password manager, or to implement it myself (assuming source code availability): make an app that pretends to be a Bluetooth HID keyboard, lets me choose a password from the list, then “types” the password into whatever game I’m playing.
Maybe this would be a reason to start using Jolla as my third phone?
Self-hosting sync
Other than that, I’d really like an optionally-self-hosted service. One that would either:
- use a one-password-per-file approach (but still properly encrypted — this is doable, right?), or
- provide a self-hosted service with a nice CRUD API that the apps, browser extensions and CLI programs would use in the background
The first option could live on FTP, SFTP and WebDAV. If it’s properly content-addressed and append-only, you’d at worst get an outdated file. The second of those would mean less files on the filesystem, which is always nice, but would require deploying a service of some sort. (Would Camlistore be appropriate here as a backend and password store viewer? I think so.)
I definitely don’t need a “single-blob database synced to a remote filesystem” approach. That’s scary and loss-prone. Syncing is hard even if we don’t make it harder. I’m not sure I want to use something that even tries to merge two disparate single-big-blob databases, then upload the result back. (iCloud Keychain is, I expect, smarter than this; then again, it’s not a self-hosted service.)
So, choice?
I’m still making the choice LastPass and KeePass, but I’ll probably go with LastPass. Especially given the opensourced nature of the CLI tool, and how easy it is for me to validate that they’re doing the right thing with syncing passwords (at least in the CLI tool).
And when I already finished writing this post, pass
came into play. It feels better than KeePass — this is, in my world, a strong contender.