1. Introduce a mechanism to tag memory containing secrets, and only restrict accesses to this. I've tried to do something similar for userland and it turns out to be hard, but this is probably the best long-term solution.
   
2. Add support for privileged applications with an appropriate signature that implement policy on the userland side. This is actually possible already, though not straightforward. Lockdown is implemented in the LSM layer, which means the policy can be imposed using any other existing LSM. As an example, we could use SELinux to impose the confidentiality restrictions on most processes but permit processes with a specific SELinux context to use them, and then use EVM to ensure that any process running in that context has a legitimate signature. This is quite a few hoops for a general purpose distribution to jump through.
   
3. Don't use confidentiality mode in general purpose distributions. The attacks it protects against are mostly against special-purpose use cases, and they can enable it themselves.

XKBLAYOUT="us"
XKBVARIANT="altgr-intl"

setxkbmap -print -verbose 10

dconf write /org/gnome/desktop/input-sources/sources "[('xkb', 'us+altgr-intl')]"

• Find all *.json files, and validate them.
• Find all *.yaml files, and validate them.
• Run all the tests in a given directory, execute them one by one.
  • But stop if any single test failed.
  • run-parts does this on Debian GNU/Linux systems, but on CentOS there is no -exit-on-error flag.
  • Which is the sole reason I had to re-implement that tool. Sigh.
• Parse PHP-files and look for comments that were bogus.
  • I mentioned this in the past.

• https://github.com/skx/sysbox/

sysbox validate-yaml [path/to/find/files/beneath]

Why Mumble rocks Before I go on with the UI critique, I should show why care: Mumble is awesome. When you do manage to configure it correctly, Mumble just works; it's highly reliable. It uses little CPU, both on the client and the server side, and can have rooms with tens if not hundreds of participants. The server can be easily installed and configured: there's a Debian package and resource requirements are minimal. It's basically network-bound. There are at least three server implementations, the official one called Murmur, the minimalist umurmur and Grumble, a Go rewrite. It has great quality: echo canceling, when correctly configured, is solid and latency is minimal. It has "overlays" so you can use it while gaming or demo'ing in full screen while still having an idea of who's talking. It also supports positional audio for gaming that integrates with popular games like Counterstrike or Half-Life. It's moderately secure: it doesn't support end-to-end encryption, but client/server communication is encrypted with TLS. It supports a server password and some moderation mechanisms.

UI improvements Mumble should be smarter about a bunch of things. Having all those settings is nice for geeky control freaks, but it makes the configuration absolutely unusable for most people. Hide most settings by default, and make better defaults. Specifically, those should be on by default:

• RNNoise
• echo cancellation (the proper "monitor" channels)
• pre-configured shortcut for PTT (Push To Talk) -- right-shift is my favorite
• "double-PTT" to hold it enabled
• be more silent by default (I understand why it would want to do voice synthesis, but it would need to be much better at it before it's default)

The echo test should be more accessible, one or two clicks away from the main UI. I have only found out about that feature when someone told me where to find it. This basically means to take it out of the settings page and into its own dialog. The basic UI should be much simpler. It could look something like Jitsi: just one giant mute button with a list of speakers. Basically:

1. Take that status bar and make it use the entire space of the main window
2. Push the chat and room list dialog to separate, optional dialog (e.g. the room list could be a popup on login, but we don't need to continuously see the damn thing)
3. Show the name of the person talking in the main UI, along with other speakers (Big Blue Button does this well: just a label that fades away with time after a person talks)

Some features could be better explained. For example, the "overlay" feature makes no sense at all for most users. It only makes sense when you're a gamer and use Mumble alongside another full-screen program, to show you who's talking. Improved authentication. The current authentication systems in Mumble are somewhat limited: the server can have a shared password to get access to it, and from there it's pretty much free-for-all. There are client certificates but those are hard to understand and the most common usage scenario is that someone manages to configure it once, forgets about it and then cannot login again with the same username. It should be easier to get the audio right. Now, to be fair, this is hard to do in any setup, and Mumble is only a part of this. There are way too many moving parts in Linux for this to be easy: between your hardware, ALSA drivers, Pulseaudio mixers and Mumble, too many things can go wrong. So this is a general problem when doing multimedia in general, and the Linux ecosystem in particular, but Mumble is especially hard to configure in there. Improved speaker stats. When you right-click on a user in Mumble, you get detailed stats about the user: packet loss, latency, bandwidth, codecs... It's pretty neat. But that is hard to parse for a user. Jitsi, in contrast, shows a neat little "bar graph" (similar to what you get on a cell phone) with a color code to show network conditions for that user. Then you can drill down to show more information. Having that info for the user would be really useful to figure out which user is causing that echo or latency. Heck, while I'm dreaming, we could do the same thing Jitsi and tell the user when we detect too much noise on their side and suggest muting! There's probably more UI issues, but at that point you have basically rebuilt the entire user interface. This problem is hard to fix because UX people are unlikely to have the skills required to hack at an (old) Qt app, and C++ hackers are unlikely to have the best UX skills...

Missing features Video. It has been on the roadmap since 2011, so I'm not holding my breath. It is, obviously, the key feature missing from the software when compared to other conferencing tools and it's nice to see they are considering it. Screensharing and whiteboarding would also be a nice addition. Unfortunately, all that is a huge undertaking and it's unlikely to happen in the short term. And even if it does, it's possible hard-core Mumble users would be really upset at the change... A good web app -- a major blocker to the adoption of Mumble is the need for that complex app. If users could join just with a web browser, adoption would be much easier. There is a web app called mumble-web out there, but it seems to work only for listening as there are numerous problems with recording: quality issues, audio glitches, voice activation, voice activation.. The CCC seems to be using that app to stream talk translation, so that part supposedly works correctly. Dial-in -- allow plain old telephones to call into conferences. There seems to be a program called mumsi that can do this, but it's unmaintained and it's unclear if any of the forks work at all. Update: according to samba, mumsi works, but sometimes freezes and needs to be restarted. Each SIP account shows up as a bot that comes up when someone calls the number. It supports multiple callers, although apparently mumsi crashes after a while with 4 callers. A comment here also mentioned there's a fork that mentions using a "pin" as well for dialing in.

Caveats Now the above will probably not happen soon. Unfortunately, Mumble has had trouble with their release process recently. It took them a long time to even agree on releasing 1.3, and when they did agree, it took them a long time again to actually do the release. There has been much more activity on the Mumble client and web app recently, so hopefully I will be proven wrong. The 1.3.1 release actually came out recently(correction:) is actually being worked on, which is encouraging. All in all, mumble has some deeply ingrained UI limitations. it's built like an app from the 1990, all the way down to the menu system and "status bar" buttons. It's definitely not intuitive for a new user and while there's an audio wizard that can help you get started, it doesn't always work and can be confusing in itself. I understand that I'm just this guy saying "please make this for me ktxbye". I'm not writing this as a critic of Mumble: I love the little guy, the underdog. Mumble has been around forever and it kicks ass. I'm writing this in a spirit of solidarity, in the hope the feedback can be useful and to provide useful guidelines on how things could be improved. I wish I had the time to do this myself and actually help the project beyond just writing, but unfortunately the reality is I'm a poor UI designer and I have little time to contribute to more software projects. So hopefully someone could take those ideas and make Mumble even greater. And if not, we'll just have to live with it. Thanks to all the Mumble developers who, over all those years, managed to make and maintain such an awesome product. You rock!

Update: a chat with Mumble folks Update: it seems the idea of simplifying the Mumble interface will take some time to sink in. After presenting this article in the #mumble Freenode IRC channel, it became obvious that having a more usable interface is not a priority. To put it in the words of a participant in the channel:

If someone is too stupid to use a piece of software than they should probably use something else or have someone capable of critical thinking set it up for them. -- meep

So I guess "I'm with stupid": I do not believe we should make software only for "smart" people because that leads to overly complicated and over-engineered user interfaces that are needlessly hard to use and configure. Mumble is actually an excellent example of such programs: powerful software, but too hard to use to actually reach critical mass. Thankfully, meep is not a Mumble developer and does not actually represent the official position of the Mumble project. A core developer (not representing the project either) was more nuanced:

The UI being not up to date is a matter of taste. The kind of UI you are describing is the kind of UI I certainly don't want. More gernally though I agree that the UI needs some rework and especially: Flexibility so that each user can (ideally) make it appear as (s)he wants. Before this can happen though, we'll have to rewrite a fair bit of code as we'll have to separate backend and frontend from one another. -- krzmbrzl

So this will take time. The fact that Qt seems to be moving back to closed-source does not help the situation with Mumble's GUI development, unfortunately. But the other hand, maybe it will provide the necessary "kick" to write a new, simpler GUI.

  class   'jitsimeet':
    fqdn                 => 'jitsi.example.com',
    repo_key             => puppet:///files/apt/jitsimeet.gpg,
    manage_certs         => true,
    jitsi_vhost_ssl_key  => '/etc/letsencrypt/live/jitsi.example.com/privkey.pem'
    jitsi_vhost_ssl_cert => '/etc/letsencrypt/live/jitsi.example.com/cert.pem'
    auth_vhost_ssl_key   => '/etc/letsencrypt/live/auth.jitsi.example.com/privkey.pem'
    auth_vhost_ssl_cert  => '/etc/letsencrypt/live/auth.jitsi.example.com/cert.pem'
    jvb_secret           => 'mysupersecretstring',
    focus_secret         => 'anothersupersecretstring',
    focus_user_password  => 'yetanothersecret',
    meet_custom_options  =>  
      'enableWelcomePage'         => true,
      'disableThirdPartyRequests' => true,
     ;
   

• Tests using puppet-rspec
• Support for other OSes (only Debian 10 at the moment)
• Integration with the Apache and Ngnix modules

• Read more about Jitsi
• Get involved by cloning our repo
• Read about the SMASH project
• See some advice on getting started with automation

What are reproducible builds? One of the original promises of open source software is that distributed peer review and transparency of process results in enhanced end-user security. However, whilst anyone may inspect the source code of free and open source software for malicious flaws, almost all software today is distributed as pre-compiled binaries. This allows nefarious third-parties to compromise systems by injecting malicious code into ostensibly secure software during the various compilation and distribution processes.

News The report from our recent summit in Marrakesh was published and is now available in both PDF and HTML formats. A sincere thank you to all of the Reproducible Builds community for the input to the event a sincere thank you to Aspiration for preparing and collating this report. Harmut Schorrig published a detailed document on how to compile Java applications in such as way that the .jar build artefact is reproducible across builds. A practical and hands-on guide, it details how to avoid unnecessary differences between builds by explicitly declaring an encoding as the default value differs across Linux and MS Windows systems and ensuring that the generated .jar a variant of a .zip archive does not embed any nondeterministic filesystem metadata, and so on. Janneke gave a quick presentation on GNU Mes and reproducible builds during the lighting talk session at LibrePlanet 2020. [ ] Vagrant Cascadian presented There and Back Again, Reproducibly! video at SCaLE 18x in Pasadena in California which generated some attention on Twitter. Herv Boutemy mentioned on our mailing list in a thread titled Rebuilding and checking Reproducible Builds from Maven Central repository that since the update of a central build script (the parent POM ) every Apache project using the Maven build system should build reproducibly. A follow-up discussion regarding how to perform such rebuilds was also started on the Apache mailing list. The Telegram instant-messaging platform announced that they had updated their iOS and Android OS applications and claim that they are reproducible according to their full instructions, verifying that its original source code is exactly the same code that is used to build the versions available on the Apple App Store and Google Play distribution platforms respectfully. Herv Boutemy also reported about a new project called reproducible-central which aims to allow anyone to rebuild a component from the Maven Central Repository that is expected to be reproducible and check that the result is as expected. In last month s report we detailed Omar Navarro Leija s work in and around an academic paper titled Reproducible Containers which describes in detail the workings of a user-space container tool called dettrace (PDF). Since then, the PhD student from the University Of Pennsylvania presented on this tool at the ASPLOS 2020 conference in Lausanne, Switzerland. Furthermore, there were contributions to dettrace from the Reproducible Builds community itself. [ ][ ]

Distribution work

openSUSE In openSUSE, Bernhard M. Wiedemann published his monthly Reproducible Builds status update as well as made the following changes within the distribution itself:

• avfs (report build problem in %post script)
• arj (fix incorrect use of strcpy, submitted upstream)
• brickv (update get upstream fix)
• fvwm-themes (delta between architectures in noarch package)
• libpeas (report build failure in single-CPU mode)
• pmix (update to incoporate upstream fix)
• pw3270 (date variation, forwarded upstream)
• python-mailmanclient (report build failure in single-CPU mode)
• ripgrep (CPU, forwarded upstream)
• tensorflow2 (avoid random temporary directory path)
• tesseract-ocr (drop native architecture optimisations)
• vlc (fixed ghost file size and sort archive, already upstream)

Debian Chris Lamb further refined his merge request for the debian-installer component to allow all arguments from sources.list files (such as [check-valid-until=no] ) in order that we can test the reproducibility of the installer images on the Reproducible Builds own testing infrastructure. (#13) Holger Levsen filed a number of bug reports against the debrebuild tool that attempts to rebuild a Debian package given a .buildinfo file as input, including:

• Accepting signed .buildinfo files. (#955050)
• Two sbuild-related bugs. (#955123 & #955304)
• Specific adjustments to the APT configuration. (#955307, #955298 & #955280)
• Requests to improve the documentation in various ways. (#955049 & #955308)

48 reviews of Debian packages were added, 17 were updated and 34 were removed this month adding to our knowledge about identified issues. Many issue types were noticed, categorised and updated by Chris Lamb, including:

• nondeterministic_gtk_icon_cache [ ]
• nondeterministic_ordering_in_documentation_generated_by_doxygen [ ]
• nondeterministic_vo_files_generated_by_coq [ ] utput
• randomness_in_browserify_lite_output [ ]

Finally, Holger opened a bug report against the software running tracker.debian.org, a service for Debian Developers to follow the evolution of packages via web and email interfaces to request that they integrate information from buildinfos.debian.net (#955434) and Chris Lamb kept isdebianreproducibleyet.com up to date. [ ]

Software development

diffoscope Chris Lamb made the following changes to diffoscope, the Reproducible Builds project s in-depth and content-aware diff utility that can locate and diagnose reproducibility issues, including preparing and uploading version 138 to Debian:

• Improvements:
  • Don t allow errors with R script deserialisation cause the entire operation to fail, for example if an external library cannot be loaded. (#91)
  • Experiment with memoising output from expensive external commands, eg. readelf. (#93)
  • Use dumppdf from the python3-pdfminer if we do not see any other differences from pdftext, etc. (#92)
  • Prevent a traceback when comparing two R .rdx files directly as the get_member method will return a file even if the file is missing. [ ]
• Reporting:
  • Display the supported file formats into the package long description. (#90)
  • Print a potentially-helpful message if the PyPDF2 module is not installed. [ ]
  • Remove any duplicate comparator descriptions when formatting in the --help output or in the package long description. [ ]
  • Weaken Install the X package to get a better output message to may produce a better output as the former is not actually guaranteed. [ ]
• Misc:
  • Ensure we only parse the recommended packages from --list-debian-substvars when we want them for debian/tests/control generation. [ ]
  • Add upstream metadata file [ ] and add a Lintian override for upstream-metadata-in-native-source as we are upstream. [ ]
  • Inline the RequiredToolNotFound.get_package method s functionality as it is only used once. [ ]
  • Drop the deprecated py36 = [..] argument in the pyproject.toml file. [ ]

In addition, Vagrant Cascadian updated diffoscope in GNU Guix to version 138 [ ], as well as updating reprotest our end-user tool to build same source code twice in widely differing environments and then checks the binaries produced by each build for any differences to version 0.7.14 [ ].

Upstream patches The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where appropriate. This month we wrote a large number of such patches, including:

• Bernhard M. Wiedemann (via openSUSE):
  • arj (date variation)
  • gnulib (date variation)
  • gnulib (date variation)
  • lasso (sort filesystem ordering)
  • mono/at-spi-sharp (report nondeterminism from filesystem nondeterminism)
  • python-M2Crypto (report security certs expiring in 2029)
  • python-swifter (report single-CPU build failure)
  • QT uic (report ASLR nondeterminism)
  • tdiff (report single-CPU build failure)
  • tensorflow (report ASLR-induced variation)
  • volk (drop compile-time CPU detection)
• Chris Lamb:
  • #952990 filed against pmemkv (forwarded upstream)
  • #953071 filed against ndisc6.
  • #953117 filed against infernal.
  • #953263 filed against beep.
  • #953646 filed against node-nodedbi.
  • #954409 filed against node-browserify-lite.
  • #955009 filed against font-manager.
  • #955287 filed against pdb2pqr.
  • #955341 filed against gucharmap.
  • #955364 filed against cloudkitty.
  • isbg (report a non-determinstic documentation issue)

Project documentation There was further work performed on our documentation and website this month including Alex Wilson adding a section regarding using Gradle for reproducible builds in JVM projects [ ] and Holger Levsen added the report from our recent summit in Marrakesh [ ][ ]. In addition, Chris Lamb made a number of changes, including correcting the syntax of some CSS class formatting [ ], improved some filed against copy a little better [ ] and corrected a reference to calendar.monthrange Python method in a utility function. [ ]

Testing framework We operate a large and many-featured Jenkins-based testing framework that powers tests.reproducible-builds.org that, amongst many other tasks, tracks the status of our reproducibility efforts as well as identifies any regressions that have been introduced. This month, Chris Lamb reworked the web-based package rescheduling tool to:

• Require a HTTP POST method in the web-based scheduler as not only should HTTP GET requests be idempotent but this will allow many future improvements in the user interface. [ ][ ][ ]
• Improve the authentication error message in said rescheduler to suggest that the developer s SSL certificate may have expired. [ ]

In addition, Holger Levsen made the following changes:

• Add a new ath97 subtarget for the OpenWrt distribution.
• Revisit ordering of Debian suites; sort the experimental distribution last and reverse the ordering of suites to prioritise the suites in development. [ ][ ][ ]
• Schedule Debian buster and bullseye a little less in order to allow unstable to catch up on the i386 architecture. [ ][ ]
• Various cosmetic changes to the web-based scheduler. [ ][ ][ ][ ]
• Improve wordings in the node health maintenance output. [ ]

Lastly, Vagrant Cascadian updated a link to the (formerly) weekly news to our reports page [ ] and kpcyrd fixed the escaping in an Alpine Linux inline patch [ ]. The usual build nodes maintenance was performed by Holger Levsen [ ][ ], Mattia Rizzolo [ ] and Vagrant Cascadian [ ][ ].
If you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:

• IRC: #reproducible-builds on irc.oftc.net.
• Twitter: @ReproBuilds
• Reddit: /r/ReproducibleBuilds
• Mailing list: rb-general@lists.reproducible-builds.org

This month s report was written by Bernhard M. Wiedemann, Chris Lamb, Holger Levsen and Vagrant Cascadian. It was subsequently reviewed by a bunch of Reproducible Builds folks on IRC and the mailing list.

• First of all you need to define the minimum set of primitives you can execute.
  • (Creating a file, fetching a package, reloading services when a configuration file changes, etc.)
• Then you need to define a syntax for expressing those rules.
  • Not using YAML. Because Ansible fucked up bigtime with that.
  • It needs to be easy to explain, it needs to be consistent, and you need to decide before you begin if you want "toy syntax" or "programming syntax".
  • Because adding on conditionals, loops, and similar, will ruin everything if you add it once you've started with the wrong syntax. Again, see Ansible.

file   name   => "This is my rule",
       target => "/tmp/blah",
       ensure => "absent"  

notify => "Name of rule"
# or
notify => [ "Name of rule", "Name of another rule" ]

shell   name => "Do stuff",
        command => "wc -l /etc/passwd > /tmp/foo",
        requires => [ "Rule 1", "Rule 2"]  

• We pass the parameters, as JSON, to STDIN of the binary.
• We read the result from STDOUT
  • Did the rule result in a change to the system?
  • Or was it a NOP?

• https://github.com/skx/marionette

Kaleidogen Kaleidogen is a little contemplative game (or toy game where, starting from just unicolored disks, you combine abstract circular patterns to breed more interesting patterns. See my FARM 2019 talk for more details, or check out the source repository. BTW, I am looking for help turning it into an Android app!

KaleidogenBot in action

Amazon Lambda Amazon Lambda is the Function as a service offering of Amazon Web Services. The idea is that you don t rent a server, where you have to deal with managing the whole system and that you are paying for constantly, but you just upload the code that responds to outside requests, and AWS takes care of the rest: Starting and stopping instances, providing a secure base system etc. When nobody is using the service, no cost occurs. This sounds ideal for hosting a toy Telegram bot: Most of the time nobody will be using it, and I really don't want to have to baby sit yet another service on my server. On Amazon Lambda, I can probably just forget about it. But Haskell is not one of the officially supported languages on Amazon Lambda. So to run Haskell on Lambda, one has to solve two problems:

• how to invoke the Haskell code on the server, and
• how to build Haskell so that it runs on the Amazon Linux distribution

A Haskell runtime for Lambda For the first we need a custom runtime. While this sounds complicated, it is actually a pretty simple concept: A runtime is an executable called bootstrap that queries the Lambda Runtime Interface for the next request to handle. The Lambda documentation is phrased as if this runtime has to be a dispatcher that calls the separate function s handler. But it could just do all the things directly. I found the Haskell package aws-lambda-haskell-runtime which provides precisely that: A function

runLambda :: (LambdaOptions -> IO (Either String LambdaResult)) -> IO ()

that talks to the Lambda Runtime API and invokes its argument on each message. The package also provides Template Haskell magic to collect handlers of any JSON-able type and generates a dispatcher, like you might expect from other, more dynamic languages. But that was too much magic for me, so I ignored that and just wrote the handler manually:

main :: IO ()
main = runLambda run
  where
   run ::  LambdaOptions -> IO (Either String LambdaResult)
   run opts = do
    result <- handler (decodeObj (eventObject opts)) (decodeObj (contextObject opts))
    either (pure . Left . encodeObj) (pure . Right . LambdaResult . encodeObj) result
data Event = Event
    path :: T.Text
  , body :: Maybe T.Text
    deriving (Generic, FromJSON)
data Response = Response
    statusCode :: Int
  , headers :: Value
  , body :: T.Text
  , isBase64Encoded :: Bool
    deriving (Generic, ToJSON)
handler :: Event -> Context -> IO (Either String Response)
handler Event body, path  context =
 

I expose my Lambda function to the world via Amazon s API Gateway, configured to just proxy the HTTP requests. This means that my code receives a JSON data structure describing the HTTP request (here called Event, listing only the fields I care about), and it will respond with a Response, again as JSON. The handler can then simply pattern-match on the path to decide what to do. For example this code handles URLs like /img/CAFFEEFACE.png, and responds with an image.

handler :: TC -> Event -> Context -> IO (Either String Response)
handler Event body, path  context
      Just bytes <- isImgPath path >>= T.decodeHex = do
        let pngData = genPurePNG bytes
        pure $ Right Response
              statusCode = 200
            , headers = object [ "Content-Type" .= ("image/png" :: String) ]
            , isBase64Encoded = True
            , body = T.decodeUtf8 $ LBS.toStrict $ Base64.encode pngData
             
     
isImgPath :: T.Text -> Maybe T.Text
isImgPath  = T.stripPrefix "/img/" >=> T.stripSuffix ".png"

If this program would grow more, then one should probably use something more structured for routing here; maybe servant, or bridging towards wai apps (amost like wai-lamda, but that still assumes an existing runtime, instead of simply being the runtime). But for my purposes, no extra layers of indirection or abstraction are needed!

Deploying Haskell to Lambda Building Haskell locally and deploying to different machiens is notoriously tricky; you often end up depending on a shared library that is not available on the other platform. The aws-lambda-haskell-runtime package, and similar projects like serverless-haskell, solve this using stack and Docker two technologies that are probably great, but I never warmed up to them. So instead adding layers and complexities, can I solve this instead my making things simpler? If I compiler my bootstrap into a static Linux binary, it should run on any Linux, including Amazon Linux. Unfortunately, building Haskell programs statically is also notoriously tricky. But it is made much simpler by the work of Niklas Hamb chen and others in the context of the Nix package manager, coordinated in the static-haskell-nix project. The promise here is that once you have set up building your project with Nix, then getting a static version is just one flag away. The support is not completely upstreamed into nixpkgs proper yet, but their repository has a nix file that contains a nixpkgs set with their patches:

let pkgs = (import (sources.nixpkgs-static + "/survey/default.nix")  ).pkgs; in

This, plus a fairly standard nix setup to build the package, yields what I was hoping for:

$ nix-build -A kaleidogen
/nix/store/ppwyq4d964ahd6k56wsklh93vzw07ln0-kaleidogen-0.1.0.0
$ file result/bin/kaleidogen-amazon-lambda
result/bin/kaleidogen-amazon-lambda: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped
$ ls -sh result/bin/kaleidogen-amazon-lambda
6,7M result/bin/kaleidogen-amazon-lambda

If we put this file, named bootstrap, into a zip file and upload it to Amazon Lambda, then it just works! Creating the zip file is easily scripted using nix:

  function-zip = pkgs.runCommandNoCC "kaleidogen-lambda"  
    buildInputs = [ pkgs.zip ];
    ''
    mkdir -p $out
    cp $ kaleidogen /bin/kaleidogen-amazon-lambda bootstrap
    zip $out/function.zip bootstrap
  '';

So to upload this, I use this one-liner (line-wrapped for your convenience):

nix-build -A function-zip &&
aws lambda update-function-code --function-name kaleidogen \
  --zip-file fileb://result/function.zip

Thanks to how Nix pins all dependencies, I am fairly confident that I can return to this project in 4 months and still be able to build it. Of course, I want continuous integration and deployment. So I build the project with GitHub Actions, using a cachix nix cache to significantly speed up the build, and auto-deploy to Lambda using aws-lambda-deploy; see my workflow file for details.

The Telegram part The above allows me to run basically any stateless service, and a Telegram bot is nothing else: When configured to act as a WebHook, Telegram will send a request with a message to our Lambda function, where we can react on it. The telegram-api package provides bindigs for the Telegram Bot API (although I had to use the repository version, as the version on Hackage has some bitrot). Slightly simplified I can write a handler for an Update:

handleUpdate :: Update -> TelegramClient ()
handleUpdate Update  message = Just m   = do
  let c = ChatId (chat_id (chat m))
  liftIO $ printf "message from %s: %s\n" (maybe "?" user_first_name (from m)) (maybe "" T.unpack (text m))
  if "/start"  T.isPrefixOf  fromMaybe "" (text m)
  then do
    rm <- sendMessageM $ sendMessageRequest c "Hi! I am @KaleidogenBot.  "
    return ()
  else do
    m1 <- sendMessageM $ sendMessageRequest c "One moment "
    withPNGFile  $ \pngFN -> do
      m2 <- uploadPhotoM $ uploadPhotoRequest c
        (FileUpload (Just "image/png") (FileUploadFile pngFN))
      return ()
handleUpdate _ u =
  liftIO $ putStrLn $ "Unhandled message: " ++ show u

and call this from the handler that I wrote above:

     
      path == "/telegram" =
      case eitherDecode (LBS.fromStrict (T.encodeUtf8 (fromMaybe "" body))) of
        Left err ->  
        Right update -> do
          runTelegramClient token manager $ handleUpdate Nothing update
          pure $ Right Response
              statusCode = 200
            , headers = object [ "Content-Type" .= ("text/plain" :: String) ]
            , isBase64Encoded = False
            , body = "Done"
             
     

Note that the Lambda code receives the request as JSON data structure with a body that contains the original HTTP request body. Which, in this case, is itself JSON, so we have to decode that. All that is left to do is to tell Telegram where this code lives:

curl --request POST \
  --url https://api.telegram.org/bot<token>/setWebhook
  --header 'content-type: application/json'
  --data ' "url": "https://api.kaleidogen.nomeata.de/telegram" '

As a little add on, I also created a Telegram game for Kaleidogen. A Telegram game is nothing but a webpage that runs inside Telegram, so it wasn t much work to wrap the Web version of Kaleidogen that way, but the resulting Telegram game (which you can access via https://core.telegram.org/bots/games) still looks pretty neat.

No /dev/dri/renderD128 I am mostly happy with this setup: My game is now available to more people in more ways. I don t have to maintain any infrastructure. When nobody is using this bot no resources are wasted, and the costs of the service are neglectible -- this is unlikely to go beyond the free tier, and even if it would, the cost per generated image is roughly USD 0.000021. There is one slight disappointment, though. What I find most intersting about Kaleidogen from a technical point of view is that when you play it in the browser, the images are not generated by my code. Instead, my code creates a WebGL shader program on the fly, and that program generates the image on your graphics card. I even managed to make the GL rendering code work headlessly, i.e. from a command line program, using EGL and libgbm and a helper written in C. But it needs access to a graphics card via /dev/dri/renderD128. Amazon does not provide that to Lambda code, and neither do the other big Function-as-a-service providers. So I had to swallow my pride and reimplement the rendering in pure Haskell. So if you think the bot is kinda slow, then that s why. Despite properly optimizing the pure implementation (the inner loop does not do allocations and deals only with unboxed Double# values), the GL shader version is still three times as fast. Maybe in a few years GPU access will be so ubiquitous that it s even on Amazon Lambda; then I can easily use that.

DPL Campaign 2020 On the 12th of March, I posted my self-nomination for the Debian Project Leader election. This is the second time I m running for DPL, and you can read my platform here. The campaign period covered the second half of the month, where I answered a bunch of questions on the debian-vote list. The voting period is currently open and ends on 18 April.

Debian Social

• Team accounts. Some Debian teams already have accounts on a myriad of other platforms. For example, the Debian Med team has a blog on blogspot and the Debian Publicity team has an account on framapiaf.org. I d really like to make our Debian Social platforms (like our WordPress multisite instance and Pleroma) a place where Debian teams can trust to host their updates on. It would also be nice to have more teams use these that don t have a particularly big online presence right now, like Debian women or a DPL team account.
• Developer demos. I enjoy the videos that the GNOME project makes that demos the new features in every release, as they ve done for the 3.36 release. I think it would be great if people in Debian could make some small videos to demo the things that they ve been working on. It doesn t have to be as flashy or elaborate as the GNOME video I ve linked to, but sometimes just a minute long demo can be really useful to convey a new idea or feature or to show progress that has been made.
• User participation. YouTube is full of videos that review Debian or demo how to customise it. It would be great if we could get users to post such videos to PeerTube. For Pixelfed, I d like to try out projects like users posting pictures of their computers with freshly installed Debian systems with a hashtag like #WeInstallDebian, then at the end of the year we could build a nice big mosaic that contains these images. Might make a cool poster for events too.
• DebConf and other Debian events. We used to use a Gallery instance to host DebConf photos, but it s always been a bit cumbersome managing photos there and Gallery hasn t updated it s UI much over the years causing it to fall a bit out of favour with attendees at these events. As a result, photos end up getting lost in WhatsApp/Telegram/Signal groups, Twitter, Facebook, etc. I hope that we could get enough users signed up on the Pixelfed instance that it could become the de facto standard for posting Debian event photos to. Having a known central place to post these make them easier to find as well.

Debian packaging I had the sense that there were fewer upstream releases this month. I suspect that everyone was busy figuring out how to cope during Covid-19 lockdowns taking place all over the world. 2020-03-02: Upload package calamares (3.2.10-1) to Debian unstable. 2020-03-10: Upload package gnome-shell-extension-dash-to-panel (29-1) to Debian unstable. 2020-03-10: Upload package gnome-shell-extension-draw-on-your-screen (5.1-1) to Debian unstable. 2020-03-28: Upload package gnome-shell-extension-dash-to-panel (31-1) to Debian unstable. 2020-03-28: Upload package gnome-shell-extension-draw-on-your-screen (6-1) to Debian unstable. 2020-03-28: Update package python3-flask-autoindexing packaging, not releasing due to licensing change that needs further clarification. (GitHub issue #55). 2020-03-28: Upload package gamemode (1.5.1-1) to Debian unstable. 2020-03-28: Upload package calamares (3.2.21-1) to Debian unstable.

Debian mentoring 2020-03-03: Sponsor package python-jaraco.functools (3.0.0-1) (Python team request). 2020-03-03: Review python-ftputil (3.4-1) (Needs some more work) (Python team request). 2020-03-04: Sponsor package pythonmagick (0.9.19-6) for Debian unstable (Python team request). 2020-03-23: Sponsor package bitwise (0.41-1) for Debian unstable (Email request). 2020-03-23: Sponsor package gpxpy (1.4.0-1) for Debian unstable (Python team request). 2020-03-28: Sponsor package gpxpy (1.4.0-2) for Debian unstable (Python team request). 2020-03-28: Sponsor package celery (4.4.2-1) for Debian unstable (Python team request). 2020-03-28: Sponsor package buildbot (2.7.0-1) for Debian unstable (Python team request).

Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent s UNIX-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent. A safer alternative may be to use a jump host (see -J).

• it holds only the private key to connect to the target host, and
• it asks confirmation for each requested signature.

alias assh="ssh-agent ssh -o AddKeysToAgent=confirm -o ForwardAgent=yes"

Request for the agent to use the specified private key

Changes in version 0.0.4 (2020-04-03)

• Upgraded to new upstream releases 0.3 and 0.3.1 (Dirk in #9 closing #8)
• Updated example validateJSON to API changes.

Highlights

• Multi-Document Parsing: Read a bundle of JSON documents (ndjson) 2-4x faster than doing it individually. API docs / Design Details
• Simplified API: The API has been completely revamped for ease of use, including a new JSON navigation API and fluent support for error code and exception styles of error handling with a single API. Docs
• Exact Float Parsing: Now simdjson parses floats flawlessly without any performance loss (https://github.com/simdjson/simdjson/pull/558). Blog Post
• Even Faster: The fastest parser got faster! With a shiny new UTF-8 validator and meticulously refactored SIMD core, simdjson 0.3 is 15% faster than before, running at 2.5 GB/s (where 0.2 ran at 2.2 GB/s).

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

• Patched the browserify-lite Javascript compiler to ensure that module dependency maps are rendered in a deterministic order. (#14)
• Pushed a change to the "pmemkv" key-value data store to make their documentation build reproducibly. (#615)
• As part of my duties of being on the board of directors of the Open Source Initiative and Software in the Public Interest I attended their respective monthly meetings and participated in various licensing and other discussions occurring on the internet as well as the usual internal discussions regarding logistics, licensing, policy and liaising with the ClearlyDefined and so Congratulations to Megan Sanicki and Josh Simmons who were elected and re-elected respectively to the OSI Board's two individual member seats and to Italo Vignoli who was elected to the affiliate member seat. These newly-elected Directors will took their seats on March 20, 2020.
• Opened a pull request against the onionbalance load balancer for hidden Tor services to fix test failures under Pytest 3.x. (#75)
• Filed an issue against IMAP Spam Begone (isbg), a script by Louis-Philippe V ronneau (pollo) that makes it easy to process an email inbox using SpamAssassin, to report that a duplicate documentation entry includes a nondeterministic value taken from the value of the XDG cache directory. (#151)

• As part of being on being on the judging panel of the OpenUK Awards I am pleased to announce that after some discussion nominations are now open until 15th June in five different categories.
• Merged a number of contributions to my django-cache-toolbox "non-magical" caching library for Django web applications, including caching negative relation lookups locally (#14) and to include the README file in the package long description (#17).
• Made some small changes to my tickle-me-email library which implements Gettings Things Done (GTD)-like behaviours in IMAP inboxes to support to optionally limiting the number of messages in the send-later functionality. [...]

• New features:
  • Check for py3versions -i in autopkgtests and debian/rules files. (#954763)
  • Warn when py3versions -s is used without a python3-all dependency. (#954763)
  • Expand possible-missing-colon-in-closes to also check for semicolons used in place of colons. (#954484)
  • Check for new packages that use a date-based versioning scheme (eg. YYYYMMDD-1) without a 0~ suffix. (#953036)
• Improvements:
  • Don't emit duplicate-short-description or duplicate-long-description if they contain substitution variables. (#947168)
  • Don't report about using a newer Standards-Version when uploading to the backports repository. [...]
  • Don't check the length of Checksums-Sha256 fields. (#954798)
  • Don't check for DEBIAN/md5sums control files in udebs. (#954803)
  • Apply a patch from gregoa to remove some <!nocheck> annotations; some packages are required to build successfully. (#954338)
• Misc:
  • Correct reference to build dependencies in the long description of the debian-rules-uses-installed-python-versions tag. [...]
  • Make some cosmetic improvements to the CONTRIBUTING.md file. [...]
  • Correct reference to a bug in a previous debian/changelog entry. [...]
  • Avoid indenting approximately 150 lines by returning early from a subroutine and other code improvements. [...]

• Filed an issue against IMAP Spam Begone a script by Louis-Philippe V ronneau (pollo) that makes it easy to process an email inbox using SpamAssassin to report that a (duplicate) documentation entry includes nondeterministic value taken from the value of the XDG cache directory (#151) and filed an upstream pull requests against the pmemkv key-value data store to make their documentation build reproducibly (#615).
• Further refined my merge request against the debian-installer component to allow all arguments from sources.list files (such as [check-valid-until=no]) in order that we can test the reproducibility of the installer images on the Reproducible Builds own testing infrastructure. (#13)
• Submitted two following patches to fix reproducibility-related toolchain issues within Debian:
  • node-browserify-lite: Please make the output reproducible. (#954409)
  • pdb2pqr: Please make the aconf.py file reproducible. (#955287)
• Submitted eight patches to fix specific reproducibility issues in beep (caused by a variation between /bin/dash and /bin/bash), cloudkitty (due to a default value being taken from the number of CPUs on the build machine), font-manager (embedding the value of @abs_top_srcdir@ into the resulting binary), gucharmap (due to embedding the absolute build path when generating a comment in a header file), infernal (timestamps are injected into a Python example, which should not be shipped anyway), ndisc6 (embeds the value of CFLAGS into the binary without sanitising any absolute build paths), node-nodedbi (embedded timestamp in binary) & pmemkv (does not respect SOURCE_DATE_EPOCH when populating a YEAR variable).
• Kept isdebianreproducibleyet.com up to date. [...]
• Continued collaborative work on an academic paper to be published within the next few months.
• Categorised a large number of packages and issues in the Reproducible Builds "notes" repository.
• Drafted, published and publicised our monthly report.
• Improved our website, including correcting the syntax of some CSS class formatting [...], improved some "filed against" copy a little better [...] and corrected a reference to calendar.monthrange Python method. [...]

• Improvements:
  • Don't allow errors with R script deserialisation cause the entire operation to fail, for example if an external library cannot be loaded. (#91)
  • Experiment with memoising output from expensive external commands, eg. readelf. (#93)
  • Use dumppdf from the python3-pdfminer if we do not see any other differences from pdftext, etc. (#92)
  • Prevent a traceback when comparing two R .rdx files directly as the get_member method will return a file even if the file is missing. [...]
• Reporting:
  • Display the supported file formats into the package long description. (#90)
  • Print a potentially-helpful message if the PyPDF2 module is not installed. [...]
  • Remove any duplicate comparator descriptions when formatting in the --help output or in the package long description. [...]
  • Weaken "Install the X package to get a better output." message to "... may produce a better output." as the former is not guaranteed. [...]
• Misc:
  • Ensure we only parse the recommended packages from --list-debian-substvars when we want them for debian/tests/control generation. [...]
  • Add upstream metadata file [...] and add a Lintian override for upstream-metadata-in-native-source as "we" are upstream. [...]
  • Inline the RequiredToolNotFound.get_package method's functionality as it is only used once. [...]
  • Drop the deprecated "py36 = [..]" argument in the pyproject.toml file. [...]

• Require a HTTP POST method in the web-based scheduler as not only should HTTP GET requests be idempotent but this will allow many future improvements in the user interface. [...][...][...]
• Improve the authentication error message in the rescheduler to suggest that the developer's SSL certificate may have expired. [...]

• Investigated and triaged glibc (CVE-2020-1751), jackson-databind, libbsd (CVE-2019-20367), libvirt (CVE-2019-20485), netkit-telnet & netkit-telnet-ssl (CVE-2020-10188), pdfresurrect (CVE-2020-9549) & shiro (CVE-2020-1957), etc.
• In the script that reserves a unique advisory number don't warn about potential duplicate work when issuing a regression in order to avoid this message being missed when it does apply. [...]
• Frontdesk duties, responding to user/developer questions, reviewing others' packages, participating in mailing list discussions, etc.
• xtrlock versions 2.8+deb9u1 (#949112) and 2.8+deb10u1 (#949113) was accepted to the Debian jessie and buster distributions.
• Issued DLA 2115-2 to correct a regression in a previous fix (a use-after-free vulnerability) in the ProFTPD FTP server.
• Issued DLA 2132-1 to fix an issue where incorrect default permissions on a HTTP cookie store could have allowed local attackers to read private credentials in libzypp, the library underpinning package management tools such as YaST, zypper and the openSUSE/SLE implementation of PackageKit.
• Issued DLA 2134-1 to patch an out-of-bounds write vulnerability in pdfresurrect, a tool for extracting or scrubbing versioning data from PDF documents.
• Issued DLA 2136-1, addressing an out-of-bounds buffer read vulnerability in libvpx, a library implementing the VP8 & VP9 video codecs.
• Issued DLA 2142-1. It was discovered that there was a buffer overflow vulnerability in slirp, a SLIP/PPP emulator for using a dial up shell account. This was caused by the incorrect usage of return values from snprintf(3).
• Issued DLA 2145-1 and DLA 2145-2 for twisted to prevent a large number of HTTP request splitting vulnerabilities in Twisted, a Python event-based framework for building various types of internet applications.
• Issued ELA-219-1 to address an out-of-bounds read vulnerability during string comparisons in libbsd, a library of functions commonly available on BSD systems but not on others such as GNU.

• python-django (2.2.11-1 & 3.0.4-1) New upstream security releases. (#953102)
• redis:
  • 6.0~rc1-3 Install OpenSSL when running the testsuite as it is required for generating test certificates.
  • 6.0~rc2-1 New upstream beta release.
• xtrlock (2.13) Add a warning that X11 does not support grabbing events under the Wayland display server protocol. (#953319)
• gunicorn (20.0.4-4) Ensure that the Python 3.x gunicorn binary package replaces the now-legacy gunicorn3 that was removed in 19.9.0-2 upon installation. I also backported this version to buster-backports. (#953883)
• hiredis (0.14.1-1) New upstream release.
• libfiu (1.00-7) Fix build failures under Python 3.8. (#954287)
• memcached:
  • 1.6.0-1 New upstream release.
  • 1.6.1-1 New upstream release.
  • 1.6.2-1 New upstream security release. (#954808)
• bfs (1.6-2, 1.6-3 & 1.6-4) Fix various build failures on kFreeBSD architectures.
• mtools (4.0.24-1) New upstream release.
• xcb (2.4-6) Remove a vague "pigeon holes" metaphor from package description.

• By keeping the Fn key pressed, i.e. the alternative layer is active as long as you hold the Fn key down.
• One-shot layer switch: After having pressed and released the Fn key, all keys are on the alternative layer for a single key press and then you are back to the default layer.
• Layer toggle: Pressing the Fn key once switches to the alternative layer and pressing it a second time switches back to the default layer.
• There are also a lot of variants of the latter variant, e.g. rotating between layers upon every key press of the Fn key. In that case it seems common to have a second special key which always switches back to the default layer, kinda Escape key for layer switching.

TRNS means transparent, i.e. use the settings from lower layers.

• The left spacebar is space on tap and switches to layer 1 if hold. The right spacebar is a real spacebar, i.e. already triggers a space on key press, not only on key release. Layer 1 has numbers on the top row and the special characters of the number row in the second row. It also has Home/End and Page Up/Down on the cursor keys.
• The key between the Enter key and the cursor-right key (medium grey with a light grey caret in the picture) is actually the Slash and Question Mark key, but if hold, it switches me to layer 2. Layer 2 has function keys on the top row and also the special characters of the number row in the second row. On the cursor keys it has volume up and down as well as the media keys previous and next .
• The green key in the picture is actually the Backslash and Pipe key, but if hold, it switches me to layer 3. On layer 3 I have mouse control.

1. press and release Menu (i.e. Compose); then
2. press and hold either Shift-Spacebar (i.e. Shift-Fn1) or Slash (i.e. Fn2), then
3. press N for a double quote (i.e. Shift-Fn1-N or Fn2-N) and then release all keys, and finally
4. press and release the base character for the umlaut, in this case Shift-A.

A triangle means that the settings from lower layers are used, N/A means the key does nothing.

• Use all keys on tap as labelled by default. (Data = Enter as mentioned above)
• Use different meanings on hold for the whole bottom row and some edge column keys.
• Have all classic modifiers (Shift, Control, OS/Sys/Win, Alt/Meta) on the first layer twice (always only on hold), so that any key, even those with a modifier on hold, can be used with any modifier. (Example: Shift is on A hold and L hold so that Shift-A is holding L and then pressing A and Shift-L is holding A and then pressing L.)

• Z = Control
• X = OS/Sys/Win
• C = Alt/Meta
• V = Layer 3 (aka Fn3)
• Space = Layer 1 (aka Fn1)
• B = Alt/Meta
• N = OS/Sys/Win
• M = Ctrl

• A = Shift
• L = Shift
• Data (Enter) = Layer 2 (aka Fn2)
• P = Layer 4 (aka Fn4)

• Layer 0 (Default): alphabetic keys, Space, Enter, and (on hold) standard modifiers
• Layer 1: numbers, special characters (most need Shift, too), and some more common other keys, e.g.
  • Space-Enter = Backspace
  • Space-S = Esc
  • Space-D = Tab
  • Space-F = Menu/Compose
  • Space-K = :
  • Space-L = '
  • Space-B = ,
  • Space-N = .
  • Space-M = /, etc.
• Layer 2: F-keys and less common other keys, e.g.
  • Enter-K = -
  • Enter-L = =
  • Enter-B = [
  • Enter-N = ]
  • Enter-M = \, etc.)
• Layer 3: Cursor movement, e.g.
  • scrolling
  • and mouse movement.
  • Cursor cross is on V-IJKL (with V-I for Up)
  • V-U and V-O are Home and End
  • V-P and V-Enter are Page Up/Down.
  • Mouse movement is on V-WASD
  • V-Q
  • V-E and V-X being mouse buttons
  • V-F and V-R is the scroll wheel up down
  • V-Z and V-C left and right.
• Layer 4: Configuring the RGB bling-bling and the QMK reset key:
  • P-Q (the both top corner keys) are QMK reset to be able to reflash the firmware.
  • The keys on the right half of the keyboard control the modes of the RGB LED strip on the bottom side of the PCB, with the upper two rows usually having keys with some Plus and Minus semantics, e.g. P-I and P-K is brightness up and down.
  • The remaining left half is unused and has no function at all on layer 4.

1. press and release Space-F (i.e. Fn1-F) for Menu (i.e. Compose); then
2. press and hold A-Spacebar-L (i.e. Shift-Fn1-L) for getting a double quote, then
3. press and release the base character for the umlaut, in this case L-A for Shift-A (because we can t use A for Shift as I can t hold a key and then press it again :-).

• A Reviung39 to start a new try on ortholinear layouts.
• A Jerkin (sold out, waitlist available) to try an Alice-style keyboard layout.
• A Pain27 (which btw. is also open source under the CC0 license) to try typing with even one key less than the Alpha28 has. ;-)

Testing basic WebRTC functionality Before you place a real call, I suggest using the official test page which will test your camera, microphone and network connectivity. Note that this test page makes use of a Google TURN server which is locked to particular HTTP referrers and so you'll need to disable privacy features that might interfere with this:

• Brave: Disable Shields entirely for that page (Simple view) or allow all cookies for that page (Advanced view).

• Firefox: Ensure that http.network.referer.spoofSource is set to false in about:config, which it is by default.
• uMatrix: The "Spoof Referer header" option needs to be turned off for that site.

Checking the type of peer connection you have Once you know that WebRTC is working in your browser, it's time to establish a connection and look at the network configuration that the two peers agreed on. My favorite service at the moment is Whereby (formerly Appear.in), so I'm going to use that to connect from two different computers:

• canada is a laptop behind a regular home router without any port forwarding.
• siberia is a desktop computer in a remote location that is also behind a home router, but in this case its internal IP address (192.168.1.2) is set as the DMZ host.

Chromium For all Chromium-based browsers, such as Brave, Chrome, Edge, Opera and Vivaldi, the debugging page you'll need to open is called chrome://webrtc-internals. Look for RTCIceCandidatePair lines and expand them one at a time until you find the one which says:

• state: succeeded (or state: in-progress)
• nominated: true
• writable: true

Then from the name of that pair (N6cxxnrr_OEpeash in the above example) find the two matching RTCIceCandidate lines (one local-candidate and one remote-candidate) and expand them. In the case of a direct connection, I saw the following on the remote-candidate:

• ip shows the external IP address of siberia
• port shows a random number between 1024 and 65535
• candidateType: srflx

and the following on local-candidate:

• ip shows the external IP address of canada
• port shows a random number between 1024 and 65535
• candidateType: prflx

These candidate types indicate that a STUN server was used to determine the public-facing IP address and port for each computer, but the actual connection between the peers is direct. On the other hand, for a relayed/proxied connection, I saw the following on the remote-candidate side:

• ip shows an IP address belonging to the TURN server
• candidateType: relay

and the same information as before on the local-candidate.

Firefox If you are using Firefox, the debugging page you want to look at is about:webrtc. Expand the top entry under "Session Statistics" and look for the line (should be the first one) which says the following in green:

• ICE State: succeeded
• Nominated: true
• Selected: true

then look in the "Local Candidate" and "Remote Candidate" sections to find the candidate type in brackets.

Firewall ports to open to avoid using a relay In order to get a direct connection to the other WebRTC peer, one of the two computers (in my case, siberia) needs to open all inbound UDP ports since there doesn't appear to be a way to restrict Chromium or Firefox to a smaller port range for incoming WebRTC connections. This isn't great and so I decided to tighten that up in two ways by:

• restricting incoming UDP traffic to the IP range of siberia's ISP, and
• explicitly denying incoming to the UDP ports I know are open on siberia.

To get the IP range, start with the external IP address of the machine (I'll use the IP address of my blog in this example: 66.228.46.55) and pass it to the whois command:

$ whois 66.228.46.55   grep CIDR
CIDR:           66.228.32.0/19

To get the list of open UDP ports on siberia, I sshed into it and ran nmap:

$ sudo nmap -sU localhost
Starting Nmap 7.60 ( https://nmap.org ) at 2020-03-28 15:55 PDT
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000015s latency).
Not shown: 994 closed ports
PORT      STATE         SERVICE
631/udp   open filtered ipp
5060/udp  open filtered sip
5353/udp  open          zeroconf
Nmap done: 1 IP address (1 host up) scanned in 190.25 seconds

I ended up with the following in my /etc/network/iptables.up.rules (ports below 1024 are denied by the default rule and don't need to be included here):

# Deny all known-open high UDP ports before enabling WebRTC for canada
-A INPUT -p udp --dport 5060 -j DROP
-A INPUT -p udp --dport 5353 -j DROP
-A INPUT -s 66.228.32.0/19 -p udp --dport 1024:65535 -j ACCEPT