6 ms·

> I have a mailing list for people who use my code, when an update is out they can download the .php files, 'require' them and test them before deployment, but

> I have a mailing list for people who use my code, when an update is out they can download the .php files, 'require' them and test them before deployment, but never will I do packages. This offers no benefit in terms of security, over a package dependency locked at a specific version. The end result is the same: the user ends up downloading the .php files, and testing them in deployment, but through composer instead of curl. It doesn't contribute to security at all, it just makes it awkward for other people to use your code. I would also assume that people are connecting your library to a package management system anyway, to overcome this unnecessary hurdle e.g. https://getcomposer.org/doc/05-repositories.md#loading-a-package-from-a-vcs-repository https://getcomposer.org/doc/05-repositories.md#loading-a-pac...

Bolkan 5y ago
By using automatic upgrades you trade theoretical security fixes for undefined behaviour and bugs. One is clearly much worse than the other.
- heurisko 5y ago
  Composer (PHP dependency manager) does not force you into doing automatic upgrades. You can keep a dependency fixed at a particular version indefinitely. You can also point composer at a private vendored repository of the dependency if you don't trust the upstream server.
notRobot 5y ago
I do this solely because I don't like packages, I don't use them, and I don't want to maintain them for other people. To the people who want to use my code, it is recommended prominently in multiple places that they not blindly trust the code and actually inspect it before using it. The friction in this process is intended. The code I write is primarily for me. Other people can use it if they want to, and I hope it helps them, but I don't care much about how many chose to use it or not. If they do, they have to work with my preferred way of distributing code. There have been times where third parties have included my code in their packages, but I'm explicitly not the package author in those cases, so it (the package) is not my responsibility.
- heurisko 5y ago
  > it is recommended prominently in multiple places that they not blindly trust the code and actually inspect it before using it. The friction in this process is intended. There is nothing inherent in using packages that means you have to blindly trust the code, neither does providing a package mean you have to accept any more responsibility over providing a .php file (packages are just .php files with a few metadata files that allow them to be downloaded using composer rather than curl). Fair enough if someone doesn't want to add metadata to allow their code to be downloaded by composer, but I disagree that that offers any security benefit.
  - notRobot 5y ago
    > There is nothing inherent in using packages that means you have to blindly trust the code Agreed, but packages are an additional layer of abstraction, and you and I both know that the vast, vast majority of devs will not "look under the hood". Packages are often seen as a one-step plug-and-play solution. I don't want people to see my code that way. They should dive in and inspect it before using it (it is always written with this in mind - with extensive commenting and documentation). > neither does providing a package mean you have to accept any more responsibility Honestly, this is a personal thing for me. If people are using my code, I will feel responsible to some extent. IMO, the advantage of my method is that (at least a few) more people will test/audit my code as opposed to if it was available as a package. Which increases the likelihood of any possible bugs in the code getting caught.
    - heurisko 5y ago
      > Packages are often seen as a one-step plug-and-play solution. I don't want people to see my code that way. They should dive in and inspect it before using it (it is always written with this in mind - with extensive commenting and documentation). > IMO, the advantage of my method is that (at least a few) more people will test/audit my code as opposed to if it was available as a package. Which increases the likelihood of any possible bugs in the code getting caught. The person who unthinkingly installs a package will also unthinkingly include your script using 'require'. The only thing that happens is anyone who is interested in auditing your code and uses composer is inconvenienced with busywork, that would otherwise be handled by composer, e.g. autoloading the library. > Honestly, this is a personal thing for me. If people are using my code, I will feel responsible to some extent. The point you made was that you would feel more responsibility for a package rather than a PHP file. There's no reason why this should be the case. Both methods result in your code being run by 3rd parties.

Bolkan 5y ago

By using automatic upgrades you trade theoretical security fixes for undefined behaviour and bugs. One is clearly much worse than the other.

heurisko 5y ago
Composer (PHP dependency manager) does not force you into doing automatic upgrades. You can keep a dependency fixed at a particular version indefinitely. You can also point composer at a private vendored repository of the dependency if you don't trust the upstream server.

notRobot 5y ago

I do this solely because I don't like packages, I don't use them, and I don't want to maintain them for other people. To the people who want to use my code, it is recommended prominently in multiple places that they not blindly trust the code and actually inspect it before using it. The friction in this process is intended. The code I write is primarily for me. Other people can use it if they want to, and I hope it helps them, but I don't care much about how many chose to use it or not. If they do, they have to work with my preferred way of distributing code. There have been times where third parties have included my code in their packages, but I'm explicitly not the package author in those cases, so it (the package) is not my responsibility.

heurisko 5y ago
> it is recommended prominently in multiple places that they not blindly trust the code and actually inspect it before using it. The friction in this process is intended. There is nothing inherent in using packages that means you have to blindly trust the code, neither does providing a package mean you have to accept any more responsibility over providing a .php file (packages are just .php files with a few metadata files that allow them to be downloaded using composer rather than curl). Fair enough if someone doesn't want to add metadata to allow their code to be downloaded by composer, but I disagree that that offers any security benefit.
- notRobot 5y ago
  > There is nothing inherent in using packages that means you have to blindly trust the code Agreed, but packages are an additional layer of abstraction, and you and I both know that the vast, vast majority of devs will not "look under the hood". Packages are often seen as a one-step plug-and-play solution. I don't want people to see my code that way. They should dive in and inspect it before using it (it is always written with this in mind - with extensive commenting and documentation). > neither does providing a package mean you have to accept any more responsibility Honestly, this is a personal thing for me. If people are using my code, I will feel responsible to some extent. IMO, the advantage of my method is that (at least a few) more people will test/audit my code as opposed to if it was available as a package. Which increases the likelihood of any possible bugs in the code getting caught.
  - heurisko 5y ago
    > Packages are often seen as a one-step plug-and-play solution. I don't want people to see my code that way. They should dive in and inspect it before using it (it is always written with this in mind - with extensive commenting and documentation). > IMO, the advantage of my method is that (at least a few) more people will test/audit my code as opposed to if it was available as a package. Which increases the likelihood of any possible bugs in the code getting caught. The person who unthinkingly installs a package will also unthinkingly include your script using 'require'. The only thing that happens is anyone who is interested in auditing your code and uses composer is inconvenienced with busywork, that would otherwise be handled by composer, e.g. autoloading the library. > Honestly, this is a personal thing for me. If people are using my code, I will feel responsible to some extent. The point you made was that you would feel more responsibility for a package rather than a PHP file. There's no reason why this should be the case. Both methods result in your code being run by 3rd parties.