fidel-perez

const carriageReturnIndicator = "⏭️"; //WARNING: There is a regexp replace that uses this literal value.
const spaceReplacerChar = " "; // ◽
const pluginClassName = "speedReadingPlugin";

function updateReadTimeEstimate(phrases, speedWPM) {
  var readTimeEstimateEl = document.getElementById("readTimeEstimate");
  readTimeEstimateEl.innerText =
    "Expected time to read the whole document at current speed: " +
    ((phrases.length * 60000) / speedWPM / 1000 / 60).toFixed(1) +
    "min.";

crisidev

#!/usr/bin/env python

import socket
import argparse
import subprocess

TCP_IP = '127.0.0.1'
TCP_PORT = 3920

DESKTOPS = {

kspeeckaert

import json
import uuid

from pathlib import Path
from urllib.parse import urlparse
from datetime import datetime

import html2text
import requests
from bs4 import BeautifulSoup

dergachev

Why You Can't Un-Root a Compromised Machine

Let's say somebody temporarily got root access to your system, whether because you "temporarily" gave them sudo rights, they guessed your password, or any other way. Even if you can disable their original method of accessing root, there's an infinite number of dirty tricks they can use to easily get it back in the future.

While the obvious tricks are easy to spot, like adding an entry to /root/.ssh/authorized_keys, or creating a new user, potentially via running malware, or via a cron job. I recently came across a rather subtle one that doesn't require changing any code, but instead exploits a standard feature of Linux user permissions system called setuid to subtly allow them to execute a root shell from any user account from the system (including www-data, which you might not even know if compromised).

If the "setuid bit" (or flag, or permission mode) is set for executable, the operating system will run not as the cur