4 ms·

Automatic Security Updates for Developers

8 points by CiPHPerCoder 10y ago

mixologic 10y ago
Automatic updates of of large custom applications built with componentized open source software suffer from the problem that unless you control all of the software, and all of the components and dependencies, you cannot guarantee that the update you are deploying is going to succeed. Best practices have tended to evolve towards Continuous Integration/Continuous delivery for those sorts of deployments (i.e dev/test/staging/deploy to prod), and its generally a very bad idea to automatically update your production software without running it through your own localized battery of tests so that you can verify that the application will continue to function. Frameworks and CMSs that encourage extensibility have no way of knowing whether an update is going to conflict with some locally developed custom code. In the composer based world of php, it would also mean relying on every library that your application is dependent upon to follow strict semantic versioning, which is merely a handshake agreement that is reliant upon the library author's judgement. Even if everything is architected such that you can guarantee the security of the process, I don't see how one could guarantee the correctness of the process.
- predakanga 10y ago
  > its generally a very bad idea to automatically update your production software without running it through your own localized battery of tests To me, this begs the question: How do we enable clients to react quickly to releases? The most easily available solution would seem to be webhooks. It's standard practice for them to be used to trigger things internally, but is it time to turn them outwards? Side note: It's always seemed a bit of a waste to me that sites like Github will only allow the owner of a repository to create web hooks. My personal use-case for that is automating Docker builds of various projects, but I'm sure others exist.

4 ms·

Automatic Security Updates for Developers

8 points by CiPHPerCoder 10y ago

mixologic 10y ago
Automatic updates of of large custom applications built with componentized open source software suffer from the problem that unless you control all of the software, and all of the components and dependencies, you cannot guarantee that the update you are deploying is going to succeed. Best practices have tended to evolve towards Continuous Integration/Continuous delivery for those sorts of deployments (i.e dev/test/staging/deploy to prod), and its generally a very bad idea to automatically update your production software without running it through your own localized battery of tests so that you can verify that the application will continue to function. Frameworks and CMSs that encourage extensibility have no way of knowing whether an update is going to conflict with some locally developed custom code. In the composer based world of php, it would also mean relying on every library that your application is dependent upon to follow strict semantic versioning, which is merely a handshake agreement that is reliant upon the library author's judgement. Even if everything is architected such that you can guarantee the security of the process, I don't see how one could guarantee the correctness of the process.
- predakanga 10y ago
  > its generally a very bad idea to automatically update your production software without running it through your own localized battery of tests To me, this begs the question: How do we enable clients to react quickly to releases? The most easily available solution would seem to be webhooks. It's standard practice for them to be used to trigger things internally, but is it time to turn them outwards? Side note: It's always seemed a bit of a waste to me that sites like Github will only allow the owner of a repository to create web hooks. My personal use-case for that is automating Docker builds of various projects, but I'm sure others exist.