This guide describes how to set up an Obsidian vault that syncs across devices while maintaining a separate Git backup without interfering with the sync mechanism. This guide should work with either official Obsidian Sync solution or with unofficial sync plugins like Obsidian Livesync or Remotely Save.
In the olden days, HTML was prepared by the server, and JavaScript was little more than a garnish, considered by some to have a soapy taste.
After a fashion, it was decided that sometimes our HTML is best rendered by JavaScript, running in a user's browser. While some would decry this new-found intimacy, the age of interactivity had begun.
But all was not right in the world. Somewhere along the way, we had slipped. Our pages went uncrawled by Bing, time to first meaningful paint grew faster than npm, and it became clear: something must be done.
And so it was decided that the applications first forged for the browser would also run on the server. We would render our HTML using the same logic on the server and the browser, and reap the advantages of both worlds. In a confusing series of events a name for this approach was agreed upon: Server-side rendering. What could go wrong?
In dark rooms, in hushed tones, we speak of colours.
Security Advisories / Bulletins / vendors Responses linked to Log4Shell (CVE-2021-44228)
| javascript: Promise.all([import('https://unpkg.com/turndown@6.0.0?module'), import('https://unpkg.com/@tehshrike/readability@0.2.0'), ]).then(async ([{ | |
| default: Turndown | |
| }, { | |
| default: Readability | |
| }]) => { | |
| /* Optional vault name */ | |
| const vault = ""; | |
| /* Optional folder name such as "Clippings/" */ |
| KEYMAPOPTS="us us" | |
| HOSTNAMEOPTS="-n alpine" | |
| INTERFACESOPTS="auto lo | |
| iface lo inet loopback | |
| auto eth0 | |
| iface eth0 inet dhcp | |
| hostname alpine | |
| " | |
| TIMEZONEOPTS="-z UTC" |
| notify: | |
| if: always() | |
| name: Notify | |
| needs: | |
| - job1 | |
| - job2 | |
| - job11 | |
| - job3 | |
| - job4 | |
| runs-on: ubuntu-latest |
| #!/usr/bin/env bash | |
| source "./dock_functions.sh" | |
| declare -a apps=( | |
| '/System/Applications/Utilities/Terminal.app' | |
| '/System/Applications/Music.app' | |
| '/Applications/Google Chrome.app' | |
| '/Applications/PhpStorm.app' | |
| '/Applications/Visual Studio Code.app' |
The following describes a technique to achieve HTTP request smuggling against infrastructure behind a HAProxy server when using specific configuration around backend connection reuse. This was tested against HAProxy versions 1.7.9, 1.7.11, 1.8.19, 1.8.21, 1.9.10, and 2.0.5. Of all these tested versions, only 2.0.5 was not vulnerable out of the box, although it is when using the no option http-use-htx configuration, which reverts back to the legacy HTTP decoder. 2.1 removed the legacy decoder so it is not affected.
To actually exploit HTTP smuggling using the issue described in this writeup, the backend server(s) behind HAProxy would also have to be vulnerable in the sense they too would need to suffer from a bug, but one which parses and accepts a poorly formed Transfer-Encoding header (almost certainly violating RFC7230), and allows HTTP keep-alive.
This is how HAProxy handles a request when Transfer-Encoding and Content-Length is p
| def StandardUsernameCredentials = com.cloudbees.plugins.credentials.CredentialsProvider.lookupCredentials(com.cloudbees.plugins.credentials.common.StandardUsernameCredentials.class, Jenkins.instance, null, null); | |
| for (c in StandardUsernameCredentials) { | |
| println(c.id + ": " + c.description) | |
| } | |
| def StandardUsernamePasswordCredentials = com.cloudbees.plugins.credentials.CredentialsProvider.lookupCredentials(com.cloudbees.plugins.credentials.common.StandardUsernamePasswordCredentials.class, Jenkins.instance, null, null); | |
| for (c in StandardUsernamePasswordCredentials) { | |
| println(c.id + ": " + c.description) | |
| } |
