Git Clients Are Disappointing

stefnotch — Thu, 25 Aug 2022 12:17:00 +0000

(Yes, this applies to CLIs and GUIs)

Well, I'm just going to run you through the options

The official CLI: Quite unintuitive. Also doesn't teach you very much at all about how Git actually works, you usually have to research that yourself. Standard beginner workflow with git add . is an anti-pattern that you have to un-teach people. (It leads to people not looking at what they're committing before they commit and push it)
Alternate Git CLIs: They're proving my point. The official CLI is not something that I'd recommend. However, I don't have enough experience with the alternate CLIs, so I don't have one specific recommendation.
gitoxide deserves a mention at thit point, despite very much being a work in progress. It's one of the more interesting Git rewrites out there.

And now, time for the GUIs

One major requirement is that they use a graph view by default. One that lets you see the commits, and the branches that exist at the moment.

Mostly everything else is unwieldy for bigger projects, and ends up not mapping quite as nicely to the "make lots of branches" Git workflow.

Official Git GUI: Technically functional, but somehow manages to be worse, or rather less popular, than the CLI.
GitHub Desktop: Fails that requirement, see this closed issue
GitUI: Lovely terminal UI, fails the requirement
Lazygit: Lovely terminal UI, fails the requirement
VSCode: Fails the requirement, though there's an extension that I've not tried out yet.
Intellij: Yay, a decent-ish Git client. Major pain point at the moment is that they're using different terms for a lot of common operations, which leaves you wondering "what does that mean" and once you figure it out, congrats on successfully teaching yourself something that a single vendor uses. (aka vendor lock-in)
Git Fork: Quite lovely. One catch is that the name makes it terribly difficult to look up anything at all if you've got a question. Like seriously, try looking up "git fork three way merge".
GitKraken: That's what I use at the moment. Issues include its startup time, its price (subscription model), the fact that it's slow when discarding thousands of changed files at once, ...
Most 3rd party GUIs out there (kudos to Git for maintaining a lovely list ) are either quite limited, abandoned, un-fun to use, are expensive paid software, only work on one operating system or have some combination of factors that make it a no-go. I'd know, I've checked out most of them. If there's one that you think deserves a mention, do send it my way!

So, here we go. I think I've successfully complained about every option on the market.

Enabling COOP/COEP without touching the server

stefnotch — Thu, 05 Aug 2021 18:04:14 +0000

Or how to modify security headers clientside.

Ever since the rather impressive Meltdown and Spectre attacks, browser vendors had to clamp down on shared memory and high resolution timers. While this conveniently means that the casual user doesn't have to work about phantom trolleys, it can be an irritating restriction for a developer. Some APIs got limited, while others were completely disabled unless one does a little dance to appease the web browser.

This means that certain web-applications have an additional hurdle to overcome.

A few examples of web-applications that have this problem are in-browser video converters using ffmpeg.wasm, a web-based notebook that supports Python and multithreaded Emscripten applications.

The Problem

The following APIs are unavailable by default

SharedArrayBuffer
Atomics

To re-enable them, the site needs to be served over HTTPS^[1] and two headers need to be set. The headers, which have to be set server side^[2], are

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

This can be quite a challenge for a number of reasons. It is not always a walk in the park for a frontend developer to control the headers that the backend sends. Static frontend applications are becoming more widespread. It is quite common that one uses a CDN which simply doesn't support setting custom HTTP headers. I personally needed a solution, as I was deploying a web-based computer algebra system on GitHub pages.

Finally, do note that those headers impose some additional restrictions. The main one is that the Cross-Origin-Embedder-Policy header makes it harder to load cross-origin resources.

[1] Or be on localhost, since the requirement is that the document has to be in a secure context

[2] Those headers cannot be set using <meta http-equiv="..">, as they're not included in the whitelist.

What if I can't set the headers myself?

Service workers to the rescue!

It turns out that there is something that sits between the server serving the webpage and frontend Javascript. Service workers can intercept all requests, modify the responses and even set arbitrary HTTP headers.

First, we register our service worker in a Javascript file that gets loaded as soon as the website gets loaded. To make sure that the service worker can intercept all requests, we have to reload the page.

// main.js
if ("serviceWorker" in navigator) {
  // Register service worker
  navigator.serviceWorker.register(new URL("./sw.js", import.meta.url)).then(
    function (registration) {
      console.log("COOP/COEP Service Worker registered", registration.scope);
      // If the registration is active, but it's not controlling the page
      if (registration.active && !navigator.serviceWorker.controller) {
          window.location.reload();
      }
    },
    function (err) {
      console.log("COOP/COEP Service Worker failed to register", err);
    }
  );
} else {
  console.warn("Cannot register a service worker");
}

Then, place the service worker right next to the script above and call it sw.js. The important part is that every time the fetch event listener is invoked, we replace the response with one where the COOP/COEP headers are set. All the other parts are optional.

Do make sure that the service worker gets served from the topmost directory, right where the index.html of the website is. This makes sure that the service worker's scope includes all the files on your site.

// sw.js
self.addEventListener("install", function () {
  self.skipWaiting();
});

self.addEventListener("activate", (event) => {
  event.waitUntil(self.clients.claim());
});

self.addEventListener("fetch", function (event) {
  if (event.request.cache === "only-if-cached" && event.request.mode !== "same-origin") {
    return;
  }

  event.respondWith(
    fetch(event.request)
      .then(function (response) {
        // It seems like we only need to set the headers for index.html
        // If you want to be on the safe side, comment this out
        // if (!response.url.includes("index.html")) return response;

        const newHeaders = new Headers(response.headers);
        newHeaders.set("Cross-Origin-Embedder-Policy", "require-corp");
        newHeaders.set("Cross-Origin-Opener-Policy", "same-origin");

        const moddedResponse = new Response(response.body, {
          status: response.status,
          statusText: response.statusText,
          headers: newHeaders,
        });

        return moddedResponse;
      })
      .catch(function (e) {
        console.error(e);
      })
  );
});

What this ends up doing is

when the page gets loaded for the first time, we register the worker
then we reload the page
and finally, now that the worker is controlling everything, every request will now have the appropriate headers set

I can quite recommend using the coi-serviceworker library, which is based on this post and does exactly what is needed.

Of course the ideal solution is still to set the headers server side.

Security issue?

No, I doubt that. There is a w3c test for this. It's a way of opting in into additional security restrictions on your website.

Opting out with the same approach does not work.

Once you add the COEP header, you won't be able to bypass the restriction by using service workers. If the document is protected by a COEP header, the policy is respected before the response enters the document process, or before it enters the service worker that is controlling the document.

-- https://web.dev/why-coop-coep/

DEV Community: stefnotch

Git Clients Are Disappointing

Enabling COOP/COEP without touching the server

The Problem

What if I can't set the headers myself?

Security issue?