irony-install-server with MacPorts

Update: I was only able to get irony to work up to the 2019 version, but irony has been unmaintained since 2023 and has now since suffered significant bit-rot, and I could not get the 2023 version to work. There seems to be other alternatives (e.g. lsp-mode). However, I'm keeping this page for the record.

The irony server provides symbol completion for irony-mode on Emacs. Under the hood, it uses libclang to parse C and C++ source. On Mac OS, the Xcode command line tools comes with clang, but it does not provide the necessary header files. Here are the specific instructions for MacPorts.

$ cd "$(mktemp -d)"  # any empty temporary directory will do.
$ clang -v
Apple clang version 17.0.0 (clang-1700.0.13.3)
Target: x86_64-apple-darwin24.4.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
$ sudo port install cmake clang-17
--->  Computing dependencies for cmake
...
--->  Cleaning cmake
--->  Computing dependencies for clang-17
...
--->  Cleaning clang-17
--->  Scanning binaries for linking errors
--->  No broken files found.                             
--->  No broken ports found.
$ cmake \
  -DLIBCLANG_LIBRARY=/opt/local/libexec/llvm-17/lib/libclang.dylib \
  -DLIBCLANG_INCLUDE_DIR=/opt/local/libexec/llvm-17/include \
  -DCMAKE_MACOSX_RPATH=1 \
  -DCMAKE_INSTALL_RPATH=/opt/local/libexec/llvm-17/lib \
  -DCMAKE_INSTALL_PREFIX=$HOME/.emacs.d/irony/ \
  $HOME/.emacs.d/elpa/irony-20231018.1915/server &&
cmake --build . --use-stderr --config Release --target install

Some notes:

• MacPorts llvm package provides the libclang.dylib, but clang provides the header files for it (see macports #69392).
• LIBCLANG_LIBRARY has to point to the dylib (or the .so on Linux), not the lib/ directory.
• irony-20231018.1915 has a bug where irony.el version string is now ";; Package-Version: 20231018.1915", but the server/src/CMakeLists.txt still uses ";; Version:" to detect the version. Update the string accordingly.
• Requires cl-libify to patch cl to cl-lib. Install it in emacs using M-x package-install cl-libify.

How to restart emulationstation on RetroPie over SSH

tl;dr: over ssh, run:

sudo systemctl restart autologin@tty1.service

You are probably looking for how to restart emulationstation on RetroPie, after running killall emulationstation in the first place. And you probably did everything over ssh so far.

After booting up, RetroPie starts emulationstation automatically using systemd autologin as the "pi" user, on the console terminal /dev/tty1. If you use a physical keyboard, you can switch to this console by pressing Alt-2, whereas the boot messages are in Alt-1.

The autologin actually starts a regular bash login shell, which runs /etc/profile, which bootstraps /etc/profile.d/10-retropie.sh. In that latter script, it checks the terminal is /dev/tty1, and only starts emulationstation if the terminal matches. If you quit emulation station from the console, it will drop back to the bash login shell, and if you exit from the bash shell, the autologin sequence starts over and runs emulationstation again. Note that the autologin sequence is not managed by systemd-logind, so it will not show when running the loginctl command.

Every time you login to ssh, the same /etc/profile.d/10-retropie.sh script runs, but since the terminal is not /dev/tty1, the script does nothing.

Now I wish to air some grievances. When googling how to do this (I figured someone must have figured this out before I did), I came across some misguided but well-intentioned answers (e.g. RetroPie forum, Reddit), but nothing is as egregious as this one in the Raspberry Pi forum. This poor chap asked a question, received some unhelpful responses from the moderator, and understandably became frustrated. Now this power-tripping moderator Jessie went all indignant, banned the user, locked the topic, and proclaimed "let other users take note here."

Even though I have nothing to do with that conversation, reading the thread made my blood boil. This Jessie character is exactly the repellant that Raspberry Pi needs to alienate more of its users. I am not impressed. I would not be surprised if there are other incidents of abuse by this moderator, and would recommend that he steps down if he had not done so already.

Crypto Ecosystem

The crypto stack is complicated. There are many APIs and implementations of the same API. There are different ways the components could be configured to interact with each other. Here is my attempt at visualizing the various relationships of the crypto ecosystem.

Here is the original drawing.

The depicted components:

• Applications: Chrome, Firefox, GnuPG, Keychain Access, OpenSSH.
• APIs and protocols: CCID, PC/SC, PKCS#11.
• Smart card drivers: CryptoTokenKit, OpenSC, *.tokend.
• Hardware: PKCS#15 card, OpenPGP card.

Yubikey NEO-n

Just got my Yubikey NEO-n today and here is how I got it to work.

• Downloaded Yubikey Manager (optionally, also Yubikey Personalization Tools).
• I changed the connection mode to OTP+U2F+CCID.
• Yubikey Personalization Tools only work if OTP mode is enabled. If not:
• Both ykpersonalize, ykinfo report "no yubikey present"
• Yubikey Manager can only enumerate CCID apps if:
• No other programs are using PC/SC (e.g. gpg-agent).
• ifdhandler has to be loaded (which may not be the case if the workaround below is applied for gpg-agent getting stuck).
• The key already has OpenPGP app installed among others.
• Followed the instruction in My Perfect GnuPG/SSH agent setup.
• For Mac OS X, I downloaded GPGTools which came with the gpg command line and the gpg-agent.
• If the 'generate' command doesn't ask for "Please specify how long the key should be valid" it might be that gpg-agent got stuck. Run killall -KILL gpg-agent and try the gpg command again.
• Mac OS X Yosemite ships with a really buggy pcsc-lite implementation. Here is a workaround so that gpg-agent would not get stuck again.
• sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.ifdreader.plist
• I added -w to make the unload persist across reboots.
• After this, scdaemon will use its own CCID driver to talk to Yubikey. Both OTP and U2F will still work since neither are interfaced through PC/SC.
• Yubikey Manager will suffer reduced functionality since it no longer has CCID access:
• It can no longer enumerate Available apps.
• If OTP and U2F are both disabled, it will report "No device found" even if CCID is enabled.
• Use launchctl load -w to re-enable.

Currently I'm using Yubikey NEO-n with OpenPGP key for SSH login. Although the OpenPGP key is protected by a PIN, I only need to enter it once, and the key remains unlocked until I remove the NEO-n from USB. The problem is that while the key is unlocked, any malicious program I run could then gain access to my gpg-agent and impersonate me, which is not very secure.

With U2F, a touch would be required before authenticating with a server, which makes impersonation more difficult. A remote attacker would have to convince me to touch the Yubikey physically. There is a patch in progress making U2F work with SSH directly, but it hasn't been accepted upstream.

Cross-Site Request Forgery Prevention

Cross-site request forgery (CSRF or XSRF) happens when an attacker embeds a tag like <img src="http://snafu.com/cgi-bin/delete_account?confirm=yes"> in a malicious web page on attacker.com. When user visits the page, authentication cookies are sent to snafu.com despite the page origin. Forms that POST to snafu.com can be embedded in a malicious page as well. "Referer" can be forged if snafu.com redirects to canonicalize URL.

One solution to prevent the attack is to both: (1) use an unguessable secret cookie rotated regularly, and (2) require the same secret to appear in the POST request as a hidden form field.

If the secret appears in the URL, and if the attacker may embed content in snafu.com, then when snafu.com loads a page on attacker.com, the "Referer" header would reveal the secret.

Source: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

Build Notes of v8 Command Line Shell

The instructions on StackOverflow is a bit outdated. You don't need scons anymore. You don't even need to download GYP in advance.

# Takes about 123MB disk space.
git clone https://chromium.googlesource.com/external/v8
cd v8
# master branch of this repo is the stable edge so it's safe to use.
nice make builddeps && nice make -j4 native
cp out/native/shell ~/where/you/want/it/to/go/shell

The build artifact based on samples/shell.cc is in out/native/shell. There is no need to compile it separately. The resulting shell doesn't have any of the usual browser intrinsics such as window or document (obviously this is not a browser JavaScript). But you can print() to the standard output, read() the contents of a file, load() a JavaScript file and execute it, quit() the interpreter, and obtain its version(). This is quite enough for many "pure" programs that do mostly computations and not a lot of I/O.

Or just use node.js. The command line interpreter \( \texttt{node} \) comes with a suite of system I/O functions you could use out of the box. It doesn't have to run a web server.