4 ms·

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 r

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.

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.