Acum 5 ani am ales symfony2, care se pregatea sa intre in alpha stage. Cred ca am fost prima aplicatie enterprise pe sy2. Nu eu am facut alegerea, dar recunosc: a fost cea mai buna.
Am tot folosit Lithium PHP în ultimii ani în producție. Abia anul ăsta prin iunie-iulie a fost lansat și un v.1.
Deci practic productia a rulat pe un alpha? Pe ce perioada de timp si ce probleme au aparut sau in ce stadiu era aplicatia? chiar sunt curios.
Interesant, ce se intampla daca apare un CVE pt. 0.8 or something si trebuie sa faci upgrade la 1.x - ceea ce include breaking changes, din moment ce API-ul s-a schimbat.
De altfel - toate variantele din productie sunt aduse in mod constant la zi?
EDIT:
- ar merita un topic nou / chiar pare un tangential-topic interesant cc @iamntz
- sunt o serie de issues pe langa e.g.: adus la zi framework, daca se merita, ce se intampla cand nu facem asta, CVEs, framework inherent bugs, deps, etc.
Cred că un release RC nu înseamnă neapărat că-i 0.x.
NodeJS a stat la 0.x vreo trei-patru ani până să sară brusc la 4.x 
Node.js pt. ca a stat in 0.x vreo 4 ani a avut probleme la adoptie.
Cand aduceam in discutii sa folosim node, in multe situatii m-am lovit de “nu e matur”, “nu e nici macar v1”, “inca nu e stabil”, “or sa apara modificari”.
Graficul urmator cred a ilustreaza destul de bine conceptul de adoptie:
Innovators, Early Adopters formeaza un early market, dupa ce acestia valideaza produsul si sunt destul de perseverenti se poate ajunge la Majority.
Cel putin asa a fost in cazul React. Am folosit 2-3 ani Angular si am ignorat React pt. ca nu-mi placea JSX. Eu am inceput sa-l folosesc in Early Majority, din diverse opinii personale care mi-au fost invalidate.
1 Like
Mă uit la istoria release-urilor. Dacă au o frecvență cât de cât constantă (e.g. gitlab are release în fiecare lună, în jurul datei de 20; WordPress are un release la vreo trei luni etc), estimez cam cât am de lucru la proiect.
În functie de cât de mult am de lucru în perioada respectivă, mă risc să folosesc varianta RC sau beta, dar doar în development. În producție am folosit doar de vreo două ori beta, pentru că era rezolvat vreun bug de care mă loveam.
Nu sunt aduse la zi pentru că nu este nevoie. Aplicațiile respective au fost construite pe baza framework-ului așa cum era el la momentul respectiv și nu fac update doar de dragul de a face update, fără a avea nevoie de ceea ce aduc nou versiunile ulterioare.
Cât despre vulnerabilități, situația e diferită de la framework la framework.
În cazul meu, mi-am asumat riscul în cunoștință de cauză; dacă apărea vreo vulnerabilitate făceam update și adaptam codul. Chestia este că m-am familiarizat cu framework-ul încă de la versiunea 0.1 și știam ce poate și nu poate. Deasemenea, API-ul cu care interacționezi în cazul Lithium este destul de restrâns așa că nici în cel mai rău caz nu pot apărea probleme majore la modificarea lui, ce nu pot fi remediate repede și ușor.
Chiar daca ai fi codat framework-ul asta nu inseamna ca nu poate avea vulnerabilitati ce pot fi exploatate de cineva care citeste codul sursa si nu alege a deschide un issue pe GitHub
In linii mari, protectia in cazul li₃ pentru versiuni mai vechi este un fel de pseudo-‘Security through obscurity’ din simplul fapt ca este un framework foarte putin folosit (atentie nu il critic aici, just stating the obvious, de fapt chiar mi se pare interesant ce am citit in lista de blog posts)
EDIT:
fc1d007 2014-10-05 Adding test for security helper sending correct signature fields. David Persson, 1 year, 10 months ago
...
b2dea24 2011-06-04 Implementing `\security\validation\RequestToken` and `\template\helper\Security` to protect against CSRF attacks. Nate Abele, 5 years ago
1 Like
N-am zis că n-are, am zis doar că în cazul în care ar apărea ceva, îmi asum răspunderea pentru actualizarea și adaptarea codului la eventualele modificări de API.
Iar prin familiar, vreau să zic că i-am parcurs codul sursă de mai multe ori (asemeni hacker-ului ipotetic despre care vorbeai) și știu[1] cam tot ce se întâmplă under the hood. De-aia sunt dispus să-mi asum riscul.
În altă ordine de idei, întregul framework este destul de rudimentar/minimalist/simplist/etc. încât să nu existe foarte multe puncte sensibilie în care să poată apărea probleme de securitate.
[1] Mai degrabă știam, pentru că în ultimul an și ceva n-am mai prea avut tangențe cu PHP-ul, drept urmare n-am mai urmărit îndeaproape nici evoluția Li3.
1 Like
Pentru noi pariul a fost corect, am scris cod incepand cu alpha version a symfony2, si in lunile in care am codat si upgradat frameworkul, acesta a ajuns la public release aproape in acelasi timp incare am lansat si noi live prima bucata de funcitonalitate.
Nu m-am simtit prea comfortabil lucrand pe edge version, insa in procesul de selectie am cantarit inclusiv skillul ca developer al lui Fabien, si aici m-a castigat pe mine. Eu inca mai studiez codul sursa al frameworkului atunci cand trebuie sa iau design decisions si am nevoie sa compar cu un good practice.
O vorba despre Lithium, cred ca @dakull a specificat foarte corect ca e securitate prin obscuritate. Anul asta am facut o analiza pe o aplicatie mare, al carei middleware e scris in Lithium. Side-note: e foarte interesant ca, atunci cand noi am ales symfony, ei au ales lithium. Vreau sa spun ca nevoile lor ca aplicatie au crescut foarte mult, si a fost nevoie sa “bend over backwards” sa atinga asta cu lithium.
P.S. Imi cer scuze pentru disparitia subita si pt exprimarea putin incoerenta si incompleta, sunt intre avioane si continente.
1 Like