Open Discussion

[mark-netalico]

The purpose of this fork and effort is to maintain Magento 1.9, focusing exclusively on security and future interoperability (i.e. now SUPEE 6788 disasters). Ideally, people should be able to auto-update without fear or extremely low probability of any breaking changes.

I know there are other projects like OpenMage and MageOne that have varying purposes. This project isn't an effort to replace them. I would like to create a program where we collaborate with any other M1 fork to provide them security notifications/updates for them to integrate in their forks.

Priorities:

• Keep up with PHP EOL versions. Versions will be based on PHP versions. i.e. Magento 1.9.7.4.x will support php 7.4. 1.9.7.4.0 will be the first version that supports php 7.4.
• Create a bug bounty to capture zero day vulnerabilities. To be eligible you must submit updated code to correct the issue.
• Other projects may apply to have additional notification of zero-day vulnerabilities, but they are also required to provide the same advance disclosure if they come across them.
• Maintain CVE's
• Remote Code Execution, SQL Injection
• Web hosting sponsorships.
• Agency sponsorships

Tangential:

• Optional Bundled (Opt-in) hardening methods. i.e. CSP. Malware/3rd party vulnerability notifications.

[psolovyov]

I think it should probably start with a forum where the updates and community can live on. Example of community like that would be WebHostingTalk.

OpenMage creators talk about any additional features being added as plugins - so maybe that is the way to work around editing core files with these updates.

Also, the project definitely has to include sponsors who are interested in it - somebody like Nexcess. Commercial involvement is very important, because their interest in the topic will supply needed $$$ for bounties and improvements that community cannot do in time.

[mark-netalico]

I plan to put in upfront money to fund the bug bounty program at the start but would like to get hosts to maintain the fund long term. I think that the agencies involved can be more beneficial in testing/QA'ing new security releases to ensure the least possible disruption.

I think these new security releases can be much better tested because we will not be creating updates for very many versions. At most 2-3 versions (for different php versions). I don't want to force people to update php prematurely, but we do need to keep up with the php versions for the purposes of security.

[gwillem]

Have you reached out to hosts yet? Nexcess, Magemojo, Sonassi, Mgtcommerce, Hypernode?

[mark-netalico]

I've had some initial conversations with people from most of those hosts. I'm getting their feedback/comments. If any other hosts would like to speak please shoot me an email: mark@netalico.com

[mark-netalico]

Based on some discussion, we might want to provide a PHP 5.6 compatible version of security updates as well as many merchants are stuck on 5.6.

[sylvainraye]

why not putting the effort into the OpenMage Project ? Why doing several forks ! Basically the idea of securing the M1 branch is good but pls do not make 1K forks...

[mark-netalico]

That's a valid question. In general, OpenMage has more of a focus on keeping M1 alive as a platform indefinitely and to keep building/bug fixing on it. And I think that's great too. But the primary gap I'm seeing is for merchants that are on M1 and that want to keep using it securely as is. This project will also require funding for the bug bounty program. OpenMage and any other projects are welcome to utilize the security updates we release in their versions.

[mark-netalico]

@sylvainraye https://openmage.github.io/magento-lts/alternatives.html ❤️