0xabad1dea

Risk Assessment of GitHub Copilot

0xabad1dea, July 2021

this is a rough draft and may be updated with more examples

GitHub was kind enough to grant me swift access to the Copilot test phase despite me @'ing them several hundred times about ICE. I would like to examine it not in terms of productivity, but security. How risky is it to allow an AI to write some or all of your code?

Ultimately, a human being must take responsibility for every line of code that is committed. AI should not be used for "responsibility washing." However, Copilot is a tool, and workers need their tools to be reliable. A carpenter doesn't have to

dillonchanis

@layer utilities {
  .text-gradient {
    background-clip: text;
    -webkit-text-fill-color: transparent;
  }
}

jamiebuilds

async function validatePassword(password: string): string[] {
  let errors = []

  // 1. Don't regex for things you can trivially express in code
  // -----------------------------------------------------------
  // For example, we could have written this as `/^.{0,7}$/` but that's not
  // nearly as clear as checking the length of the string.

  if (password.length < 8) {
    errors.push("Password must be at least 8 characters long")

christippett

#!/bin/sh -e
IGNORE_FILES=$(ls -p | grep -v /)
TRACKING_BUCKET="$COMMIT_STATE_BUCKET/$REPO_NAME/$BRANCH_NAME"

detect_changed_folders() {
    gsutil cp gs://$TRACKING_BUCKET/LAST_COMMIT . &> /dev/null || true
    last_commit_sha=`cat LAST_COMMIT 2> /dev/null || git rev-list --max-parents=0 HEAD`
    echo "Detecting changes from last build: $last_commit_sha"
    folders=`git diff --name-only "$last_commit_sha" | sort -u | awk 'BEGIN {FS="/"} {print $1}' | uniq`
    export changed_components=$folders

mrmurphy

open Pom;

type middleware('context, 'result) =
  (Express.Request.t, Express.Response.t, 'context) =>
  pomWithError('result, Express.complete);

type handler('context) =
  (Express.Request.t, Express.Response.t, 'context) => pom(Express.complete);

let _onError500 =

mrmurphy

type pomWithError('data, 'err) = Js.Promise.t(Result.t('data, 'err));
type pom('data) = pomWithError('data, unit);

module JsPromise = {
  let make = () => {
    let resolver = ref(ignore);
    let p =
      Js.Promise.make((~resolve, ~reject as _) =>
        resolver := (a => resolve(. a))
      );

Rich-Harris

I've been deceiving you all. I had you believe that Svelte was a UI framework — unlike React and Vue etc, because it shifts work out of the client and into the compiler, but a framework nonetheless.

But that's not exactly accurate. In my defense, I didn't realise it myself until very recently. But with Svelte 3 around the corner, it's time to come clean about what Svelte really is.

Svelte is a language.

Specifically, Svelte is an attempt to answer a question that many people have asked, and a few have answered: what would it look like if we had a language for describing reactive user interfaces?

A few projects that have answered this question:

jaredly

let recv = (client, maxlen) => {
  let bytes = Bytes.create(maxlen);
  let len = Unix.recv(client, bytes, 0, maxlen, []);
  Bytes.sub_string(bytes, 0, len)
};

let parse_top = top => {
  let parts = Str.split(Str.regexp("[ \t]+"), top);
  switch (parts) {

tomwwright

# perform a fresh install of Ubuntu 17.10

# upgrade the kernel to v4.13.10
mkdir ~/kernel-v4.13.10
cd ~/kernel-v4.13.10
wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.13.10/linux-headers-4.13.10-041310_4.13.10-041310.201710270531_all.deb
wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.13.10/linux-headers-4.13.10-041310-generic_4.13.10-041310.201710270531_amd64.deb
wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.13.10/linux-image-4.13.10-041310-generic_4.13.10-041310.201710270531_amd64.deb
sudo dpkg -i *.deb

Rich-Harris

When Babel 6 came out, it was hard for a lot of packages to upgrade because it was essentially an entirely different category of thing than Babel 5. So what happened was that some packages upgraded, and some didn't — at least not straight away.

Some projects took the prima facie enlightened view that packages should expose untranspiled code, so that the consumers of that code could determine for themselves what needed to get transpiled based on the environments they supported.

That was a costly decision. If I was the author of an app that was using Babel 6, I couldn't import a library that was still using Babel 5 and shipping untranspiled code (because the configs were completely incompatible), and vice versa. Frankly, it was a bloody nuisance. We are bad at anticipating these sorts of issues. It will happen again at some point.

Adding a few extra bytes to pkg.main or pkg.module is a small price to pay for things just working. As well as avoiding the aforementioned headaches, it means that your