There are probably other private parts of the crates website, like the pages for developers who are uploading crates. It makes sense to just give the same error for everything, from the same logic all in one easily auditable spot.

And of course, just because all crates on the site are public now, doesn’t preclude the possibility of private crates im the future.

Only possible to authenticate with Github

They seem to be working on it

If you go to a page which doesn’t exist, one would expect to get the 404 HTTP code (not found). So let’s try when we query a crate which doesn’t exist:

This is the only one I somewhat disagree with. If you give a 403 error whenever you don’t have permissions to access a page, and a 404 whenever you access a page, it becomes possible to discover parts of the website that exist but you can’t access.

It’s because of this, that both Github and Forgejo just return 404 errors when you access a repo that doens’t exist OR it’s a private repo. A quick test with Codeberg against a repo that probably doesn’t exist gives me an error 404 and the message:

The page you are trying to reach either does not exist, has been removed or you are not authorized to view it.

(emphasis mine)

Now, I would rather see 404 errors everywhere instead of 403’s. It’s way more likely that you are encountering a repo or website path that doesn’t exist, than you lacking privileges/auth. But, 403’s everywhere is an approach I’ve seen done before and it makes sense when you understand why.

Performance, it’s slightly slower compared to Bun, but it is faster than Node. But it has sandboxing, which is neat.

Deno is pretty interesting because it has built in sandboxing. By default, no code can even access the network. Everything must be explicitly allowed, including network access and environment variables: https://docs.deno.com/runtime/fundamentals/security/

Access can be scoped pretty granularly as well, only allowing access to specific websites or env variables.

I really like this model since it offers a strong protection against secrets stealers, which have hit NPM extremely frequently. No more of malicious NPM packages scraping the whole system to find secrets.

It does have a performance tradeoff compared to Bun. Bun is (was?) the fastest, Node was the slowest, Deno was in the middle.

You can use local certs with nginx proxy manager as well. You can upload certs via the web ui.

Rather than local certs though, I would recommend buying a domain and using it locally, with https. The problem with the local cert approach outlined in the video, is that importing a root cert opens up a big security hole to MITM attacks. If an attacker gets the root certificate, they can now MITM everything else your browser is accessing. You turn the browser from one of the most secure components of a modern OS, into only as secure as the server hosting the root certificates.

The approach I would prefer, is to buy a domain, and use it locally, using DNS-01 challenges to get letsencrypt signed certificates even from within an internal network. Both Caddy and NPM have support for DNS-01 challenges.

No, they are trivial to block using techniques like deep package inspection.

In addition to that, they aren’t truly decentralized (no decentralized network really is), both rely on relay/bootstrap servers to start up the connection. So, if you block the public relay/bootstrap servers, you effectively block access to the network.

Tailscale, netbird also can traverse NAT.

Iroh (the actually pretty interesting software which the vibecoded rayfish is based on) and Yggdrassil do have their uses, but evading blocks isn’t one of them.

You want a reverse proxy. A reverse proxy reads requests to subdomains and then forwards them to ports and back.

The easiest GUI one is: https://nginxproxymanager.com/

But there is also just straight nginx, or you can use Caddy or traefik or anything else.

Yes, but it looks like the xdg.user.tags and xdg.user.comments are KDE software specific, and not part of the official spec. Meaning other softwarw probably can’t read and interact with those attributss in the same way.

This workflow is tied to KDE Plasma’s tagging feature. Moving away from KDE Plasma would likely mean abandoning parts of this workflow altogether.

It looks like these tags are stored in filesystem xattrs themself, not in dolphin or kde metadata. That is, even if you load up gnome’s file browser, or another file browser, it should still be able to read them.

Nope, it looks like the tags used are KDE specific, even though any software could theoretically implement support for reading and writing them.

https://wiki.archlinux.org/title/Extended_attributes

https://www.freedesktop.org/wiki/CommonExtendedAttributes/

Yes. Under the hood, gnome controls the power profiles daemon.

You can configure it from the cli via powerprofilesctl.

powerprofilesctl get gets the currently active mode. powerprofilesctl set performance set’s it to performance mode.

There are three modes: ‘power-saver’, ‘balanced’, ‘performance’

Yes, I do lock it down. It’s still worth securing it because “internal servers” can still get exposed and touched, even though there are less paths to them, and it’s not as punishing to slip up vs a public server. For example, One of the wireguard client devices downloads a virus, and now you have a cyberattacker with access.

Another problem is supply chain issues. If the distributor of a docker container is hacked, it’s not that bad… as long as your kernel is up to date and is protected against some of the recent vulns, that would enable someone to break out of a docker container

Blajah.zone’s lemmy instance was hacked partially becuase internal servers weren’t being held to the same security standards as the public ones:

https://pen.blahaj.zone/supakaity/weve-been-hacked

I had not patched these internal servers that nobody should have access to against this. Rebooting DB servers causes downtime, and in my hubris – I thought nobody should (nay COULD) be on my servers except me, right?

I have a comment on that post with some potential solutions, that would have cut off attack paths.

Though, I guess, it still does depend. Like if it’s just gonna you wireguarding in and no one else, then the data on your devices is probably worth more than the data on the server, so no, it wouldn’t be worth spending too much effort to secure less valuable data.

But if you are handing out internal access to people, including to some relative who keeps falling for scammers, then yeah, I’d take some time to harden the systems.

https://programming.dev/comment/24515044

Same problem is present here. Uses JWT’s for auth.

Edit:

Using jwt’s for auth isn’t bad, it’s good and quite common The problem is when they are used in place of actual bearer/cookie/session auth methods. As I understand it at least, a jwt token with a lifespan greater than 5 minutes is a red flag.

I used to use innoextract to extract the launchers, and the the system wine to run it. Although sometimes I have to run extra installers that put dlls in the right spots.

You should probably just run the installer in lutris (which ships a proton distributution) or bottles.

Edit: I can’t read smh my head.

Check this out: https://github.com/lutris/docs/blob/2b116519c5b67254733234f36ab33a60f14f1358/WineDependencies.md

I don’t use a UI.

I don’t use flux’s kustomize (there is also kustomize by kubernetes.

I use flux for installing helm charts, mostly.

Repo: https://github.com/moonpiedumplings/flux-config

It’s not up right now though. I am currently revamping it, which will also involve reorganizing the repo. I really dislike that I didn’t use (flux’s) kustomize, which is one of the things I would like to fix.

I’m on my phone rn, if I get to this post again from my computer later I will add longer/further thoughts.

Second comment, but if you need/want Caddy we can help that too. It looks like the documentation link in the github page you linked is dead, and the correct one is: https://caddyserver.com/docs/json/apps/tls/automation/policies/issuers/acme/

I found that from this page: https://caddy.community/t/how-to-use-dns-provider-modules-in-caddy-2/8148

Setup legit Let’s Encrypt as wildcard locally to test services at *example.domain.com, then put them into production on mainsite wildcard *.domain.com on VPS or similar.

Just to be clear, why wouldn’t simply provisioning a certificate for each subdomain under the wildcard work?

Like, if you have a test site test.example.domain.com, you could have nginx (using acme) create a certificate for that. And then when you move to test.domain.com, nginx would do the same thing.

Now, technically letsencrypt does have a rate limit, but it’s a fairly generous rate limit:

Up to 50 certificates can be issued per registered domain (or IPv4 address, or IPv6 /64 range) every 7 days. This is a global limit, and all new order requests, regardless of which account submits them, count towards this limit. The ability to issue new certificates for the same registered domain refills at a rate of 1 certificate every 202 minutes.

I would do my testing this way, and I didn’t hit any limits, although I was careful to keep certificates and reuse them, and to not spam.

If you need more domains with SSL than that rate limit would provide, then it would make sense to investigate Caddy with porkbun, since DNS-01 challenges are the only way to get wildcard certificates, which apply to a whole wildcard.

TeamPCP is very interesting, since they actually reused an open source secrets scanner to find secrets:

https://github.com/trufflesecurity/trufflehog

So if you wanted to know, I’d start by looking there.

Debian unstable/sid (the rolling branch) was affected. Debian is not special.

Debian stable, Red Hat, and Ubuntu LTS were not affected. They also happen to be popular on servers, because of things like this.

This specific attack was discovered early,

Debian only updates packages on a new distro release, every 4 years. Red Hat does so every 13 years. There is a huge difference between a 6+ year window to detect packages, and a less than a week’s notice because you are keeping up with the latest from upstream.

The stable distro model is broken.

I will address this one at the end, since it’s a longer point.

Distro developers are not better than upstreams at judging upstream code. Many non-security tagged bugs can become security ones.

Okay. And? We are talking about supply chain security here.

There is a huge difference between vetting packages once every 6 years, and the continuous, ongoing, toilsome process that you are made to in order to maintain systems like cargo’s build system.

despite actually shipping the compromised xz version? It’s Arch. Why? Because they didn’t patch systemd with xz support thinking they can outsmart an upstream.

The XZ utils backdoor could have easily effected any distro that uses xz for any form of root/system level service. The backdoor makers decision to not do this doesn’t actually make Arch or other distros that did this more secure. Debian stable did not receive vulnerable code in the first place. Big difference.

Distros pull from upstreams anyway (code has to exist somewhere), crates.io included.

This is because rust and crates makes it impossible to do any form of dynamic linking. Which is why some people have gripes with rust and avoid it.

But for C, Java, and other languages, it is possible for distros to ship and manage libraries, which has the benefit that the various libraries can have their security issues fixed automatically.

What makes you think JAVA or its ecosystem(s)

The Java ecosystem, and it’s various language specific package managers have lots of problems. But I am specifically talking about the Java ecosystem available from stable Linux distros, like Red Hat or Debian.

So. Why would I want a stable distro? Why would I want “old” packages? The reason is very simple: The absolute guarantee of compatibility between the security updates, of the programs themselves, and dynamically linked libraries.

If I make, say, a Java program, and tie it to Java packages available from the stable distro, when programs in that

The model of vendoring dependencies, breaks this. With Cargo (or uv or etc), the programs move very fast, and updates break things. In order to prevent their program from breaking, developers pin packages. And then, they don’t update them. This results in them shipping code with CVE’s to their users, even though the CVE has already been fixed in an upstream version.

I like to run cargo-audit, or the go equivalents on the open source projects I look at, and I almost always find vulnerabilities of varying degrees of criticallity. Here is cargo-audit ran against radicle-tui: https://gist.github.com/moonpiedumplings/7e71121b76c58ecaba4176be9bb827c4

With a mere 5 months of not being touched, there are now present CVE’s that are critical on the scoring system (radicles top repo had none yippee! and their second to top repo had a few mediums). It irritates me to see them in software that interacts with networked systems.

I only very rarely find programs that are empty of CVE’s. Usually only the most well resourced, active projects are able to keep their audit clean. It’s a lot of work —

Work that a stable distro automates. With a stable Linux distribution like Debian, I can be confident that if I make a program tied to libraries or programs that the distro provides, this stuff will automatically be patched and handled for me.

Look, you don’t have to use a stable distro on your own personal Linux desktop. I use Arch on my laptop. But for servers, not using pinned dependencies, and instead linking against libraries provided by distros means saving thousands of hours of toil doing basic cleanup of updating libraries and figuring out what the newer version of libraries broke. With a stable distro, you just do that once every six years.

One downside is that the cached file is not independently archived so it could be tampered with. Thanks for the idea.

You could have multiple researchers archive it and store copies independently. Then tampering would show up accross copies.

Unfortunately, central hosting doesn’t guarantee that it is tamper free. The host could be hacked, or could be malicious. Archive.is was caught tampering with their archived pages:

https://en.wikipedia.org/wiki/Wikipedia:Archive.today_guidance

Check out Zotero: https://www.zotero.org/

Zotero is an open source bibliography manager. It’s my main go to tool for generating works cited pages, like during essays.

But, it also has a browser extension, which can download, and archive sites or academic articles you are adding to the sources. I would then use the fulltext search that zotero provides for easy searching of sources.

Unfortunately, it’s not hosted, which would make it difficult to share.

EDIT: It does look like the server component is open source, AGPLv3: https://github.com/zotero/dataserver/

But, I cannot find any deployment instructions. But, it looks like their hosted version lets users create groups of shared items, including sharing archived snapshots of the various items.