uacme
acme-tiny
Our great sponsors
uacme | acme-tiny | |
---|---|---|
7 | 5 | |
417 | 4,699 | |
- | - | |
4.7 | 0.0 | |
about 1 month ago | over 1 year ago | |
C | Python | |
GNU General Public License v3.0 only | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
uacme
- Dehydrated: Letsencrypt/acme client implemented as a shell-script
- Uacme: ACMEv2 client written in plain C with minimal dependencies
-
Retrospective and Technical Details on the Recent Firefox Outage
> So you're saying telemetry should be handled as a separate process that has nothing to do with the rest of the browser, and treated like a hostile service? [... T]his was a dumb bug and it is completely unreasonable to expect some kind of adversarial design "just in case a freak bug triggers on telemetry network requests".
I absolutely agree that this a dumb bug having little to nothing to do with telemetry. It is not even the first case-sensitivity HTTP/3 bug I’m personally encountering in the course of completely casual use[1].
At the same time, you know what? I’m glad you suggested this, because I certainly didn’t think of it. Yes, in an ideal world, telemetry absolutely should be a separate process (or thread, or at least not share an event loop—a separate “hang domain”, a vat[2] if you want). And so should everything off the critical path.
I’m not saying Firefox is bad for doing it differently. I’m saying it’s silly that Firefox is forced to play OS to such an extent because the actual one isn’t up to its demands.
[1] https://github.com/ndilieto/uacme/pull/11
[2] http://www.erights.org/elib/concurrency/vat.html
-
Who should consider using BSD over Linux and why?
Hmm .... not sure i'd necessarily say that's where i'm coming from. i'd be happy with a mix'n'match OS if most of the individual components were created and maintained with thought and care. (As distinct from e.g. "Over the last couple of weekends I learned Rust, and here's my first full program, an encrypted chat server. Enjoy!") Like, SQLite is not maintained by the OpenBSD project, but i believe it's generally considered to be a high-quality codebase. And i recently started using uacme on my server; i don't feel competent enough in C to comment directly on the quality of the codebase, but this and this indicate to me that the author has a clue (and in fact, i feel confident that they have far more of a clue than i do).
acme-tiny
- Write Posix Shell
-
ZeroSSL: XSS to session hijacking, stealing a private key (and password hash)
Going to throw another hat into the ring here: I use acme-tiny [1], which is a single file ACME client written in Python in under 200 lines. The idea behind it is that you can fully read and understand everything it does without spending too much time on it. I really like this approach, so I went ahead and started using it, and have been for a few years now.
[1] https://github.com/diafygi/acme-tiny
- Uacme: ACMEv2 client written in plain C with minimal dependencies
-
Certs for SSL for internal devices
Let’s Encrypt with ACME-Tiny
-
Another free CA as an alternative to Let's Encrypt
Recommendation from me as well. Have been using this script for multiple years now without a single issue. The minimal code is awesome for avoiding unnecessary external dependencies and complexity.
Be sure to use the latest version from https://github.com/diafygi/acme-tiny though :-)
What are some alternatives?
acme.sh - A pure Unix shell script implementing ACME client protocol
win-acme - A simple ACME client for Windows (for use with Let's Encrypt et al.)
letsencrypt - Certbot is EFF's tool to obtain certs from Let's Encrypt and (optionally) auto-enable HTTPS on your server. It can also act as a client for any other CA that uses the ACME protocol.
dehydrated - letsencrypt/acme client implemented as a shell-script – just add water
Posh-ACME - PowerShell module and ACME client to create certificates from Let's Encrypt (or other ACME CA)
acme-dns - Limited DNS server with RESTful HTTP API to handle ACME DNS challenges easily and securely.
certify - Professional ACME Client for Windows. Certificate Management UI, powered by Let's Encrypt and compatible with all ACME v2 CAs. Download from certifytheweb.com
acme-dns-server - Simple DNS server for serving TXT records written in Python
acme-companion - Automated ACME SSL certificate generation for nginx-proxy
dehydrated-bigip-ansible - Ansible based hooks for dehydrated to enable ACME certificate automation for F5 BIG-IP systems