Episode 270: Ghostly Releases | BSD Now 270 - a podcast by Allan Jude

from 2018-11-01T07:00

:: ::

OpenBSD 6.4 released, GhostBSD RC2 released, MeetBSD - the ultimate hallway track, DragonflyBSD desktop on a Thinkpad, Porting keybase to NetBSD, OpenSSH 7.9, and draft-ietf-6man-ipv6only-flag in FreeBSD.

##Headlines
OpenBSD 6.4 released

###GhostBSD 18.10 RC2 Announced

This second release candidate of GhostBSD 18.10 is the second official release of GhostBSD with TrueOS under the hood. The official desktop of GhostBSD is MATE. However, in the future, there might be an XFCE community release, but for now, there is no community release yet.

  • What has changed since RC1

  • Removed drm-stable-kmod and we will let users installed the propper drm-*-kmod

  • Douglas Joachin added libva-intel-driver libva-vdpau-driver to supports accelerated some video driver for Intel

  • Issues that got fixed

  • Bug #70 Cannot run Octopi, missing libgksu error.

  • Bug #71 LibreOffice doesn’t start because of missing libcurl.so.4

  • Bug #72 libarchive is a missing dependency

Again thanks to iXsystems, TrueOS, Joe Maloney, Kris Moore, Ken Moore, Martin Wilke, Neville Goddard, Vester “Vic” Thacker, Douglas Joachim, Alex Lyakhov, Yetkin Degirmenci and many more who helped to make the transition from FreeBSD to TrueOS smoother.

###OpenSSH 7.9 has been released and it has support for OpenSSL 1.1

Changes since OpenSSH 7.8
This is primarily a bugfix release.New Features
ssh(1), sshd(8): allow most port numbers to be specified usingservice names from getservbyname(3) (typically /etc/services).
ssh(1): allow the IdentityAgent configuration directive to acceptenvironment variable names. This supports the use of multiple
agent sockets without needing to use fixed paths.sshd(8): support signalling sessions via the SSH protocol.
A limited subset of signals is supported and only for login orcommand sessions (i.e. not subsystems) that were not subject to
a forced command via authorizedkeys or sshdconfig. bz#1424ssh(1): support"ssh -Q sig" to list supported signature options.
Also"ssh -Q help" to show the full set of supported queries.
ssh(1), sshd(8): add a CASignatureAlgorithms option for theclient and server configs to allow control over which signature
formats are allowed for CAs to sign certificates. For example,this allows banning CAs that sign certificates using the RSA-SHA1
signature algorithm.sshd(8), ssh-keygen(1): allow key revocation lists (KRLs) to
revoke keys specified by SHA256 hash.ssh-keygen(1): allow creation of key revocation lists directly
from base64-encoded SHA256 fingerprints. This supports revokingkeys using only the information contained in sshd(8)
authentication log messages.Bugfixes
ssh(1), ssh-keygen(1): avoid spurious"invalid format" errors when
attempting to load PEM private keys while using an incorrectpassphrase. bz#2901
sshd(8): when a channel closed message is received from a client,close the stderr file descriptor at the same time stdout is
closed. This avoids stuck processes if they were waiting forstderr to close and were insensitive to stdin/out closing. bz#2863
ssh(1): allow ForwardX11Timeout=0 to disable the untrusted X11forwarding timeout and support X11 forwarding indefinitely.
Previously the behaviour of ForwardX11Timeout=0 was undefined.sshd(8): when compiled with GSSAPI support, cache supported method
OIDs regardless of whether GSSAPI authentication is enabled in themain section of sshd_config. This avoids sandbox violations if
GSSAPI authentication was later enabled in a Match block. bz#2107sshd(8): do not fail closed when configured with a text key
revocation list that contains a too-short key. bz#2897ssh(1): treat connections with ProxyJump specified the same as
ones with a ProxyCommand set with regards to hostnamecanonicalisation (i.e. don't try to canonicalise the hostname
unless CanonicalizeHostname is set to 'always'). bz#2896ssh(1): fix regression in OpenSSH 7.8 that could prevent public-
key authentication using certificates hosted in a ssh-agent(1)or against sshd(8) from OpenSSH<7.8.
PortabilityAll: support building against the openssl-1.1 API (releases 1.1.0g
and later). The openssl-1.0 API will remain supported at leastuntil OpenSSL terminates security patch support for that API version.
sshd(8): allow the futex(2) syscall in the Linux seccomp sandbox;apparently required by some glibc/OpenSSL combinations.
sshd(8): handle getgrouplist(3) returning more thanSCNGROUPSMAX groups. Some platforms consider this limit more
as a guideline.

##News Roundup

###MeetBSD 2018: The Ultimate Hallway Track

Founded in Poland in 2007 and first hosted in California in 2008, MeetBSD combines formal talks with UnConference activities to provide a level of interactivity not found at any other BSD conference. The character of each MeetBSD is determined largely by its venue, ranging from Hacker Dojo in 2010 to Intel’s Santa Clara headquarters this year. The Intel SC12 building provided a beautiful auditorium and sponsors’ room, plus a cafeteria for the Friday night social event and the Saturday night FreeBSD 25th Anniversary Celebration. The formal nature of the auditorium motivated the formation of MeetBSD’s first independent Program Committee and public Call for Participation. Together these resulted in a backbone of talks presented by speakers from the USA, Canada, and Poland, combined with UnConference activities tailored to the space.

  • MeetBSD Day 0

Day Zero of MeetBSD was a FreeBSD Developer/Vendor Summit hosted in the same auditorium where the talks would take place. Like the conference itself, this event featured a mix of scheduled talks and interactive sessions. The scheduled talks were LWPMFS: LightWeight Persistent Memory Filesystem by Ravi Pokala, Evaluating GIT for FreeBSD by Ed Maste, and NUMA by Mark Johnston. Ed’s overview of the advantages and disadvantages of using Git for FreeBSD development was of the most interest to users and developers, and the discussion continued into the following two days.

  • MeetBSD Day 1

The first official day of MeetBSD 2018 was kicked off with introductions led by emcee JT Pennington and a keynote, “Using TrueOS to boot-strap your FreeBSD-based project” by Kris Moore. Kris described a new JSON-based release infrastructure that he has exercised with FreeBSD, TrueOS, and FreeNAS. Kris’ talk was followed by “Intel& FreeBSD: Better Together” by Ben Widawsky, the FreeBSD program lead at Intel, who gave an overview of Intel’s past and current efforts supporting FreeBSD. Next came lunch, followed by Kamil Rytarowski’s “Bug detecting software in the NetBSD userland: MKSANITIZER”. This was followed by 5-Minute Lightning Talks, Andrew Fengler’s “FreeBSD: What to (Not) Monitor”, and an OpenZFS Panel Discussion featuring OpenZFS experts Michael W. Lucas, Allan Jude, Alexander Motin, Pawel Dawidek, and Dan Langille. Day one concluded with a social event at the Intel cafeteria where the discussions continued into the night.

  • MeetBSD Day 2

Day Two of MeetBSD 2018 kicked off with a keynote by Michael W. Lucas entitled “Why BSD?”, where Michael detailed what makes the BSD community different and why it attracts us all. This was followed by Dr. Kirk McKusick’s “The Early Days of BSD” talk, which was followed by “DTrace/dwatch in Production” by Devin Teske. After lunch, we enjoyed “A Curmudgeon’s Language Selection Criteria: Why I Don’t Write Everything in Go, Rust, Elixir, etc” by G. Clifford Williams and, “Best practices of sandboxing applications with Capsicum” by Mariusz Zaborski. I then hosted a Virtualization Panel Discussion that featured eight developers from FreeBSD, OpenBSD, and NetBSD. We then split up for Breakout Sessions and the one on Bloomberg’s controversial article on backdoored Supermicro systems was fascinating given the experts present, all of whom were skeptical of the feasibility of the attack. The day wrapped up with a final talk, “Tales of a Daemontown Performance Peddler: Why ‘it depends’ and what you can do about it” by Nick Principe, followed by the FreeBSD 25th Anniversary Celebration.

  • Putting the “meet” in MeetBSD

I confess the other organizers and I were nervous about how well one large auditorium would suit a BSD event but the flexible personal space it gave everyone allowed for countless meetings and heated hacking that often brought about immediate results. I watched people take ideas through several iterations with the help and input of obvious and unexpected experts, all of whom were within reach. Not having to pick up and leave for a talk in another room organically resulted in essentially a series of mini hackathons that none of us anticipated but were delighted to witness, taking the “hallway track” to a whole new level. The mix of formal and UnConference activities at MeetBSD is certain to evolve. Thank you to everyone who participated with questions, Lightning Talks, and Panel participation. A huge thanks to our sponsors, including Intel for both hosting and sponsoring MeetBSD California 2018, Western Digital, Supermicro, Verisign, Jupiter Broadcasting, the FreeBSD Foundation, Bank of America Merrill Lynch, the NetBSD Foundation, and the team at iXsystems.

See you at MeetBSD 2020!

###Setup DragonflyBSD with a desktop on real hardware ThinkPad T410
+Video Demo

Linux has become too mainstream and standard BSD is a common thing now? How about DragonflyBSD which was created as a fork of FreeBSD 4.8 in conflict over system internals. This tutorial will show how to install it and set up a user-oriented desktop. It should work with DragonflyBSD, FreeBSD and probably all BSDs.
Some background: BSD was is ultimately derived from UNIX back in the days. It is not Linux even though it is similar in many ways because Linux was designed to follow UNIX principles. Seeing is believing, so check out the video of the install!
I did try two BSD distros before called GhostBSD and TrueOS and you can check out my short reviews. DragonflyBSD comes like FreeBSD bare bones and requires some work to get a desktop running.

  • Download image file and burn to USB drive or DVD

  • First installation

  • Setting up the system and installing a desktop

  • Inside the desktop

  • Install some more programs

  • How to enable sound?

  • Let’s play some free games

  • Setup WiFi

  • Power mode settings

  • More to do?

You can check out this blog post if you want a much more detailed tutorial. If you don’t mind standard BSD, get the GhostBSD distro instead which comes with a ready-made desktop xcfe or mate and many functional presets.

  • A small summary of what we got on the upside:

    • Free and open source operating system with a long history
    • Drivers worked fine including Ethernet, WiFi, video 2D& 3D, audio, etc
    • Hammer2 advanced file system
    • You are very unique if you use this OS fork

  • Some downsides:

  • Less driver and direct app support than Linux

  • Installer and desktop have some traps and quirks and require work

###Porting Keybase to NetBSD

Keybase significantly simplifies the whole keypair/PGP thing and makes what is usually a confusing, difficult experience actually rather pleasant. At its heart is an open-source command line utility that does all of the heavy cryptographic lifting. But it’s also hooked up to the network of all other Keybase users, so you don’t have to work very hard to maintain big keychains. Pretty cool!
So, this evening, I tried to get it to all work on NetBSD.
The Keybase client code base is, in my opinion, not very well architected… there exist many different Keybase clients (command line apps, desktop apps, mobile apps) and for some reason the code for all of them are seemingly in this single repository, without even using Git submodules. Not sure what that’s about.
Anyway, “go build”-ing the command line program (it’s written in Go) failed immediately because there’s some platform-specific code that just does not seem to recognize that NetBSD exists (but they do for FreeBSD and OpenBSD). Looks like the Keybase developers maintain a Golang wrapper around struct proc, which of course is different from OS to OS. So I literally just copypasted the OpenBSD wrapper, renamed it to “NetBSD”, and the build basically succeeded from there! This is of course super janky and untrustworthy, but it seems to Mostly Just Work…
I forked the GitHub repo, you can see the diff on top of keybase 2.7.3 here: bccaaf3096a
Eventually I ended up with a ~/go/bin/keybase which launches just fine. Meaning, I can main() okay. But the moment you try to do anything interesting, it looks super scary:

charlotte@sakuracity:~/go/bin ./keybase login
▶ WARNING Running in devel mode▶ INFO Forking background server with pid=12932
▶ ERROR unexpected error in Login: API network error:doRetry failed,
attempts: 1, timeout 5s, last err: Gethttp://localhost:3000//api/1.0/merkle/path.json?last=3784314&loaddeleted=1&loadresetchain=1&poll=10&sighints_low=3&uid=38ae1dfa49cd6831ea2fdade5c5d0519:
dial tcp [::1]:3000: connect: connection refused

There’s a few things about this error message that stuck out to me:

  • Forking a background server? What?
  • It’s trying to connect to localhost? That must be the server that doesn’t work …

Unfortunately, this nonfunctional “background server” sticks around even when a command as simple as ‘login’ command just failed:

charlotte@sakuracity:~/go/bin ps 12932
PID TTY STAT    TIME COMMAND12932 ?   Ssl  0:00.21 ./keybase --debug --log-file
/home/charlotte/.cache/keybase.devel/keybase.service.log service --chdir/home/charlotte/.config/keybase.devel --auto-forked

I’m not exactly sure what the intended purpose of the “background server” even is, but fortunately we can kill it and even tell the keybase command to not even spawn one:

charlotte@sakuracity:~/go/bin ./keybase help advanced | grep -- --standalone
--standalone                         Use the client without any daemon support.

And then we can fix wanting to connect to localhost by specifying an expected Keybase API server – how about the one hosted athttps://keybase.io?

charlotte@sakuracity:~/go/bin ./keybase help advanced | grep -- --server
--server, -s                         Specify server API.

Basically, what I’m trying to say is that if you specify both of these options, the keybase command does what I expect on NetBSD:

charlotte@sakuracity:~/go/bin ./keybase --standalone -s https://keybase.io login
▶ WARNING Running in devel modePlease enter the Keybase passphrase for dressupgeekout (6+ characters): 
charlotte@sakuracity:~/go/bin ./keybase --standalone -s https://keybase.io id dressupgeekout▶ WARNING Running in devel mode
▶ INFO Identifying dressupgeekout✔ public key fingerprint: 7873 DA50 A786 9A3F 1662 3A17 20BD 8739 E82C 7F2F
✔"dressupgeekout" on github:
https://gist.github.com/0471c7918d254425835bf5e1b4bcda00 [cached 2018-10-1120:55:21 PDT]
✔"dressupgeekout" on reddit:
https://www.reddit.com/r/KeybaseProofs/comments/9ng5qm/mykeybaseproof_redditdressupgeekout/[cached 2018-10-11 20:55:21 PDT]

###Initial implementation of draft-ietf-6man-ipv6only-flag

This change defines the RA"6" (IPv6-Only) flag which routers
may advertise, kernel logic to check if all routers on a linkhave the flag set and accordingly update a per-interface flag.
If all routers agree that it is an IPv6-only link, etheroutputframe(),based on the interface flag, will filter out all ETHERTYPE_IP/ARP
frames, drop them, and return EAFNOSUPPORT to upper layers.The change also updates ndp to show the"6" flag, ifconfig to
display the IPV6_ONLY nd6 flag if set, and rtadvd to allowannouncing the flag.
Further changes to tcpdump (contrib code) are availble and willbe upstreamed.
Tested the code (slightly earlier version) with 2 FreeBSDIPv6 routers, a FreeBSD laptop on ethernet as well as wifi,
and with Win10 and OSX clients (which did not fall over withthe"6" flag set but not understood).
We may also want to (a) implement and RX filter, and (b) overtime enahnce user space to, say, stop dhclient from running
when the interface flag is set.  Also we might want to startIPv6 before IPv4 in the future.
All the code is hidden under the EXPERIMENTAL option and notcompiled by default as the draft is a work-in-progress and
we cannot rely on the fact that IANA will assign the bitsas requested by the draft and hence they may change.
Dear 6man, you have running code.Discussed with: Bob Hinden, Brian E Carpenter

##Beastie Bits

##Feedback/Questions

  • Send questions, comments, show ideas/topics, or stories you want mentioned on the show tofeedback@bsdnow.tv

Further episodes of BSD Now

Further podcasts by Allan Jude

Website of Allan Jude