A method not yet mentioned is by inode, (I’ve accidentally created filenames I didn’t know how to escape at the time like -- or other command line flags/special characters)

ls -li

Once you get the inode

find . -type f -inum $inode -delete

In Linux everything is a file. So modifying files is all you really need. The hardest part is how to handle mobile endpoints like laptops, that don’t have always on connections. Ansible pull mode is what we were looking at in a POC, with triggers on VPN connection. Note we have a large Linux server footprint already managed by ansible, so it isn’t a large lift for us.

Tried this at work and discovered it only really works on vscode and probably eclipse. Other IDEs claimed support but it was found to be unusable.

I do agree mostly with your point here, but I think you can limit the scope a bit more. Mainly provide a working build environment via one of the mentioned tools, since you will need it anyway for a ci/cd pipeline. You can additionally have a full development environment that you use available for people to use if they choose. It is important that it be one regularly used to keep the instructions up to date for anyone that might want to try to contribute.

From my observations as a sys admin, people tend to prefer the tools they are familiar with, especially as you cross disciplines. A known working example is usually easy to adapt to anyone’s preferred tooling.

It’s anything acidic from what I have found/read, the pamphlet that comes with mine mentions it. You can get a strong and longer lasting effect if you take calcium carbonate (aka antacids) around the same time.

The main benefits to paying for certs are

• as many said, getting more than 90 days validity for certs that are harder to rotate, or the automation hasn’t been done.
• higher rate limits for issuing and renewing certs, you can ask letsencrypt to up limits, but you can still hit them.
• you can get certs for things other than web sites, ie code signing.

The only thing that matters to most people is that they don’t get cert errors going to/using a web site, or installing software. Any CA that is in the browsers, OS and various language trust stores is the same to that effect.

The rules for inclusion in the browsers trust stores are strict (many of the Linux distros and language trust stores just use the Mozilla cert set), which is where the trust comes from.

Which CA provider you choose doesn’t change your potential attack surface. The question on attack surface seems like it might come from lacking understanding of how certs and signing work.

A cert has 2 parts public cert and private key, CAs sign your sites public cert with their private key, they never have or need your private key. Public certs can be used to verify something was signed by the private key. Public certs can be used to encrypt data such that only the private key can decrypt it.