8 ms·

Certbot deprecates operating system packages, “standardizes” on snaps

56 points by JetSpiegel 6y ago

JetSpiegel 6y ago
This was mentioned 2 months ago, but without traction. https://news.ycombinator.com/item?id=25141524 https://news.ycombinator.com/item?id=25141524 This is a ridiculous requirement for a glorified Python script, over-engineering at its worst.
- mmastrac 6y ago
  This seems unnecessarily hostile. Certbot is a complex beast that generates TLS configurations, has multiple plugins that likely require specific system configuration, and is I think charitably more than "a glorified Python script". The rationale makes sense for me: "While the Certbot team tries to keep the Certbot packages offered by various operating systems working in the most basic sense, due to distribution policies and/or the limited resources of distribution maintainers, Certbot OS packages often have problems that other distribution mechanisms do not. The packages are often old resulting in a lack of bug fixes and features and a worse TLS configuration than is generated by newer versions of Certbot. They also may not configure certificate renewal for you or have all of Certbot’s plugins available. For reasons like these, we recommend most users follow the instructions at https://certbot.eff.org/instructions https://certbot.eff.org/instructions and OS packages are only documented here as an alternative."
  - bccdee 6y ago
    A distro-independent avenue for distribution could be important, but surely we can do better than snapd.
    - floatingatoll 6y ago
      Have we done better, or is snapd the best option for their needs as of today?
      - akvadrako 6y ago
        Snapd is not a solution to anything. It might be distro-agnostic, but it's tied to Canonical. The server is closed source and the client doesn't support multiple servers.
      - lokedhs 6y ago
        Flatpak, probably. I'm not saying Flatpak is great, but it's the best we have, in my opinion. That said, having published one application on Flathub, packaging Flatpak is not a great experience, especially when the two major repositories: Flathub and Fedora both use two completely different build processes.
        floatingatoll 6y ago
        Is Flatpak better than snapd, if we set aside that one is ‘open’ and one is ‘closed’ and evaluate them by the merits of their functionality in service of the goal?
        bccdee 6y ago
        Yeah flatpak is much more mature, as I understand it.
      - JetSpiegel 6y ago
        AppImage? I don't see the need for much sandboxing, since certbot requires to have the keys to the kingdom anyway. systemd can whitelist a single folder for certbot to have write permissions.
  - JetSpiegel 6y ago
    > This seems unnecessarily hostile. Certbot is a complex beast that generates TLS configurations, has multiple plugins that likely require specific system configuration, and is I think charitably more than "a glorified Python script". I didn't meant it as a knock on certbot, which I use and cherish. It's just not something that I would install and entire parallel package management system over, lest of all some ugly thing like snap.
  - rstuart4133 6y ago
    > This seems unnecessarily hostile. Certbot is a complex beast that generates TLS configurations, has multiple plugins that likely require specific system configuration, and is I think charitably more than "a glorified Python script". Yeah, it is complex. Far too complex for what it does. What it does is implement a not particularly complex IETF protocol between your server and letsencrypt's servers, and run a few of your scripts when the protocol wants something done, like "install DNS entry". In fact the protocol is so simple a bash script can do it. Dehydrated https://dehydrated.io/ https://dehydrated.io/ is just that - a bash script that implements ACME. It also is in Debian. I moved to dehydrated when certbot was slow to implement DNS wildcards. The nice thing about simplicity is it infects everything else: the document becomes simple, which is nice because I had to read certbot's doco several times just to figure out what scenario would work for me. And distribution packaging becomes simple, so no snap's needed. And installation becomes simple.
prepperdev 6y ago
snaps are tied to the proprietary Ubuntu store and they are not available on all of the Linux flavors. For instance, I don't see snapd on Alpine Linux: $apk search snapd $ Not cool, I think.
- deleted 6y ago
  [deleted]
- lstamour 6y ago
  An alpine Linux core dev appears to maintain the alpine package for Certbot. I don’t see it being deprecated anytime soon. The snap is very different and relies on systemd which isn’t commonly found in Alpine.
koolba 6y ago
This has likely been asked and answered before, but why not write something like this in something that can be statically compiled like go? Isn’t the whole thing just a couple of web requests and cert operations?
- bryogenic 6y ago
  https://go-acme.github.io/lego/ https://go-acme.github.io/lego/ is exactly that. This is the client/library underneath traefik's batteries included version of let's encrypt certs.
  - koolba 6y ago
    Oh that’s exactly what I’m talking about. No funky deps. No virtualenv. No python versions. That looks perfect.
- linsomniac 6y ago
  I switched over to acme.sh, a bash version. I wasn't holding out much hope when I first tried it, but honestly it's worked great!
sliken 6y ago
Wow, of all the standards why something proprietary like snaps? How about flatpak? Or anything out open?
- akvadrako 6y ago
  I'm not sure flatpak works for services, but certainly docker would make more sense.
Havoc 6y ago
Literally just switched from Ubuntu to Debian to get away from snaps
- njsubedi 6y ago
  Same here but Let’s Encrypt suggests you install snap on Debian and use snap to install certbot.
- ryebit 6y ago
  Linux Mint has even removed snap, which is impressive since they're downstream from Ubuntu. After hearing some of the issues with it (here and elsewhere), I'm kinda grateful to them for making the effort. Though this concerns me -- I use certbot on some debian servers, I hope that at least stays up to date.
  - lstamour 6y ago
    Debian is still on version 0.x when the snap is at 1.1 ... this is one of those cases where the Debian stable branch is too stable when you need to ship software that interacts with a lot of remote APIs the way the certbot-dns packages do. It’s impossible to use the old Debian versions with the more secure API tokens from CloudFlare, for example.
    - hlieberman 6y ago
      The certbot-dns packages are certainly the most fragile part of the process -- however, I don't have any bug reports showing that the version in stable is currently broken for any of the dns plugins. If you're experiencing that, please file a bug against them and I can look into having a stable backport done for them.
      - lstamour 6y ago
        I’ll see what I can do, I’m not familiar with Debian package bug tracking. For reference, the incompatibility I faced was for the CloudFlare DNS plugin, which added support for API Tokens that had granular permissions somewhere between version 0.23 distributed in stable and 1.11 distributed via snap. Certbot docs and CloudFlare docs both encourage you to use API tokens instead of account-wide API secrets and the previous install instructions for wildcard DNS support suggested installing the CloudFlare DNS plugin by default on the Certbot site. As CloudFlare is used by a lot of folks for DNS, and was a suggested default install, I’m probably not the only one that encountered problems setting it up, without a backport available for a newer package of Certbot.
jdcaron 6y ago
Skip Certbot and use the more powerful and versatile tool acme.sh http://acme.sh http://acme.sh
- fanf2 6y ago
  My favourite ACME client is dehydrated https://github.com/dehydrated-io/dehydrated https://github.com/dehydrated-io/dehydrated
msturgill 6y ago
The Docker images are an option as well: https://hub.docker.com/r/certbot/certbot/ https://hub.docker.com/r/certbot/certbot/
ohazi 6y ago
Snaps require you to allow each publisher to automatically push arbitrary software updates to your machine, and snap deliberately does not allow you to disable this misfeature. It's not a bug or an oversight -- it's part of the design of snap, and it's not going to change. Handing out the keys to the kingdom like this is supremely annoying on a desktop (e.g. Windows 10), but it's completely unacceptable on a server. This is a terrible move, and they should absolutely walk it back.
- lstamour 6y ago
  I agree — the auto-updating nature of Snaps are a problem without an easy solution: https://askubuntu.com/questions/930593/how-to-disable-autorefresh-in-snap https://askubuntu.com/questions/930593/how-to-disable-autore... But I would also point out that on stable Debian it’s near impossible to deploy Certbot because the versions available are too old, especially the plugins. I’ve been routinely installing the snap instead because it’s a quick and easy way to deploy the service at the latest version. The only other alternative to suggest is to request the Certbot project deploys custom deb repos or similar. But can we expect that of every project? Perhaps we need a new standard to replace snap, if so the only folks I can see large enough to promote it would be GitHub... Since that’s unlikely to happen, maybe just noting the auto-update “feature” more prominently in their is all they should need to do?
  - erik_seaberg 6y ago
    Too old in what way? Is the Debian stable version relying on something that Let’s Encrypt is deprecating?
    - lstamour 6y ago
      I’m not sure, but it’s possible. The version in stable was 0.31 or so, while the version in snap and unstable/sid is 1.11. The specific incompatibility I faced was for the CloudFlare DNS plugin, which added support for API Tokens that had granular permissions somewhere between the 0.23 version in stable and the current version of the plugin at 1.11. Current Certbot docs and CloudFlare docs both encourage you to use API tokens instead of account-wide API secrets and the previous install instructions for wildcard DNS support suggested installing the CloudFlare DNS plugin by default on the Certbot site.
linsomniac 6y ago
Just to clarify something I think a lot of replies don't understand: The Ubuntu Certbot packages have been horribly broken for well over a year, probably at least two. The PPA for Certbot includes updates of a lot of OS packages, with with incompatibilities with other Ubuntu provided packages. I've spent hours tracking down and fixing the problems that have come from installing certbot via apt. Usually, I'm much more a fan of native packages than snaps or similar, but in this case it makes a lot of sense. Here is a link to the Github Issue: https://github.com/certbot/certbot/issues/5234#event-3691151021 https://github.com/certbot/certbot/issues/5234#event-3691151... (Edit: Adding issue link)
- hlieberman 6y ago
  Hello! I formerly maintained this PPA before turning it over to some of the Ubuntu people. It's my understanding that certbot is going to be migrated out of universe soon and into the main Ubuntu archive. That will cause it to gain full support from Canonical. Either way, we will continue to support certbot in Debian (upstream of Ubuntu, if downstream from /actual/ upstream) indefinitely. The Ubuntu maintainers and I work closely on packaging.
  - linsomniac 6y ago
    Thanks for your work on that. I imagine it will be easier moving forward as most of the issues seemed to be related to pulling in newer versions of Python packages, which broke supplied versions of other packages (boto-related tools ISTR were breaking).
- rlpb 6y ago
  > The Ubuntu Certbot packages have been horribly broken for well over a year, probably at least two. I think you're mistaken. The Ubuntu Certbot packages are maintained and work fine. What you're referring to is the PPA, which is no longer required (since Ubuntu's distribution-shipped certbot packages have worked fine for a long time now). Or, if not, can you point to specific issues with Ubuntu's own certbot packages please?
  - 6y ago
rascul 6y ago
I'll stop using certbot before I install snap.
ivan_ah 6y ago
If y'all want to try a high-magic solution based on a single-host docker-compose setup with traefik 2+ as ingress, here is the paragraph for configuring Let's encrypt certs: https://github.com/rocdata/rocserver/blob/main/docker-compose.yml#L5-L27 https://github.com/rocdata/rocserver/blob/main/docker-compos... It works great. Host just needs to have ports 80 443 open and docker installed: https://github.com/rocdata/rocserver/blob/main/fabfile.py#L239-L264 https://github.com/rocdata/rocserver/blob/main/fabfile.py#L2... PS: In case I can save anyone days of debugging, if you want to run a wordpress container using this setup, you'll need to do some manual config to convince wp it's running in HTTPS mode, see https://wordpress.org/support/article/administration-over-ssl/#using-a-reverse-proxy https://wordpress.org/support/article/administration-over-ss...
- ivan_ah 6y ago
  Updated link to traefik container config: https://github.com/rocdata/rocserver/blob/main/docker-compose.prod.yml#L5-L27 https://github.com/rocdata/rocserver/blob/main/docker-compos... (link changed because only need SSL certs in prod -- so moved to a prod-specific docker-compose file)
soraminazuki 6y ago
Is there anything out of the ordinary here? Most upstream projects don't officially support distro packages and distros don't support non-distro packages. It's been that way for as long as I can remember.
hlieberman 6y ago
As the maintainer of certbot for Debian, I promise you that there's no intention of deprecating the certbot packages that exist in the archive. The EFF fully supports this decision and has promised to continue to assist. Their recommendation for snaps is meant to target new and inexperienced users who may not understand why they are not getting the latest software when they see it was updated "on the website". If any of you have concerns specifically about certbot on Debian, please feel free to contact me directly at my username @debian.org.
- ohazi 6y ago
  Good to hear, and thanks for your work on this!
- mariopal 6y ago
  Thanks for your work!
- traveler01 6y ago
  Thank you! I was concerned I'd have to install Snap on my Debian server.
- detaro 6y ago
  Giving new and inexperienced users yet another thing to install (and potentially break) feels like the wrong tradeoff IMHO. But good to know it'll continue to be packaged (even though I didn't expect anything else from Debian). Thanks for your work!
solarkraft 6y ago
So the EFF, an organization I thought stood for promoting digital freedom, is essentially promoting proprietary software? Looks questionable to me.

56 points by JetSpiegel 6y ago

This was mentioned 2 months ago, but without traction. https://news.ycombinator.com/item?id=25141524 https://news.ycombinator.com/item?id=25141524 This is a ridiculous requirement for a glorified Python script, over-engineering at its worst.

mmastrac 6y ago
This seems unnecessarily hostile. Certbot is a complex beast that generates TLS configurations, has multiple plugins that likely require specific system configuration, and is I think charitably more than "a glorified Python script". The rationale makes sense for me: "While the Certbot team tries to keep the Certbot packages offered by various operating systems working in the most basic sense, due to distribution policies and/or the limited resources of distribution maintainers, Certbot OS packages often have problems that other distribution mechanisms do not. The packages are often old resulting in a lack of bug fixes and features and a worse TLS configuration than is generated by newer versions of Certbot. They also may not configure certificate renewal for you or have all of Certbot’s plugins available. For reasons like these, we recommend most users follow the instructions at https://certbot.eff.org/instructions https://certbot.eff.org/instructions and OS packages are only documented here as an alternative."
- bccdee 6y ago
  A distro-independent avenue for distribution could be important, but surely we can do better than snapd.
  - floatingatoll 6y ago
    Have we done better, or is snapd the best option for their needs as of today?
    - akvadrako 6y ago
      Snapd is not a solution to anything. It might be distro-agnostic, but it's tied to Canonical. The server is closed source and the client doesn't support multiple servers.
    - lokedhs 6y ago
      Flatpak, probably. I'm not saying Flatpak is great, but it's the best we have, in my opinion. That said, having published one application on Flathub, packaging Flatpak is not a great experience, especially when the two major repositories: Flathub and Fedora both use two completely different build processes.
      - floatingatoll 6y ago
        Is Flatpak better than snapd, if we set aside that one is ‘open’ and one is ‘closed’ and evaluate them by the merits of their functionality in service of the goal?
        bccdee 6y ago
        Yeah flatpak is much more mature, as I understand it.
    - JetSpiegel 6y ago
      AppImage? I don't see the need for much sandboxing, since certbot requires to have the keys to the kingdom anyway. systemd can whitelist a single folder for certbot to have write permissions.
- JetSpiegel 6y ago
  > This seems unnecessarily hostile. Certbot is a complex beast that generates TLS configurations, has multiple plugins that likely require specific system configuration, and is I think charitably more than "a glorified Python script". I didn't meant it as a knock on certbot, which I use and cherish. It's just not something that I would install and entire parallel package management system over, lest of all some ugly thing like snap.
- rstuart4133 6y ago
  > This seems unnecessarily hostile. Certbot is a complex beast that generates TLS configurations, has multiple plugins that likely require specific system configuration, and is I think charitably more than "a glorified Python script". Yeah, it is complex. Far too complex for what it does. What it does is implement a not particularly complex IETF protocol between your server and letsencrypt's servers, and run a few of your scripts when the protocol wants something done, like "install DNS entry". In fact the protocol is so simple a bash script can do it. Dehydrated https://dehydrated.io/ https://dehydrated.io/ is just that - a bash script that implements ACME. It also is in Debian. I moved to dehydrated when certbot was slow to implement DNS wildcards. The nice thing about simplicity is it infects everything else: the document becomes simple, which is nice because I had to read certbot's doco several times just to figure out what scenario would work for me. And distribution packaging becomes simple, so no snap's needed. And installation becomes simple.

prepperdev 6y ago

snaps are tied to the proprietary Ubuntu store and they are not available on all of the Linux flavors. For instance, I don't see snapd on Alpine Linux: $apk search snapd $ Not cool, I think.

deleted 6y ago
[deleted]
lstamour 6y ago
An alpine Linux core dev appears to maintain the alpine package for Certbot. I don’t see it being deprecated anytime soon. The snap is very different and relies on systemd which isn’t commonly found in Alpine.

koolba 6y ago

This has likely been asked and answered before, but why not write something like this in something that can be statically compiled like go? Isn’t the whole thing just a couple of web requests and cert operations?

bryogenic 6y ago
https://go-acme.github.io/lego/ https://go-acme.github.io/lego/ is exactly that. This is the client/library underneath traefik's batteries included version of let's encrypt certs.
- koolba 6y ago
  Oh that’s exactly what I’m talking about. No funky deps. No virtualenv. No python versions. That looks perfect.
linsomniac 6y ago
I switched over to acme.sh, a bash version. I wasn't holding out much hope when I first tried it, but honestly it's worked great!

sliken 6y ago

Wow, of all the standards why something proprietary like snaps? How about flatpak? Or anything out open?

akvadrako 6y ago
I'm not sure flatpak works for services, but certainly docker would make more sense.

Havoc 6y ago

Literally just switched from Ubuntu to Debian to get away from snaps

njsubedi 6y ago
Same here but Let’s Encrypt suggests you install snap on Debian and use snap to install certbot.
ryebit 6y ago
Linux Mint has even removed snap, which is impressive since they're downstream from Ubuntu. After hearing some of the issues with it (here and elsewhere), I'm kinda grateful to them for making the effort. Though this concerns me -- I use certbot on some debian servers, I hope that at least stays up to date.
- lstamour 6y ago
  Debian is still on version 0.x when the snap is at 1.1 ... this is one of those cases where the Debian stable branch is too stable when you need to ship software that interacts with a lot of remote APIs the way the certbot-dns packages do. It’s impossible to use the old Debian versions with the more secure API tokens from CloudFlare, for example.
  - hlieberman 6y ago
    The certbot-dns packages are certainly the most fragile part of the process -- however, I don't have any bug reports showing that the version in stable is currently broken for any of the dns plugins. If you're experiencing that, please file a bug against them and I can look into having a stable backport done for them.
    - lstamour 6y ago
      I’ll see what I can do, I’m not familiar with Debian package bug tracking. For reference, the incompatibility I faced was for the CloudFlare DNS plugin, which added support for API Tokens that had granular permissions somewhere between version 0.23 distributed in stable and 1.11 distributed via snap. Certbot docs and CloudFlare docs both encourage you to use API tokens instead of account-wide API secrets and the previous install instructions for wildcard DNS support suggested installing the CloudFlare DNS plugin by default on the Certbot site. As CloudFlare is used by a lot of folks for DNS, and was a suggested default install, I’m probably not the only one that encountered problems setting it up, without a backport available for a newer package of Certbot.

jdcaron 6y ago

Skip Certbot and use the more powerful and versatile tool acme.sh http://acme.sh http://acme.sh

fanf2 6y ago
My favourite ACME client is dehydrated https://github.com/dehydrated-io/dehydrated https://github.com/dehydrated-io/dehydrated

msturgill 6y ago

The Docker images are an option as well: https://hub.docker.com/r/certbot/certbot/ https://hub.docker.com/r/certbot/certbot/

ohazi 6y ago

Snaps require you to allow each publisher to automatically push arbitrary software updates to your machine, and snap deliberately does not allow you to disable this misfeature. It's not a bug or an oversight -- it's part of the design of snap, and it's not going to change. Handing out the keys to the kingdom like this is supremely annoying on a desktop (e.g. Windows 10), but it's completely unacceptable on a server. This is a terrible move, and they should absolutely walk it back.

lstamour 6y ago
I agree — the auto-updating nature of Snaps are a problem without an easy solution: https://askubuntu.com/questions/930593/how-to-disable-autorefresh-in-snap https://askubuntu.com/questions/930593/how-to-disable-autore... But I would also point out that on stable Debian it’s near impossible to deploy Certbot because the versions available are too old, especially the plugins. I’ve been routinely installing the snap instead because it’s a quick and easy way to deploy the service at the latest version. The only other alternative to suggest is to request the Certbot project deploys custom deb repos or similar. But can we expect that of every project? Perhaps we need a new standard to replace snap, if so the only folks I can see large enough to promote it would be GitHub... Since that’s unlikely to happen, maybe just noting the auto-update “feature” more prominently in their is all they should need to do?
- erik_seaberg 6y ago
  Too old in what way? Is the Debian stable version relying on something that Let’s Encrypt is deprecating?
  - lstamour 6y ago
    I’m not sure, but it’s possible. The version in stable was 0.31 or so, while the version in snap and unstable/sid is 1.11. The specific incompatibility I faced was for the CloudFlare DNS plugin, which added support for API Tokens that had granular permissions somewhere between the 0.23 version in stable and the current version of the plugin at 1.11. Current Certbot docs and CloudFlare docs both encourage you to use API tokens instead of account-wide API secrets and the previous install instructions for wildcard DNS support suggested installing the CloudFlare DNS plugin by default on the Certbot site.

linsomniac 6y ago

Just to clarify something I think a lot of replies don't understand: The Ubuntu Certbot packages have been horribly broken for well over a year, probably at least two. The PPA for Certbot includes updates of a lot of OS packages, with with incompatibilities with other Ubuntu provided packages. I've spent hours tracking down and fixing the problems that have come from installing certbot via apt. Usually, I'm much more a fan of native packages than snaps or similar, but in this case it makes a lot of sense. Here is a link to the Github Issue: https://github.com/certbot/certbot/issues/5234#event-3691151021 https://github.com/certbot/certbot/issues/5234#event-3691151... (Edit: Adding issue link)

hlieberman 6y ago
Hello! I formerly maintained this PPA before turning it over to some of the Ubuntu people. It's my understanding that certbot is going to be migrated out of universe soon and into the main Ubuntu archive. That will cause it to gain full support from Canonical. Either way, we will continue to support certbot in Debian (upstream of Ubuntu, if downstream from /actual/ upstream) indefinitely. The Ubuntu maintainers and I work closely on packaging.
- linsomniac 6y ago
  Thanks for your work on that. I imagine it will be easier moving forward as most of the issues seemed to be related to pulling in newer versions of Python packages, which broke supplied versions of other packages (boto-related tools ISTR were breaking).
rlpb 6y ago
> The Ubuntu Certbot packages have been horribly broken for well over a year, probably at least two. I think you're mistaken. The Ubuntu Certbot packages are maintained and work fine. What you're referring to is the PPA, which is no longer required (since Ubuntu's distribution-shipped certbot packages have worked fine for a long time now). Or, if not, can you point to specific issues with Ubuntu's own certbot packages please?
- 6y ago

rascul 6y ago

I'll stop using certbot before I install snap.

ivan_ah 6y ago

If y'all want to try a high-magic solution based on a single-host docker-compose setup with traefik 2+ as ingress, here is the paragraph for configuring Let's encrypt certs: https://github.com/rocdata/rocserver/blob/main/docker-compose.yml#L5-L27 https://github.com/rocdata/rocserver/blob/main/docker-compos... It works great. Host just needs to have ports 80 443 open and docker installed: https://github.com/rocdata/rocserver/blob/main/fabfile.py#L239-L264 https://github.com/rocdata/rocserver/blob/main/fabfile.py#L2... PS: In case I can save anyone days of debugging, if you want to run a wordpress container using this setup, you'll need to do some manual config to convince wp it's running in HTTPS mode, see https://wordpress.org/support/article/administration-over-ssl/#using-a-reverse-proxy https://wordpress.org/support/article/administration-over-ss...

ivan_ah 6y ago
Updated link to traefik container config: https://github.com/rocdata/rocserver/blob/main/docker-compose.prod.yml#L5-L27 https://github.com/rocdata/rocserver/blob/main/docker-compos... (link changed because only need SSL certs in prod -- so moved to a prod-specific docker-compose file)

soraminazuki 6y ago

Is there anything out of the ordinary here? Most upstream projects don't officially support distro packages and distros don't support non-distro packages. It's been that way for as long as I can remember.

hlieberman 6y ago

As the maintainer of certbot for Debian, I promise you that there's no intention of deprecating the certbot packages that exist in the archive. The EFF fully supports this decision and has promised to continue to assist. Their recommendation for snaps is meant to target new and inexperienced users who may not understand why they are not getting the latest software when they see it was updated "on the website". If any of you have concerns specifically about certbot on Debian, please feel free to contact me directly at my username @debian.org.

ohazi 6y ago
Good to hear, and thanks for your work on this!
mariopal 6y ago
Thanks for your work!
traveler01 6y ago
Thank you! I was concerned I'd have to install Snap on my Debian server.
detaro 6y ago
Giving new and inexperienced users yet another thing to install (and potentially break) feels like the wrong tradeoff IMHO. But good to know it'll continue to be packaged (even though I didn't expect anything else from Debian). Thanks for your work!

solarkraft 6y ago

So the EFF, an organization I thought stood for promoting digital freedom, is essentially promoting proprietary software? Looks questionable to me.