4 ms·

> 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 i

> 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.
  - notRobot 5y ago
    > The person who unthinkingly installs a package will also unthinkingly include your script using 'require'. Yeah, everything I'm talking about is to make the latter a less likely occurance.
    - heurisko 5y ago
      You have misunderstood, the latter refers to "download the .php files, 'require' them", which is the situation you say exists right now. I'm going to leave this by saying that I think the idea that you can make developers more conscientious by increasing busywork, is false. All it achieves is creating more busywork. Unconscientious developers will do the busywork and not scrutinise the library anyway, conscientious developers will just have to do extra busywork. A better solution would be to provide a composer metadata file and to publish each new release using a new major release number each time, which is arguably the proper way to signal to consumers of the library that each version needs careful scrutiny and testing, as major release numbers signal breaking changes.
      - notRobot 5y ago
        Thanks for the suggestions, I'm not yet convinced, but I will give this more thought!
      - mannykannot 5y ago
        If I understand notRobot correctly, each instance of this 'busywork' is initiated by an email, which is an opportunity for pointing out the importance of testing. It is a matter of fact that most people are susceptible (in some degree) to such influences, so if notRobot is making this point with each announcement, it may have some effect (though probably small) - and regardless, if the process turns away some people who consider this busywork too onerous, and some of those also take the same attitude with regard to testing, then so much the better, from notRobot's point of view! NotRobot is under no obligation to do anything any differently, or give any justification at all.
        5y ago
newaccount74 5y ago
> There is nothing inherent in using packages that means you have to blindly trust the code I use about a dozen different package managers and I have no idea how to check the code they download before they install/deploy it. I often check the source on Github if I need to look something up, but I have no idea how I'd go about verifying that the code on Github is the same as whatever the package managers install.
- IgorPartola 5y ago
  That sounds like a personal problem. .deb and .rpm packages are nothing more than tar archives with a specific file structure. dpkg and rpm both have options to extract the package locally. dpkg -L NAME will show you all the files the installed package has placed on your file system (not generated ones by the code obviously but ones that came with the archive). pip has similar options. More broadly, and I am sorry if I am wrong here, but what do you expect to glean from reading that code if you don’t bother reading the man page for your package manager?
  - newaccount74 5y ago
    The point is, if you want people to review the code before they deploy it, it's better to just give them a source file. Package managers just make it so convenient to use code without ever looking at it.
    - IgorPartola 5y ago
      That is a truly absurd argument.
- heurisko 5y ago
  In the context of PHP, the package source is put under vendor/ and in my IDE is automatically indexed. It's very easy to view the source code. You can even experiment with the packages directly, by editing the files in vendor/.
  - 5y ago
ryanbrunner 5y ago
At the very least, distributing in this way (presumably with some license clause that it can't be later placed in a package repository) prevents other libraries using this library as a dependency. Expecting developers to review what's happening with libraries is mostly unrealistic, but expecting them to review changes in the dependencies of the libraries you use is completely hopeless.

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.
- notRobot 5y ago
  > The person who unthinkingly installs a package will also unthinkingly include your script using 'require'. Yeah, everything I'm talking about is to make the latter a less likely occurance.
  - heurisko 5y ago
    You have misunderstood, the latter refers to "download the .php files, 'require' them", which is the situation you say exists right now. I'm going to leave this by saying that I think the idea that you can make developers more conscientious by increasing busywork, is false. All it achieves is creating more busywork. Unconscientious developers will do the busywork and not scrutinise the library anyway, conscientious developers will just have to do extra busywork. A better solution would be to provide a composer metadata file and to publish each new release using a new major release number each time, which is arguably the proper way to signal to consumers of the library that each version needs careful scrutiny and testing, as major release numbers signal breaking changes.
    - notRobot 5y ago
      Thanks for the suggestions, I'm not yet convinced, but I will give this more thought!
    - mannykannot 5y ago
      If I understand notRobot correctly, each instance of this 'busywork' is initiated by an email, which is an opportunity for pointing out the importance of testing. It is a matter of fact that most people are susceptible (in some degree) to such influences, so if notRobot is making this point with each announcement, it may have some effect (though probably small) - and regardless, if the process turns away some people who consider this busywork too onerous, and some of those also take the same attitude with regard to testing, then so much the better, from notRobot's point of view! NotRobot is under no obligation to do anything any differently, or give any justification at all.
      - 5y ago

newaccount74 5y ago

> There is nothing inherent in using packages that means you have to blindly trust the code I use about a dozen different package managers and I have no idea how to check the code they download before they install/deploy it. I often check the source on Github if I need to look something up, but I have no idea how I'd go about verifying that the code on Github is the same as whatever the package managers install.

IgorPartola 5y ago
That sounds like a personal problem. .deb and .rpm packages are nothing more than tar archives with a specific file structure. dpkg and rpm both have options to extract the package locally. dpkg -L NAME will show you all the files the installed package has placed on your file system (not generated ones by the code obviously but ones that came with the archive). pip has similar options. More broadly, and I am sorry if I am wrong here, but what do you expect to glean from reading that code if you don’t bother reading the man page for your package manager?
- newaccount74 5y ago
  The point is, if you want people to review the code before they deploy it, it's better to just give them a source file. Package managers just make it so convenient to use code without ever looking at it.
  - IgorPartola 5y ago
    That is a truly absurd argument.
heurisko 5y ago
In the context of PHP, the package source is put under vendor/ and in my IDE is automatically indexed. It's very easy to view the source code. You can even experiment with the packages directly, by editing the files in vendor/.
- 5y ago

ryanbrunner 5y ago

At the very least, distributing in this way (presumably with some license clause that it can't be later placed in a package repository) prevents other libraries using this library as a dependency. Expecting developers to review what's happening with libraries is mostly unrealistic, but expecting them to review changes in the dependencies of the libraries you use is completely hopeless.