Please do a release

[someone-somenet-org]

It has been almost 2 years since the last release and people will feel like this project died

(Please do at least 1 release every 6 months, even if nothing seriously changed)

[bllfr0g]

Agreed! Is this project still alive or is it abandoned?

…

On Jul 30, 2024, at 09:27, Someone ***@***.***> wrote: It has been almost 2 years since the last release and people will feel like this project died (Please do at least 1 release every 6 months, even if nothing seriously changed) — Reply to this email directly, view it on GitHub <#941>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJO74S4UAFRYY544A2ACAILZO65G5AVCNFSM6AAAAABLWXGEVKVHI2DSMVQWIX3LMV43ASLTON2WKOZSGQZTQMRSG4YTCOI>. You are receiving this because you are subscribed to this thread.

[polyzen]

It would be nice not to have to backport 4fd777e.

The reasoning you have given, however, is not a good reason for cutting releases, and creates needless churn and work for people packaging this software.

[lukas2511]

Project is not abandoned, I'm regulary checking that everything still works and keep up to date with changes with the ACME protocol.

I'm in a weird position where I started rewriting dehydrated a few times in different styles, but abandoned those rewrites because they just didn't seem good enough, but unfortunately that took away time to actually make changes to the original codebase... The reason for the rewrites is that a) I want to implement some features that would be really messy to implement in the current code (mostly automation and logging stuff) and b) I want something more modular, so changes could be easier tracked and parts of the code tested using automated means.

I guess I should just re-prioritize working on the existing code instead... at least that's something that's proven stable.

[someone-somenet-org]

I know that feeling ... I had sooo many projects which I wanted to fully rewrite ... and ... I abandoned all of the rewrites.

The reasoning you have given, however, is not a good reason for cutting releases, and creates needless churn and work for people packaging this software.

We will have to agree to disagree, its imo much more important to look alive, to attract new users and possibly contributors and package-maintainers.

[bllfr0g]

My experience is incremental change is more likely to succeed. If you plan to rewrite the whole thing from scratch — it’s unlikely to happen. Instead, refactor parts of it at a time. Little by little — and before you know it, the whole thing will be done!

…

On Jul 30, 2024, at 11:56, Someone ***@***.***> wrote: I know that feeling ... I had sooo many projects which I wanted to fully rewrite ... and ... I abandoned all of the rewrites. The reasoning you have given, however, is not a good reason for cutting releases, and creates needless churn and work for people packaging this software. We will have to agree to disagree, its imo much more important to look alive, to attract new users and possibly contributors and package-maintainers. — Reply to this email directly, view it on GitHub <#941 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJO74SZPEE6VMO74UFWW7JTZO7OUPAVCNFSM6AAAAABLWXGEVKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJZGAYDKMJSHE>. You are receiving this because you commented.

[someone-somenet-org]

My experience is incremental change is more likely to succeed. If you plan to rewrite the whole thing from scratch — it’s unlikely to happen. Instead, refactor parts of it at a time. Little by little — and before you know it, the whole thing will be done!

This doesnt work if you want to change the language, tho. :(

[lukas2511]

My experience is incremental change is more likely to succeed. If you plan to rewrite the whole thing from scratch — it’s unlikely to happen. Instead, refactor parts of it at a time. Little by little — and before you know it, the whole thing will be done!

This doesnt work if you want to change the language, tho. :(

Language and dependencies will definitively stay the same. I have no interested in writing an ACME client in a different language, even though that would probably be a lot easier than doing it in bash 🙃

[j3g]

I have to admit I am here looking at issues to see if this project is abandoned. Any small release gives everyone assurances that the project is active. Thanks for all your work! I'm a fan!!

[EdNett]

Hi, I'm using an implementation of dehydrated which states that it is version 0.7.2 - and it is not renewing certs at all. Is there really a version 0.7.2 of dehydrated? (I can't find any mention of it here)! Can you confirm this please ? Thanks

This is the error produced by version "0.7.2":

• Checking domain name(s) of existing cert... unchanged. + Checking expire date of existing cert...
• Valid till Sep 20 01:18:07 2024 GMT (Less than 30 days). Renewing! + Signing domains... + Generating private key... + Generating signing request...
• Requesting new certificate order from CA... + ERROR: An error occurred while sending post-request to https://acme-v02.api.letsencrypt.org/acme/new-order (Status 400)
  Details: HTTP/2 400 server: nginx date: Fri, 27 Sep 2024 08:02:11 GMT content-type: application/problem+json content-length: 107 boulder-requester: 1889822956
  cache-control: public, max-age=0, no-cache link: ;rel="index" replay-nonce: PqaU5B9M8P8gx2hEbSRbsm3g5REGoLU--C0KocK9blY5BHT_aGo
  { "type": "urn:ietf:params:acme:error:malformed", "detail": "JWS verification error", "status": 400 }

I noticed that the CURL version used does not include zstd compression - is that necessary for using dehydrated?
This is the CURL used:
non-working :

curl --version
curl 8.9.1 (x86_64-pc-linux-gnu) libcurl/8.9.1 OpenSSL/3.0.15 zlib/1.2.11 brotli/1.0.9 libidn2/2.3.0 libpsl/0.21.0 nghttp2/1.43.0 librtmp/2.3 OpenLDAP/2.4.57
Release-Date: 2024-07-31
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt pop3 pop3s rtmp rtsp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli HSTS HTTP2 HTTPS-proxy IDN IPv6 Largefile libz NTLM PSL SSL threadsafe TLS-SRP UnixSockets

Should CURL include HTTP/1.1 also to work properly?

[taam]

The currently latest release (v0.7.1) seems to be broken when using the current stable versions of OpenSSL >= v3.2.0 due to #924, which was apparently fixed by #923 almost a year ago, but not released so far. More and more distros upgrade to OpenSSL v3.3.x causing problems, dehydrated is effectively broken on my system now (when using regular system packages).

Related OpenSSL issue (I guess), which could lead to a fix for this as well: openssl/openssl#25125