SaltStack VS letsencrypt

In the new style, when the tag is longer than 20 characters, an end of tag string is appended to the tag given by the string constant TAGEND, that is, two line feeds '\n\n'. When the tag is less than 20 characters then the tag is padded with pipes "|" out to 20 characters as before. When the tag is exactly 20 characters no padded is done. source: https://github.com/saltstack/salt/blob/master/salt/utils/event.py

https://github.com/saltstack/salt https://github.com/chocolatey/choco https://github.com/nextcloud https://github.com/authelia/authelia https://github.com/grafana/grafana

SaltStack

One thing that really irks me about Salt, though, is that they are very slow to fix bugs. My Salt states are littered with workarounds for bugs that have been open for multiple years. Even in basic things, like ssh authorized_keys management. Other than bug velocity, though, I've been pretty pleased with Salt.

Here are several related GitHub issues: - https://github.com/saltstack/salt/issues/54791 - https://github.com/saltstack/salt/issues/57541 - https://github.com/saltstack/salt/issues/16089

For clarity, here's the issue: https://github.com/saltstack/salt/issues/64111

Nightly builds on supported branches & master running the full test suite, producing fully tested builds. https://github.com/saltstack/salt/actions/workflows/nightly.yml

It's definitely some sort of AI script. Not this exactly, but something working off Python or scripts of thar nature. https://github.com/saltstack/salt

This seems to be not implemented in certbot, yet: https://github.com/certbot/certbot/issues/6566

If you do go with NPM or Traefik, under the covers it's using certbot to request/renew your certificates through Let's Encrypt using the DNS-01 challenge, meaning you can get wildcard certs and don't have to futz around with port forwards. Again I'd think Caddy has similar functionality, I just have not used it personally. Raw NGINX you probably don't want to try out yet considering it requires manually doing the configs

certbot won't be missed. The code quality is pretty poor.

https://github.com/certbot/certbot/issues 5000 bugs and it most of it can be replaced by much smaller tools

Here’s a good code reference (Python and rust): https://github.com/certbot/certbot

I am trying to migrate off of Linux and back to FreeBSD, but I hit a problem today. The Let's Encrypt Certbot is not installing. A bit surprising, given how important it is. So I thought I would notify the community Here is my bug report. https://github.com/certbot/certbot/issues/9394

Last release: https://github.com/certbot/certbot/releases (on 28th August 2022 = 1.29.0)

Right? It’s so ridiculous how you’re supposed to use Snap to install certbot. The (well, one of..) GitHub discussion is just beyond the pale:

https://github.com/certbot/certbot/issues/8345#issuecomment-...

It goes way beyond, since Let's Encrypt influence the ecosystem a lot and the standards that are used.

If you use Let's Encrypt, you are likely using Certbot, which means that everybody uses a tool that a central authority strongly recommends to you.

I wonder how they generate the key, for example, it may be using secp256r1: https://github.com/certbot/certbot/blob/5c111d0bd1206d864d7c...

# nginx-ingress-https.conf events { } http { include mime.types; server { listen 443 ssl; listen [::]:443 ssl; server_name sg.horlick.me; ssl_certificate /etc/letsencrypt/live/sg.horlick.me/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/sg.horlick.me/privkey.pem; # taken from https://github.com/certbot/certbot/blob/master/certbot-nginx/certbot_nginx/_internal/tls_configs/options-ssl-nginx.conf ssl_session_cache shared:le_nginx_SSL:10m; ssl_session_timeout 1440m; ssl_session_tickets off; ssl_protocols TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers off; ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384"; ssl_dhparam /etc/ssl/certs/dhparam.pem; sendfile on; tcp_nopush on; tcp_nodelay on; location / { proxy_pass http://host.docker.internal:9090/; proxy_http_version 1.1; proxy_cache_bypass $http_upgrade; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Port $server_port; } } }