Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Lescript – Simple PHP client library for Let's encrypt (github.com)
96 points by efesak2 on Dec 10, 2015 | hide | past | web | favorite | 68 comments

Thanks, nice looking code that is pretty darn clean. It is always refreshing to see an application that is as self contained as possible without all the multitude of required dependencies.

Mate, seriously, use composer and packagist.

Well, composer needs to be installed and present on the system. As the author states, minimal dependencies.

Hell why doesn't everyone follow this? Instead I see projects with five or more build tools needed to deploy a website.

A single small website depending on... PHP/MySQL (obviously), Symfony, composer, npm, grunt, bower, ant, vagrant, docker. And well, language dependencies not needed by the website itself, just for the buildtools: python, nodejs, ruby, java plus virtualbox for vagrant!

All of this for a setup that can be (with proper documentation) replicated by hand and from scratch in <10 minutes (Debian, not RPM-based crap). The fuck are you smoking, people? Took me even WITH documentation about all those build tools 30min to get running where a simple git clone should be all that's needed. Bonus side effect: if you need to hack stuff in your deps, it's easier to ship them in your repo than if you use composer and friends.

I'd coin a new term for this: tool-sturbation.

I agree with you that modern web projects tend to suffer from build dependency creep - but I don't think Composer alone really counts as being heavyweight or unnecessarily complex, even for a small project. It's just a phar archive and a json file. That's not really the same class of insanity as, say, requiring the Node.js runtime and npm to import a build system to compile the CSS assets for a PHP project.

Even if structuring a project around the PSR autoloader adds a bit more complexity (probably little more than adding a namespace and moving everything into a folder) that's still preferable to the dark days when everyone just rolled their own autoloaders (if you were lucky) or you were expected to do it yourself (and then maybe everything gets wrecked because of a relative path somewhere in the mass of includes of includes.)

Who says you need those build tools? That has nothing to do with sane package management, which is what composer provides. Composer doesn't require you to have any dependencies and you can use a library that supports composer in the exact way you described. It's just a JSON config file, there is absolutely no reason to not set it up - not having "dependencies" is not a valid reason.

> Composer doesn't require you to have any dependencies

Oh yes, it does - SSH or other shell access, as well as the hoster allowing the server to connect to the outside Internet!

Both are not common, in fact many hosters firewall their hosts for outgoing connections to prevent spam, botnets etc.

I'm really not sure if this is sarcasm/trolling or not, but just in case it's not, composer is mainly used on the development side to maintain dependencies. It really shouldn't be a problem to have ssh/a working internet connection on your development box. Not saying you have to use composer, but I think the above point stands.

> composer is mainly used on the development side to maintain dependencies.

Well you will also need composer for actual deployment.

> . It really shouldn't be a problem to have ssh/a working internet connection on your development box.

Ever worked at a BigCo where everything is firewalled and needs a proxy? Or no internet at all and you gonna transfer stuff via USB sticks?

>Well you will also need composer for actual deployment.

No you don't, it's PHP, there is no "actual deployment" beyond putting the files on a server.

Worst case scenario (because I've had to do this) is you have to change the paths in the file generated by the autoloader, if your development environment is different than production. But that's no more work than adding paths to include statements. You can even just do that locally first and move everything with FTP.

No, you don't need it for deployment at all - a very common and sane deployment strategy is to have one developer / staging environment that does composer install/updating, and then the result of that build is rsync'd (or it could be FTP'd over in a shared hosting environment) to the production host(s).

> many hosters firewall their hosts for outgoing connections to prevent spam, botnets etc.

That's not really true. Even on our shared hosting platform (non-shell) we permit http/https/ftp outbound connections, and we're pretty conservative.

We also expect our customers to build and test their stuff locally then push up a working and hopefully error free site to our servers. We consider our servers production-only environments and will actually take you down if you're generating more than a few errors an hour, because errors and exceptions are expensive.

That said I do kind of agree with your sentiment about some "simple" projects that use everything under the sun just to get a todo list app built, even on my local dev env.

Adding composer support doesn't make the package incapable of being used exactly as it's being used now. It merely adds support. You can theoretically install any composer package without using composer. Though, those with complicated dependency trees would be more difficult. That, though, is not an issue here.

You can always do a local deployment, zip the thing, and rsync it anywhere. It's not at all a necessity, it's just that most PHP devs have embraced Composer.

In fact we used to do something rather similar at my job, until we just switched to replicating containers over all our servers

You just don't get it :)

Whoever wish to include manually this package and use it like if it was 1993 will still be able to do by cloning this repo and including the file by hand. On the other side, 99% of the sane PHP that has been written in the last few years including fairly large projects, WILL use composer to manage external dependencies as it's probably the single project who made PHP a modern language.

So, what are the cons of releasing this as a package?

I'm not even starting the conversation where I'm trying to convince you that using a dependencies manager is always a good thing to keep the codebase sane and clean - even for small scripts. That "<10 mins thing" is an empty claim as you have to do a boilerplate once and can use it all the time (unless you are the kind of programmer who is not 'good-lazy' but rather 'bad-lazy' and love to re-do its job by hand over and over)

"99% of sane PHP" is not the audience here. There are millions and millions of shared hosting accounts running basic cPanel + PHP + some minimal form of SSH access - those are the people that won't have a way to install LetsEncrypt otherwise, except for the ability to execute some random PHP file in their SSH home directory. Step out of your walled garden and buy yourself a crappy $5/mo hosting account, and you will see why the author's choices are a blessing in disguise.

A pity you're being downvoted. People forget not everyone has the bucks to shell out for even a webhost with SSH enabled.

$5/mo shared hosting plan where you're walled and can't do anything you want, or $5/mo VPS at Digital Ocean where you have SSH enabled by default and can install anything you want.

of course, people don't have the bucks to shell out for that. I get it.

> of course, people don't have the bucks to shell out for that. I get it.

they don't know better. Don't forget what the base of most Wordpress and Drupal setups is - people with barely enough skill to do a FTP push, download and install a theme from Themeforest and done.

or they can't pay because nearly every US startup/service accepts credit cards only (which is not widespread in Europe) and no one really trusts Paypal.

> they don't know better. Don't forget what the base of most Wordpress and Drupal setups is

Considering the audience of HN, I am astounded by the amount of people who complain about a PHP package being on Composer, yet they all use NodeJS, Go, and other things that require more than modern PHP and Composer does.

Most people are not likely to know how to manage a VPS. There is a fundamental difference.

A managed hosting company does something important for you. They manage!

For the average user, this is something they need if they want to start a small business or a website for a project and want to have SSL while doing so. Integrating this with some form of tutorial for the average user makes this tool amazing.

You can still use a Composer based project without using Composer, though. You can still just FTP the thing up to your server and include it manually, as long as it doesn't include its own dependencies (and if it does, you would have to manage those manually anyway.)

Adding composer support would not impact people's ability to use this the way they would now. Composer support doesn't stop manually installation. It's akin to supporting npm. I can use npm to install packages, or I can manually add them if I wanted.

You can always distribute a "full" package like many popular products do, with all the dependencies lodged in place. It's a damn convenient thing to have at dev time, but there's 0 need to enforce build processes in PHP at least.

Sorry, but most hosts have composer installed, it's the preferred way to install PHP packages.

I'm working with a customer right know that doesn't even have shell access on their hosted environment. composer and git are barely usable under those circumstances.

I don't have reliable information about the market situation, but i assume that this is pretty much standard with shared hosting.

I am working with hosters still running PHP5.2 in production... FTP only.

Someone on ServerFault was posting about their PHP CLI on their shared host being PHP 4.x this week. Yowch.

Hoooooly shit, I'd change the hoster for fear of being hacked lol

No reason why composer would be unusable - just composer install locally and upload the results to your host. This isn't an uncommon deploy practice even if you have shell access.

It's a PITA if you're developing on Windows. The less you have to do other than FTP upload, the better because SOME incompatibility WILL fuck you up. Wrong CRT version, weird path issues, package installers assuming Unix... dependencies on stuff that doesn't work on Winblows, requires PECL extensions (which are regularly unmaintained on win32),...

Not in my experience - I develop PHP on Windows and have never had an issue using Composer. I can't imagine what sort of PHP dependencies "don't work on Winblows (cute)" or which even care about your CRT, or how that would even be a Composer issue as opposed to an issue with the libraries themselves or your PHP install. It's just PHP scripts running from an archive - if PHP works, and isn't too out of date, Composer works.

Developing on a VM solves all of these problems. Your dev environment should match your prod environment as much as possible, anyways.

If your target host is *nix, develop on something unix-like.

What I meant was develop locally, use composer locally, then deploy the end product over, which sounds like all environments would allow you to do.

> unless you are the kind of programmer who is not 'good-lazy' but rather 'bad-lazy' and love to re-do its job by hand over and over

Well. If you do it by hand you know WHERE and WHY it didn't work in case problems arise. Granted, it takes experience in server management, but imho a good developer MUST know about the platform his software is to run.

The more tools you add to the process, the more complex debugging gets when even the tiniest dependency chanes.

Hell, no!

A single PHP file is the perfect solution to this. Call it from /etc/crontab and you are done.

I hate overladen projects on GitHub with all kinds of fluff. A single source file and a readme is just awesome.

It requires at least two PHP files. One that ACTUALLY DOES WHAT YOU WANT and the library files.

Since you have to write a new PHP file anyway, composer allows you to pull in the latest version (or update it) with semver constraints.

Then you can package it as a phar and call it that way.

This is a library, not a file to run, and so it should have composer support.

Or, if you don't want to package it as a PHAR - since I have no idea how to do that, you'd implement your version in some directory and probably alias a command to it.

TL;DR: This is a library, not a script. It should have composer support.

I don't want to automatically pull the latest version. I would only use this after I studied the code and made sure it is not doing anything harmful. That's why this has to be as simple as possible.

> I don't want to automatically pull the latest version.

You don't have to. Composer allows you to pick a particular package version if you like, and it's only going to fetch a more recent version if your composer.json permits it and if you explicitly run composer update.

And how distributing this as a composer package would stop you from cloning the repo manually and still use the class as if it had no composer json?

On the other hand, what if you have a slightly more complex system with some logic to handle crons?

Just fork and add whatever your "more complex system" needs. But don't force this complexity on me. I work hard to keep my systems simple.

Also maybe a namespace. I doubt they're the only person to have ever made a class called `\Client` :)


Though I notice that the README states "[i]ts goal [is] to have one easy to use PHP file without dependencies", and they point out there's already a proper package out there, kelunik/acme. If the goal is a single file with no dependencies, I can understand the lack of Composer, as it's not really targeted at that audience.

If the target audience are those developers manually including everything, then it's not a package for me. Using composer is completely unrelated to having (or rather not) dependencies. It's actually pretty much the opposite: a way of distributing your package to projects who wish to use it. So again: please use composer.

Completely agree with the namespace. You HAVE to namespace it :) Hope it helps

Composer is awesome, but this is not a package ready to use! (at least not now). Valid point for namespace.

Thank you for the great link.

Pull request with composer added here: https://github.com/analogic/lescript/pull/5

Hopefully the author sees it


From README: If you prefer more robust and clean library see excellent https://github.com/kelunik/acme

Huge obstacle from using kelunik lib is PHP7 and need of external libraries.

What's wrong with external libraries? They're a mere `composer install` away.

Nothing in general, its about choice...

So this is a solution looking for a problem, then?

Thanks, seems like every day we get a shorter version. This is actually quite useful since I have PHP on most system but not all the dependencies that some of the python versions require.

I'm hoping to see a single file bash script at some point :)

Actually there is single bash file client https://github.com/lukas2511/letsencrypt.sh :)

> public function signDomains($domains)

Should this have an `array` type declaration? You used it on another function.

What is Let's encrypt exactly? I thought it was just free SSL so why do I need to touch my code at all?

Let's Encrypt has a public API for managing certificates. One use case where this is handy is for creating/modifying certificates for each customer-controlled domain/subdomain of your multi-tenant web service.

Let's Encrypt certificates expire after 30 days. The reason for that is to mitigate problems with old certs and to encourage automation so there's less danger of a server being left unsecured because an admin forgotten to update something. This sort of library is aimed at [sys|web|dev]ops rather than developers per se.

Ultimately services like LE will get to the point where certificates will expire in hours rather than days, so a problem like Heartbleed will 'self-heal' because certificates can be fixed and servers will automatically get the patch within a day.

90 days.

How is this used to renew? I don't see a function related to renewals.

What would be the difference between "renewing" and running the script twice? There's no distinction made when I buy certificates from another CA.

This is probably my misunderstanding of how it works. Pardon what's probably a silly question, but do all certs work the same way (i.e., certs are never "renewed" but just reissued with new dates)?

> certs are never "renewed" but just reissued with new dates

This is correct.

The question arises. How Letsencrypt handle reissued certificates under one domain? Guess if I reissue million times for a specific domain, does this override the previous certificates on their database or does it create valid certificates each time I reissue? Thanks for the script.


Why is this comment here?

I was going to star it, until I saw the advertisement in the README.md.

Is it problem? I am author of poste.io too. Edit: To be precise lescript.php was developed only and because of LE implementation to Poste.io

Putting a line or two about why you developed a library doesn't seem unreasonable.

I'm actually happy about it in most cases, as it shows that it's likely to be maintained, as it has a existing use outside of "Hey, I wrote some code!"

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact