4 ms·

I don't see any problem if the framework offers all it needs to run the application. Angular was a good choice these days and you were able to build pretty perf

I don't see any problem if the framework offers all it needs to run the application. Angular was a good choice these days and you were able to build pretty performant products. I would be on your side if that would be a new project from 2022.

rmetzler 4y ago
I can’t say anything regarding this project or Angular. I just want to address the „you don’t need to be on a maintained/supported version, if what you need is there“. The problem are security bug fixes, which usually are only backported to supported versions, regardless of when they were introduced. E.g. version 1.5 introduced a vulnerability, but it’s not found until after the release of 3.1. At this time only 3.1 and 2.5 are supported. If you’re using 1.5 you need to upgrade. Most probably at the least convenient time possible. You probably know this already. I still wanted to address it, because at one time in my life I was young and naive and thought similar to you. There might be people out there who can learn from that.
- dewey 4y ago
  > The problem are security bug fixes [...] I'd say the bigger problem is having a stack that a very limited amount of people want to work on. This is true for a company where you want to hire specific people to work on your outdated stack (hard and expensive), but even more for an open source project where you need contributors willing to work on an old stack in their free time.
  - rmetzler 4y ago
    I agree that this is a bigger issue, but only IF you want to change the code. My comment was more in the direction of "the project is done, deployed, and will not change anymore". Somehow software seem to be subject to weathering over time. And what seemed like a secure piece of software can become insecure over night, when someone is fuzzing it and publishes a PoC.
- SeriousM 4y ago
  Angular was and is a frontend framework. "Security issues" may alter the authentication state of the frontend but the server should always check if operations are authorised. Lets assume the server runs php or .net. Security patches are crucial to avoid eg. code injection or malicious request forgery and thus should always be applied, maybe also upgrade the runtime version if possible. Please tell me in which scenario a frontend issue is a security issue because I'm more the backend architect, not a naive developer.
  - evilduck 4y ago
    You're focused on the security of your own server, but an insecure or compromised front end can be used to leverage your site's utility or popularity to attack your end users or be used against other sites. Just read up on XSS. Your server can remain perfectly secure and uncompromised while your front end drags your company or project's reputation through the mud.
  - rmetzler 4y ago
    I mentioned in my first sentence that my reply was not really regarding Angular. But yeah, I looked it up. Here is a link to the CVEs for Angular, mainly XSS like the sibling comment explains. https://www.cvedetails.com/vendor/18512/Angularjs.html https://www.cvedetails.com/vendor/18512/Angularjs.html

rmetzler 4y ago

I can’t say anything regarding this project or Angular. I just want to address the „you don’t need to be on a maintained/supported version, if what you need is there“. The problem are security bug fixes, which usually are only backported to supported versions, regardless of when they were introduced. E.g. version 1.5 introduced a vulnerability, but it’s not found until after the release of 3.1. At this time only 3.1 and 2.5 are supported. If you’re using 1.5 you need to upgrade. Most probably at the least convenient time possible. You probably know this already. I still wanted to address it, because at one time in my life I was young and naive and thought similar to you. There might be people out there who can learn from that.

dewey 4y ago
> The problem are security bug fixes [...] I'd say the bigger problem is having a stack that a very limited amount of people want to work on. This is true for a company where you want to hire specific people to work on your outdated stack (hard and expensive), but even more for an open source project where you need contributors willing to work on an old stack in their free time.
- rmetzler 4y ago
  I agree that this is a bigger issue, but only IF you want to change the code. My comment was more in the direction of "the project is done, deployed, and will not change anymore". Somehow software seem to be subject to weathering over time. And what seemed like a secure piece of software can become insecure over night, when someone is fuzzing it and publishes a PoC.
SeriousM 4y ago
Angular was and is a frontend framework. "Security issues" may alter the authentication state of the frontend but the server should always check if operations are authorised. Lets assume the server runs php or .net. Security patches are crucial to avoid eg. code injection or malicious request forgery and thus should always be applied, maybe also upgrade the runtime version if possible. Please tell me in which scenario a frontend issue is a security issue because I'm more the backend architect, not a naive developer.
- evilduck 4y ago
  You're focused on the security of your own server, but an insecure or compromised front end can be used to leverage your site's utility or popularity to attack your end users or be used against other sites. Just read up on XSS. Your server can remain perfectly secure and uncompromised while your front end drags your company or project's reputation through the mud.
- rmetzler 4y ago
  I mentioned in my first sentence that my reply was not really regarding Angular. But yeah, I looked it up. Here is a link to the CVEs for Angular, mainly XSS like the sibling comment explains. https://www.cvedetails.com/vendor/18512/Angularjs.html https://www.cvedetails.com/vendor/18512/Angularjs.html