dgl

Just looking for "const _0x112" as an IOC seems a bit false positive prone: https://github.com/search?q=%2Fconst+_0x112%2F+lang%3Ajs&typ... (most of that code is pretty dodgy obviously, but it's not unique enough to identify this).

It's not; the git format defines it as a positive integer, see git help commit:

    DATE FORMATS
       The GIT_AUTHOR_DATE and GIT_COMMITTER_DATE environment variables support the following date formats:

       Git internal format
           It is <unix-timestamp> <time-zone-offset>, where <unix-timestamp> is the number of seconds since the UNIX epoch.

Changing a commit's timestamp is as simple as:

    $ git commit --amend --date='1970-01-01T00:00:00' --reset-author
    [main 6e1d001] test
     Date: Thu Jan 1 00:00:00 1970 +0000
     1 file changed, 1 insertion(+)

But dates before 1970 really don't work (in some cases it gives "fatal: invalid date format"):

    TZ=UTC git commit --amend --date='1969-12-31T23:59:59Z' --reset-author
    [main 47e54f0] test
     Date: Mon Dec 31 23:59:59 2012 +0000
     1 file changed, 1 insertion(+)

Chrome can also import/export in this format, chrome://bookmarks, dots menu at the top right, export bookmarks.

The file it generates has:

    <!DOCTYPE NETSCAPE-Bookmark-file-1>

Not exactly, but close, the BBC made Micro Men (2009) which covers the whole era, in a relatively accurate way... https://en.wikipedia.org/wiki/Micro_Men

I don’t really want to give it credit by linking to it, but this seems to refer to putty[.]org which is using its search ranking to push things unrelated to PuTTY.

> […] isn't any particular risk in a world of letsencrypt where an attacker (who gained access to that box) could simply request a new SSL certificate

You can use CAA records with validationmethods and accounturi to limit issuance, so simply access to the machine isn’t enough. (E.g. using dns and an account stored on a different machine.)

Unless you're using ECH (encrypted client helo) the endpoint is obscured (known keys), not concealed.

PS: HAProxy definitely can do this too, something using req.ssl_sni like this:

   frontend tcp-https-plain
       mode tcp
       tcp-request inspect-delay 10s
       bind [::]:443 v4v6 tfo
       acl clienthello req.ssl_hello_type 1
       acl example.com req.ssl_sni,lower,word(-1,.,2) example.com
       tcp-request content accept if clienthello
       tcp-request content reject if !clienthello
       default_backend tcp-https-default-proxy
       use_backend tcp-https-example-proxy if example.com

Then tcp-https-example-proxy is a backend which forwards to a server listening for HTTPS (and using send-proxy-v2, so the client IP is kept). Cloudflare really isn't doing anything special here; there are also other tools like sniproxy[1] which can intercept based on SNI (a common thing commerical proxies do for filtering reasons).

[1]: https://github.com/ameshkov/sniproxy

Clients supporting QUIC usually also support HTTPS DNS records, so you can use a lower priority record as a failover, letting the client potentially take care of it. (See for example: host -t https dgl.cx.)

That's the theory anyway. You can't always rely on clients to do that (see how much of the HTTPS record Chromium actually supports[1]), but in general if QUIC fails for any reason clients will transparently fallback, as well as respecting the Alt-Svc[2] header. If this is a planned failover you could stop sending a Alt-Svc record and wait for the alternative to timeout, although it isn't strictly necessary.

If you do really want to route QUIC however, one nice property is the SNI is always in the first packet, so you can route flows by inspecting the first packet. See cloudflare's udpgrm[3] (this on its own isn't enough to proxy to another machine, but the building block is there).

Without Encrypted Client Hello (ECH) the client hello (including SNI) is encrypted with a known key (this is to stop middleboxes which don't know about the version of QUIC breaking it), so it is possible to decrypt it, see the code in udpgrm[4]. With ECH the "router" would need to have a key to decrypt the ECH, which it can then decrypt inline and make a decision on (this is different to the TLS key and can also use fallback HTTPS records to use a different key than the non-fallback route, although whether browsers currently support that is a different issue, but it is possible in the protocol). This is similar to how fallback with ECH could be supported with HTTP/2 and a TCP connection.

[1]: https://issues.chromium.org/issues/40257146

[2]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...

[3]: https://blog.cloudflare.com/quic-restarts-slow-problems-udpg...

[4]: https://github.com/cloudflare/udpgrm/blob/main/ebpf/ebpf_qui...

Here's an example of a phish actually using it: https://abyssdomain.expert/@filippo/114868224898553428 (also note "cat" is potentially another antipattern, less -U or cat -v is what you want).

https://radar.cloudflare.com/routing might be of interest for aggregated data that doesn't require a complete understanding of the internet. The global looking glass that bgp.tools has is pretty powerful too, but it gives you a lot of data, so if you don't know what you're looking for or what it should look like it's hard to say something is wrong.

Except it is sourced from /etc/rc, and that’s a shell script which obviously depends on the shell and some other pieces. If you want an immutable base you kind of need to make the whole (base) system immutable (and that is possibly best designed as such to start with).

I don’t think this is “security vs convenience”, I’d more argue it’s possible to think you’ve made this secure but you’ve missed something and haven’t configured it to be as secure as you think. An approach like others have suggested with remote logging is at least easier to reason about.

Same. I used to read a bunch of things offline using Instapaper, but that was when I commuted on the tube (no signal, then), now I hardly commute. I still save things (in a text file) but try to save them with grepable keywords, so I can find them more easily later.

I'm not privy to the exact communications that happened, but per the Ubuntu changelog they prepared a patch a week ago[1] (which is about the normal timeline for notification per[2]). Homebrew is not on the distros list, so likely wouldn't have got an early notification. Arch is, but remember "The Arch Security Team is a group of volunteers"[3].

[1]: https://launchpad.net/ubuntu/+source/git/1:2.43.0-1ubuntu7.3

[2]: https://oss-security.openwall.org/wiki/mailing-lists/distros

[3]: https://wiki.archlinux.org/title/Arch_Security_Team

I've adjusted that paragraph to make it more clear how writing a file can lead to code execution.

Submodules can be any URL (and recursive), so for GitHub to block this totally would require them to crawl other forges (and some URLs could be private URLs, but GitHub likely can't tell that apart from an attacker who is just blocking GitHub). So the risk is GitHub could say they are blocking this and give a false sense of security.

Some previous bugs have resulted in validation added to git fsck, but because clone URLs can't change after the submodules are initialised that's not going to have any benefit here. (There were some defence-in-depth measures discussed, there's definitely a few things that can be improved here.)

With make allnoconfig it also takes <30s on a recent-ish Intel CPU (12th gen; i7 12700). As low as 20s if it's cached and with make -j20.

ChromeOS has a quite interesting design to do this: https://www.chromium.org/chromium-os/chromiumos-design-docs/...

Essentially: keep some minimum values for time. Then do a single HTTPS request, ignore the validation of the certificate's date to start with, but use the Date header to later validate it against minimum / maximum. This has the advantage it's still a HTTPS request, so can't be MiTM'd and depending on implementation it can validate the time quite well (even if the device has run out of power it can have saved a recent timestamp on disk, so with regular use of the device an old certificate won't be valid, keeping the main useful property of certificates having validity periods).

I don't believe it does this, but you could do this without DNS as 8.8.8.8, etc already have IP address certificates:

    curl -sI https://1.1.1.1 | grep -i '^date:'

    curl -sI https://8.8.8.8 | grep -i '^date:'

    curl -sI https://9.9.9.9 | grep -i '^date:'

It would need a custom tool though, as curl only has --insecure, not a way to avoid just the notBefore / notAfter validation of the cert.

(This is not the only thing to use this technique, OpenBSD's ntpd has a way to contrain time based on HTTP headers: https://man.openbsd.org/ntpd.conf#CONSTRAINTS -- the default ntpd.conf ships with Quad9 configured via IP address.)

The ChromeOS terminal (hterm[1]) is actually a pretty good terminal, so even a terminal might justify a browser context. Blink[2] on iOS for example uses it.

[1]: https://hterm.org/ (although in the way they do Google seems to have lost interest in updating that site and the GitHub repo, there's still fixes in the upstream Chromium repo)

[2]: https://blink.sh

  Sorry, you have been blocked
  You are unable to access daviey.com

Looks like Cloudflare has decided the whole thing is dodgy. Or doesn't like my IP address...

Don't use Docker, use podman (which has a registries.conf for this, with many settings). You can then use podman-docker to have command line Docker compatibility. Podman is more secure than Docker too, by default it runs as a user, rather than as root.

Unfortunately this makes a mistake by using a short commit ID: "(e.g. a5b3abf)"

That's not a full commit ID, so it can still result in a mutable reference if either someone can find a clash[1] or if they can push a tag with that name and it takes priority in the context it is used (this is somewhat complex, e.g. GitHub prohibits pushes of branches and tags which are exactly 40 hex characters long, but other services may not).

[1]: https://people.kernel.org/kees/colliding-with-the-sha-prefix...

Getting the tree (at the root) is only a few requests (get the refs or HEAD, get the relevant commit, get the tree ID from that). If pack files aren't involved then that's literally 3 requests. Pack files make this more complex, but careful caching and range requests could reduce that to as few as around 5-8 extra requests (doing binary searching via HTTP range requests). I don't think even libgit2 has APIs for range requests on pack files though, so this would need a special library (or patching libgit2...).

There's also various optimizations on the git side like bitmaps[1] and commit-graphs[2]. If this a bare repo on the server side it shouldn't be a problem to make sure it is in a particular format with receive hooks.

That's just displaying a file listing though. Displaying what GitHub displays with the last change of each file is more complex, maybe the commit graph could be used so the client wouldn't have to fetch everything itself.

  [1]: https://git-scm.com/docs/bitmap-format
  [2]: https://git-scm.com/docs/commit-graph

Strangely not including the scheme doesn't seem to consistently work on an iPhone when in uppercase, a string like "FOO.COM/BAR" does open as a URL, but a string like "FOO.UK/BAR" does a search. I think it's best to include the full HTTPS:// prefix (and I don't think it being uppercase really matters, I'd be surprised if that breaks anything).

Some discussion happened here about that when it was in draft: https://news.ycombinator.com/item?id=27628178

tl;dr: It is sadly not the most efficient encoding (and they missed an opportunity to make it actually base41, which could have been URL safe) -- as defined it only needs 41 characters (as 41^3 > 2^16).

The RFC is also not standards track, it's just "Category: Informational".

I think a better approach is to understand there are many circumstances where different sets of characters make sense for encoding data. There's no need to write an RFC, instead define a custom alphabet for them, using something like base-x[1].

[1]: https://github.com/cryptocoinjs/base-x

This won't work in most cases inside a Kubernetes pod, as the default seccomp policies don't allow creating namespaces within them. You can obviously relax the seccomp policies, but at that point you can also just give yourself the capabilities.

There are eBPF tools which will work, for example https://inspektor-gadget.io/docs/latest/gadgets/trace_ssl

It is quite simple to use eBPF with uprobes to hook library calls, for example: https://github.com/iovisor/bcc/blob/master/tools/sslsniff.py

The downside is this doesn't work with anything not using OpenSSL, there are projects like https://github.com/gojue/ecapture which have interceptors for many common libraries, but the downside is that needs different code for each library.

I think providing a TLS certificate is fine for the use cases of the tool; most tools won't be doing certificate pinning, but ecapture does support Android where this is more likely.

One name for it is PESOS[1] ("Publish Elsewhere, Syndicate (to your) Own Site"), although that doesn't necessitate it be static, but requiring it be static is mixing the implementation with the user experience anyway.

[1]: https://indieweb.org/PESOS

There definitely have been CVEs in Terminal.app, over many years:

- https://www.cve.org/CVERecord?id=CVE-2008-0042

- https://www.cve.org/CVERecord?id=CVE-2002-1898

- https://infocon.org/cons/Disobey/Disobey%202017/Mikko%20Kent... [video, I can't find a reference to that in Apple's release notes]

- There is also https://seclists.org/oss-sec/2018/q1/216 -- which led to a vague credit for Federico Bento in https://support.apple.com/en-ng/103758 proving they don't give everything CVEs (fine, but when the issue is public already it would be helpful to have a bit more detail).

I reported https://dgl.cx/2023/09/ansi-terminal-security#apple-terminal... to Apple ~2 years ago and they still haven't fixed it. It's not as serious as some vulnerabilities though and likely doesn't deserve a CVE, would be nice if they fixed it though.

(Finding this can be hard because Apple only link to release notes for currently supported versions, the pages are still around if you know the URL or you can find them via searches if they happen to be indexed still.)

To me this is actually one of the attractive aspects of Wireguard compared to some other VPNs, it doesn't try to manage everything within the tool and delegates to the host's normal routing mechanisms. However it still by default conflates AllowedIPs and the routing table -- you can actually separate them (Table=off with wg-quick) and then manually add routes.