Archives
Contributors
Re: OCA and security notices
Interesting conversation about SDLC.
And very important to take in account in real life projects with OCA.
I've a doubt if working from scratch with Odoo OCB and OCA or from Odoo CE because no all repositories are migrated.
I'm agree with Pedro to work at edge in last version, this is fundamental for security reasons of dependencies packages, but it's ideal if you work with OCA without migrated repositories.
And very important to take in account in real life projects with OCA.
I've a doubt if working from scratch with Odoo OCB and OCA or from Odoo CE because no all repositories are migrated.
I'm agree with Pedro to work at edge in last version, this is fundamental for security reasons of dependencies packages, but it's ideal if you work with OCA without migrated repositories.
I propose discuss about SDLC with a discord channel and maybe another channel for S-SDLC ( Security/SecDevOps ).
Happy year Contributors !!!
JuanDCG
El jue, 31 dic 2020 a las 16:07, Raphaël Valyi (<rvalyi@akretion.com>) escribió:
a few considerations,About a 2 years based LTS:yes at Akretion we mostly skipped the uneven Odoo versions since version 8 (before that evolution was so much needed that we couldn't). But that may change. It happens Odoo SA screwed v9 release badly and so far they screwed no even version. But should they screw v16, we might totally change our "LTS" policy and we have no control over what version Odoo will screw or not. That being said, there is also an OCA effort resonance happening on Odoo uneven releases. Look how many modules every Odoo version has 1 year or 2 years after release and it will be clear that this is not just an Akretion thing. In the future, eventually migrations become simpler and we follow every version, I can not tell you except that this would be the condition.About migration cycles:Even if you go for an uneven LTS strategy, not every company may migrate every 2 years (or less), that is just not true. Large projects may need to invest for 1 full year for the implementation, not sure it's appealing to invest 20% of the implementation cost the next year to migrate immediately. The newer the version you migrate too, the more expensive it will be as you will eventually need to migrate the OCA modules yourself or even dig into the early OpenUpgrade bugs/limitations. A company can have a bad year, the integrator may not be available. The market is growing a lot, lots of new integrators have just not the experience to be able to migrate 1 or 2 years after they started their 1st projects where they likely did a lot of shit...As soon as you admit this, having secure versions for only 3 years before being forced to migrate is not appealing at all. I think 4 years (2 LTS cycles) would be a wiser stance.A business opportunity for the OCA?Since Odoo SA says they take care of security for only 3 years, eventually this gives room for the OCA to brag "the OCA ensures the security patches from recent Odoo releases are backported for 4 or 5 years". We may not promise it's all secure, but IMHO promising this backport is cheap and may drive more audiences to the OCA.About Odoo SA trying to please the VCs.It has been very true in the past and eventually shaped the released cycle. But we know it's no longer true: despite nearly losing control to the VCs back in 2015 (as Fabien admits himself that had only 2 month of cash if they didn't made the last VC round where they had to change the license and start doing proprietary code), they now managed to get totally independent from them again. Eventually we were pissed of by the risk taken while we didn't choose open source for that kind of risk. But it's over now. That being said, Odoo SA is now a company with many salesmen and managers, sort of unproductive people and consequently they need to sell new projects like mad to feed everybody. So eventually they are structurally doomed to keep riding the rocket.About security and Python versions:again IMHO the OCA is not wise when it follows Odoo SA Python version policy, like have the v14 CI run Python 3.6 (end of life next year). Because what we see with the Odoo CVE also just happens in the Python packages we depend on. In new fields like web, API connectors, ecommerce, SOAP... Python packages come and go, replaced by newer technologies. Newer packages use recent Python versions and loose compatibility with older Pythons. Hence if you use an old Python, chances are your Python packages have much more CVE that will not get fixed, not even for a newer Python (a new lib might be used instead). IMHO, Odoo SA supports older Pythons by accident because they come from legacy, But just because they support it by accident is not a good reason for the OCA to align to this policy. We don't run the CI on windows just because Odoo SA also make Odoo instalable on Windows, right? So why cannot we say: "you want Odoo 14? The OCA CI ensures it works on Python 3.7+, so evolve your distro before starting your real life project, doing that may give you 1 extra year of CVE free packages in the future."About web enabled ERP and security:We have to face it: how many not up to date Odoo ecommerces and portals are there around in the wild? Now think about how easy it is to take the CVE list of Odoo and of its old Python dependencies and scan the web to attack these older Odoos? Think how hard it is to migrate and how naive were some companies to do an Odoo ecommerce before understanding this. Think if company X has an unfair competitor Y ready to pay a hacker to use these CVE to attack the old Odoo, think how easy it is to take over the company X data or even spoil its ERP... At Akretion this is the kind of reasoning we had before building Shopinvader for instance.Regards.On Thu, Dec 31, 2020 at 11:12 AM Pedro M. Baeza (Tecnativa) <pedro.baeza@tecnativa.com> wrote:For me the path is clear: upgrade to the latest possible Odoo version, and that's why OpenUpgrade is done and funded by OCA itself, and the most famous OCA modules are migrated to all versions by regular contributors.Regards._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Raphaël ValyiFounder and consultant_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
by Juan Del Castillo Gómez - 03:01 - 2 Jan 2020
Reference
-
OCA and security notices
Hi community,
Yesterday a security notices has been published.
Stefan has begun to bring one security fix to OCB with this PR
It raises what seems to be an important point about the handling of the security fixes for the unsupported Odoo version on OCB. Will this should be taken in charge by OCA, as OCB is under OCA umbrella or it'll remain on the goodwill of the community's members ? I don't have any problem with one of the possible responses.
My point is how do we takle the minimum about this topic. I mean how do we organize the contribution members on this topics ?
My first idea will be to open an issue on OCB for each security notice and organize the work as it done for modules migration. What do you think ? Creating a PSC team security could be another idea.
Finding the security issues seems to be easy but at this point we don't have a tracking on the ones that are brought back on the unsupported version on OCB.
Here at Coop IT Easy we'll probably focus on the versions affecting our customers it means 9.0 as 11.0 and later are still supported.
Regards,
Housine
by Houssine BAKKALI - 11:46 - 23 Dec 2020-
Re: OCA and security notices
Hi, Xavier,The delay depends on 2 factors:- The technical work to be done, which is the installed core modules to be covered by OpenUpgrade + the OCA modules to be migrated. This can be complemented with use cases test suite to be checked.- The customer alignment for the best moment to migrate, depending on their activity.FYI, we are migrating our customers to v13 now, having 4 of them on 13.0 already, and the rest coming in the following months.Regards.El mié, 6 ene 2021 a las 19:07, Xavier Brochard (<xavier@alternatif.org>) escribió:Hi Pedro I've found your post very interesting. However can you elaborate a bit on the delay before migration ? Obviously you can't migrate before the newest version is stabilized enough, but you can't also migrate before OpenUpgrade is available (or do you migrate "by hand" ?). So, are you curently running Odoo 13 and planning migrations around june ? Best regards Xavier / zeroheure --- Librement, Xavier Brochard xavier@alternatif.org La liberté est à l'homme ce que les ailes sont à l'oiseau (Jean-Pierre Rosnay) Le 05.01.2021 09:27, Pedro M. Baeza (Tecnativa) a écrit : > Hi, Tom, > > Each version can have some bugs, but it's better to handle them > between more people than let SaaS users or the same partners to > notify/fix them. You think it's "safer" to be on a previous version > for avoiding such bugs, but the facts are: > > - Such a bug is because of your use cases, and it will be found on the > version you are using, no matter if outdated or not. Nobody till then > may notify it. > - Odoo is fixing bugs very quickly and without effort by your part on > the latest version (or the previous one), as they are committed to > "stabilize" that version, but not on very old versions. A note about > this: notifying properly a bug is the key for having it solved. You > can't expect to have the work done not doing a minimum effort on your > part. > > - Bugs can happen even on unsupported versions, so the maintenance > cost starts to rise if you need to fix them by yourself and you are > introducing regression risks. > - There are even occasions where the bug is fixed or doesn't apply on > higher versions, but you don't have it in an outdated one. See the > recent CVE cases and the effort needed by Stefan and Nils. > - Odoo continues to improve its test suite, and each version has more > and more stability/quality. > > Other facts about using outdated versions: > > - You need to "backport" features that are on higher versions or lack > them. > - Framework evolves, and using an outdated framework makes your > development team to require more time to complete the same tasks, or > to not have available some tools. Programming in 2020 with the old API > or the v8/v9 hybrid for me is horrible. > - Collaboration possibilities are reduced working on an outdated > version, as there are less contributors on them. You can see the same > examples on your 7.0 PRs, or even on the 10.0 PRs, that is more > recent, but the same unattended. > - As a complement to the previous one, new contributors push newer > versions, not old ones. > - Underlying libraries and dependencies are outdated as well, with the > problems this supposes. > > So at Tecnativa we deal with this not having middle positions: all our > customers go to latest versions (the supported ones), and we reject > those that don't want this approach. That way, we focus on dealing > with a reduced set of Odoo versions, we migrate them regularly (not > forcing a yearly migration, but more and more customers demand to go > to each version and they don't want to keep the same version 2/3 > years), and we report bugs to Odoo constantly that makes the versions > stable enough. > > Migrating OCA modules is not a problem while you are on the wheel. The > keys are: > > - Having a team used to OCA guidelines. All our developments follow > strict guidelines. This makes the team to take the habit and don't > require more time to be "OCA". Anyway, 95% of our developments are > directly OCA. OCA first approach is also very important for us. > > - Having good test coverage. This is vital for easing the migrations. > Doing good tests is not easy, but the time spent on that will be for > sure gained later. This includes also JS tour/Qunit tests if needed. > - Reviewing PRs between colleagues as part of your development cycle. > This raises a lot your team skills and don't stuck PRs. People > complain about their PRs not being reviewed, but they don't review > others in exchange or don't push colleagues to review them. > > We also take a proactive position for handling some "polemical" > decisions taken on the versions, creating OCA modules that fill the > gaps. This is better IMO than staying on an older version and > complaining that "Odoo has removed this or changed that". In general > you win more than you lose on newer versions. > > And finally, customers receive a refresh training on each version > change. Being proactive as well on the changes they have makes people > to not reject the new version and embrace the new features from the > beginning. > > Do I convince you, hehe? > > Regards. > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 > Post to: mailto:contributors@odoo-community.org > Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Pedro M. Baeza - 12:36 - 7 Jan 2021 -
Re: OCA and security notices
Hi, Tom,Each version can have some bugs, but it's better to handle them between more people than let SaaS users or the same partners to notify/fix them. You think it's "safer" to be on a previous version for avoiding such bugs, but the facts are:- Such a bug is because of your use cases, and it will be found on the version you are using, no matter if outdated or not. Nobody till then may notify it.- Odoo is fixing bugs very quickly and without effort by your part on the latest version (or the previous one), as they are committed to "stabilize" that version, but not on very old versions. A note about this: notifying properly a bug is the key for having it solved. You can't expect to have the work done not doing a minimum effort on your part.- Bugs can happen even on unsupported versions, so the maintenance cost starts to rise if you need to fix them by yourself and you are introducing regression risks.- There are even occasions where the bug is fixed or doesn't apply on higher versions, but you don't have it in an outdated one. See the recent CVE cases and the effort needed by Stefan and Nils.- Odoo continues to improve its test suite, and each version has more and more stability/quality.Other facts about using outdated versions:- You need to "backport" features that are on higher versions or lack them.- Framework evolves, and using an outdated framework makes your development team to require more time to complete the same tasks, or to not have available some tools. Programming in 2020 with the old API or the v8/v9 hybrid for me is horrible.- Collaboration possibilities are reduced working on an outdated version, as there are less contributors on them. You can see the same examples on your 7.0 PRs, or even on the 10.0 PRs, that is more recent, but the same unattended.- As a complement to the previous one, new contributors push newer versions, not old ones.- Underlying libraries and dependencies are outdated as well, with the problems this supposes.So at Tecnativa we deal with this not having middle positions: all our customers go to latest versions (the supported ones), and we reject those that don't want this approach. That way, we focus on dealing with a reduced set of Odoo versions, we migrate them regularly (not forcing a yearly migration, but more and more customers demand to go to each version and they don't want to keep the same version 2/3 years), and we report bugs to Odoo constantly that makes the versions stable enough.Migrating OCA modules is not a problem while you are on the wheel. The keys are:- Having a team used to OCA guidelines. All our developments follow strict guidelines. This makes the team to take the habit and don't require more time to be "OCA". Anyway, 95% of our developments are directly OCA. OCA first approach is also very important for us.- Having good test coverage. This is vital for easing the migrations. Doing good tests is not easy, but the time spent on that will be for sure gained later. This includes also JS tour/Qunit tests if needed.- Reviewing PRs between colleagues as part of your development cycle. This raises a lot your team skills and don't stuck PRs. People complain about their PRs not being reviewed, but they don't review others in exchange or don't push colleagues to review them.We also take a proactive position for handling some "polemical" decisions taken on the versions, creating OCA modules that fill the gaps. This is better IMO than staying on an older version and complaining that "Odoo has removed this or changed that". In general you win more than you lose on newer versions.And finally, customers receive a refresh training on each version change. Being proactive as well on the changes they have makes people to not reject the new version and embrace the new features from the beginning.Do I convince you, hehe?Regards.
by Pedro M. Baeza - 09:21 - 5 Jan 2021
