Solved The security/acme-client port has been deleted: Removed

NuLL3rr0r

NuLL3rr0r

What happened to security/acme-client? I couldn't find any entry inside /usr/ports/UPDATING. Why FreeBSD ports team decided to remove a package without documenting it inside /usr/ports/UPDATING?
 
Why would a port have an entry in /usr/src/UPDATING ?

Perhaps you need to check usr/ports/UPDATING

forums.freebsd.org

acme-client replacement

As you may or may not know security/acme-client was removed recently, upstream stopped updating the code. I liked it, it had very little dependencies and I liked the scripts. It made integrating it really easy. What's a nice alternative for it?
forums.freebsd.org forums.freebsd.org
 
Most of my jails had it too. Acme.sh doesa good job. Certtool or so now auto-renew certificates via a cron job. The Apache MD mod, which I hope is now finalized, does monitor/assist in renewing the certs too.
 
Yeah, it's much much more elegant and simpler than acme-client. Last night, I migrated to acme.sh and like it so far. I use the webroot method + nginx. I am not sure if adding it to a cron job would suffice:

Code: 
7 22 * * * /usr/local/sbin/acme.sh --cron --home /path/to/acme/.acme.sh > /dev/null

Since I did generate the certs using:

Code: 
$ acme.sh --force --home /path/to/acme/.acme.sh --issue \
    -d seditious.games \
    -w /path/to/webroot
$ acme.sh --home /path/to/acme/.acme.sh \
    --install-cert -d seditious.games \
    --key-file       /path/to/ssl/key/seditious.games.pem  \
    --fullchain-file /path/to/ssl/fullchain/seditious.games.pem \
    --reloadcmd     "service nginx restart"

I guess I have to run the cron command in a script along with --install-cert to install certs in the dir read by nginx, and instead run that script as a cron job. Am I right?
 
As a side note, I cannot use the nginx mode since on some of my sub-domains, I run services such as gitea (nginx proxy). So, I created this rule:
Code: 
# Letsencrypt needs http for acme challenges
location ^~ /.well-known/acme-challenge/ {
    proxy_redirect off;
    default_type "text/plain";
    alias /path/to/webroot/for/all/domains/.well-known/acme-challenge/;
    allow all;
}

And then in the vhost file:

Code: 
server {
    server_tokens   off;

    listen          80;
    listen          [::]:80;
    server_name     seditious.games;

    location / {
        return 301 https://$server_name$request_uri;  # enforce https
    }

    # Error Pages
    include /path/to/nginx/conf/error;

    # Anti-DDoS
    include /path/to/nginx/conf/anti-ddos;

    # letsencrypt acme challenges
    include /path/to/nginx/conf/letsencrypt-acme-challenge;
}

server {
    server_tokens   off;

    listen          80;
    listen          [::]:80;
    server_name     *.seditious.games;

    location / {
        return 301 https://$host$request_uri;  # enforce https
    }

    # Error Pages
    include /path/to/nginx/conf/error;

    # Anti-DDoS
    include /path/to/nginx/conf/anti-ddos;

    # letsencrypt acme challenges
    include /path/to/nginx/conf/letsencrypt-acme-challenge;
}

But, it later complains, that it cannot find the certificate for sub1.domain.com, sub2.domain.com (I put all subs in one cert file as the domain.com).
 
I really don't understand.. a critical port which was still working shouldn't have been marked deprecated before removing?

Switching to acme.sh is easy but not trivial, at least requires some testing to update existing certificates without issues.

Something like two months of deprecation period would have left us the time to organize the switch instead of turning it in another emergency fix.

Moreover, people are talking to update it with OpenBSD version, so the situation could be: a perfectly working port is removed without advice, users are forced to switch to a new software, and then the port is added again updated.
 
Well you users have got legitimate beef as it was not de-orbited correctly.
But I think of the old song:
"What do you want for nothing—a rubber biscuit?" ...
 
I usually agree with this logic but not in this case.

I am a maintainer myself (of a single and very easy port, I must admit), and while I don't feel myself obligated to keep maintaining it forever, I feel myself obligated to not removing it abruptly. And my port is not a security critical one.

You're right, we are giving something for free, and this authorize us to stop doing it whenever we want, but i don't think it authorize us to do something that damage users with no reason.
 
Thanks everyone for their feedback. I guess it helps users voice to be heard by the ports tree maintainers despite the fact that we, users are not entitled to it since it is FLOSS. Nonetheless, we expect better than the FreeBSD team. We use FreeBSD due to their professionalism. I, myself maintain various ports and one of my ports has been stuck for more than two years now to get a simple update without any explanation. I have the latest version, but the committers are not responsive, unfortunately. Being responsive and communicative is what keeps a FLOSS project kicking.
 
Well first off I want to thank all port maintainers along with all developers.
Looking at that PR makes my eyes bleed. Porting Linux software to FreeBSD is not an easy task.

My philosophy is I like to accentuate the positive because any headless organization is bound to have problems.
I cringe when I see any port deleted.
 
My pleasure. Well, that's not Linux software. The developers of Wt Toolkit are professional developers who keep Linuxism out. Since the day one I used it on FreeBSD (I guess back in 2008/2009, I was buildingh it manually until I learned how to create FreeBSD ports). Their software runs even on Microsoft Windows.
 
If it don't bounce back... you go hungry.

According to the (former) maintainer, there are no known security vulns and the upstream port has not been updated. It may break with LibreSSL, but it has not yet.

If you've just run into a build problem such as

Code: 
===>>> The security/acme-client port has been deleted: Removed
===>>> Aborting update

You can get past this with pkg lock acme-client but note that as the port is no longer in the ports tree, any discovered vulnerabilities will not be reported. This should be considered a temporary solution.

I'm considering migrating to security/acme.sh myself, but I've put some effort into integrating security/acme-client into my system and am rather dreading rewriting that code.
 
gessel said:
You can get past this with pkg lock acme-client
Click to expand...

Nice tip!

At the end I'm taking a more radical approach and keeping acme-client switching the OS around!

Of course the switch was already planned and I just anticipated it, I'm not advocating to switch from FreeBSD to OpenBSD instead of changing from acme-client to some other tool (which, by the way I couldn't find).
 
Source is still available yes, but it's not being maintained. Bugs or security issues aren't going to be fixed. You're better off spending time in getting acme.sh to work.
 
I try:
1. wget https://kristaps.bsd.lv/acme-client/snapshots/acme-client.tgz
2. tar -xvzf acme-client.tgz
3. cd acme-client-0.1.16/
4. make
Code: 
cc -O2 -pipe -g -W -Wall -c acctproc.c -o acctproc.o
cc -O2 -pipe -g -W -Wall -c base64.c -o base64.o
cc -O2 -pipe -g -W -Wall -c certproc.c -o certproc.o
cc -O2 -pipe -g -W -Wall -c chngproc.c -o chngproc.o
cc -O2 -pipe -g -W -Wall -c dbg.c -o dbg.o
In file included from dbg.c:25:
./extern.h:217:24: error: expected identifier
int              checkexit(pid_t, enum comp);
                                  ^
./extern.h:218:28: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
int              checkexit_ext(int *, pid_t, enum comp);
                                      ^
1 warning and 1 error generated.
*** Error code 1

Stop.

Bad try ..
 
You must log in or register to reply here.
Back
Top