We are still running Magento community version 2.3.4x.
We are upgrading since 4 months to current version, there were many plug-ins not compatible and so on.
Now we are about 2-3 weeks before we can fully switch.
On 11. of Oct. Adobe released:
Security update available for Adobe Commerce | APSB22-48
https://helpx.adobe.com/security/products/magento/apsb22-48.html
But our version of out of service since one month.
So we can not switch now, and there is also no patch.
Adobe Commerce 2.4.5 and earlier versions
What can we do until then?
I know this is not an adequate question here, but since It will probably affect 60% of all Shop worldwide, it's necessary to ask this here.
Maybe try this: https://github.com/EmicoEcommerce/Magento-APSB22-48-Security-Patches
This repository contains Magento 2 Patch Files for the recently found security issues on 12-10-2022. The patch files aim to fix the CVE-2022-35698 and CVE-2022-35689 vulnerabilities.
Related
Is there a chart/statistic which versions of Shopware 6 are used by online shops actually.
Background: developing custom plugins, it's hard to cover all versions from 6.1 - current (6.4)
I would suggest supporting the releases since the latest major release 6.4, which has first been released 1 1/2 years ago. That's ample time for users to have updated to one of the minor releases since then. When you offer plugins in the community store you'll get an overview which Shopware versions your plugin is used with. Looking at the data of my plugins I can tell you that the vast majority is now at 6.4. Without breaking changes it should not be a problem supporting all 6.4 releases and with the 6.5 major release coming next year you should be able to cover a significant userbase by supporting both the upcoming and the current major release.
I use and love cygwin, but every few weeks it notifies me that a new installer is available and I should use it to get the latest bugfixes. But I find this quite annoying because of my company policy, where downloading, installing and running a new .EXE file is a bit of a process due to paranoid company monitoring software.
I am just curious why the installer updates so frequently and what will happen if I don't update it. It is after all just an installer - all it does is it downloads updated packages and installs them (or rather, that is what I believe all it is doing). I do not understand why such a simple tool should have so many fixes/updates over time. If I don't update the installer, will I miss out on updates to the cygwin packages themselves?
I have been using the same cygwin version since years now and not faced any issues.If the application is working as expected then you dont need an update unless you face some trouble or you are migrating to a new windows Os which might have some compatibility issues.
Note : There is no guarantee that there will not be any problems with applying updates and also the cygwin faq section says that after updates issues should be reported to the project or product supplier for remedial action.
https://cygwin.com/faq/
The changes in Setup are usually to improve the functionality or correct some
issue.
See relative Announce:
https://sourceware.org/pipermail/cygwin-announce/2021-April/010021.html
Most of the time, previous version continues to work fine.
Broke of compatibility is very rare.
I would like to ask a question about wether or not I should do the migration to Liferay 6.2.
Me and my team are working since 4 month on a portal quite big developed with Liferay 6.1 (CE edition) and now, since the project publication date is still 4-5 month ahead (so I do have time), I was wondering if doing the migration to 6.2 now is a good choice.
I already tried the new version and I must say I am impressed about the new features and since now I haven't find any bugs.
Anyone had any experience on developing portlet/themes on Liferay 6.2? Is is worth it to do the migration now or shall I wait for the next ga2 release?
Any suggestion is very welcome.
Thanks
Depends mostly on the kind of work you've done on that portal. Even slight upgrades in Liferay, can have major differences in the source code. If this affects the work you've done, it will affect the upgrade too. For example, things will get difficult to update if :
You have developed custom portlets, as they will need recompilation for the new runtime
Developed Portlets that use ServiceBuilder might need more work than just a recompilation
Using Hooks (even simple jsp hooks) might need re-writing. ext hooks will almost certainly need to, and it can become a major pain
On, the other hand, if most of your work had to do with light theming and content management, it could become an relatively easy and painless upgrade.
In any case, make sure to keep a backup of your Liferay Database, because once you upgrade, there is no way to downgrade back to the initial version.
As you're using CE, my recommendation is to upgrade as soon as possible. Reason is that there are no more updates for 6.1, now that 6.2 is out. If you're going live in 5 months, you'd be on a version that's unsupported for half a year at the date of publication.
The alternative is to go to EE, which is supported for ~5 years from release, e.g. you'll have several years of support in front of you. However, as Liferay is paying my salary, note that I might be biased...
Of course, being unsupported "by Liferay" does not mean that you won't be able to fix any bugs or issues, but you'll have to do this on your own, and sooner or later you should upgrade anyway... If you're not yet live, I'm recommending to do it sooner.
Liferay 6.2 does not (yet) support as many marketplace apps as Liferay 6.1. Also Liferay 6.2 CE has bugs, and patches are available only to EE subscribers; this forced us to use Liferay 6.1 CE instead of 6.2 CE.
You will have issues if you are using the Vaadin framework under Liferay.
Liferay 6.2 CE does not support Vaadin out of the box ... it is delivered with Vaadin 6.8, but it is broken - your portlet code will break.
You would have to consider moving to Vaadin 7.1 at best ... and that is a non-trivial code migration as many items have been deprecated between 6.8 and 7.
I went that route and the learning curve was unexpectedly steep.
Today, our Enterprise Architect mentioned that a recent vulnerability was discovered in the JRE 1.7. I found an article the JRE 1.7 vulnerability recommending disabling Java.
I am running JDK 1.5 and 1.6 at work (like many organizations, we're not on the latest of technologies), so no problems there.
At home I am doing development with Java SE 7u6. I'm playing with Grails, Spring Security, trying to keep learning.
I have already gone and disabled the Java Plug-in in all my browsers on my home development machine. However, does anyone know if my home dev machine is still vulnerable by virtue of having the JDK 7 installed? I did find this article on US-CERT declaring the vulnerability notice: Oracle Java JRE 1.7 Expression.execute() fails to restrict access to privileged code.
It sounded like as long as the browser is not able to run Applets, I should be fine (it should not with the Java Plug-in disabled). However, what about Java Web Start/JNLP? Could that get invoked? That's the only other thing I could think of, other than Applets, that might be of concern.
Just wondering if I need to go through the efforts of uninstalling my Java SE 7 and dropping back to a JDK6.
What have others done upon learning of this security issue with JRE 1.7?
The details of the latest vulnerability have not been made public. However, my understanding is that it only affects Java browser plugins. The recommended mitigation is to disable the Java browser plugins. No mention is made of non-plugin Java, so I think it is safe to assume that your dev machine is not vulnerable simply by virtue of having Java 7 installed.
However, what about Java Web Start/JNLP? Could that get invoked?
I don't think so. I think it is safe to assume that the people who found the problem would have thought of that potential attack vector. (But simple common sense says that you wouldn't want to be launching random JNLP programs in the first place ...)
I understand it as if you have to visit a malicious site to become infected. So no, you are not at risk simply by virtue of having Java 7 installed in your browser.
Some useful links:
US-CERT link which explains the vulnerability:
http://www.kb.cert.org/vuls/id/636312
Oracle link to their Security Alerts (not just Java, but also including Java):
http://www.oracle.com/technetwork/topics/security/alerts-086861.html
As of writing (30 Aug 2012) I cannot see that Oracle has yet issued an alert for this. I can't really figure out if they only issue such alerts AFTER a patch has been created. According to US-CERT site Oracle was officially alerted on 29 Aug 2012 but they may already have known about it because blog reports about the vulnerability started a few days before the 29th.
What you can read on the Oracle site is that the next planned "Java SE Critical Patch Update" is on 16 October 2012. Surely they won't wait for that but release an out-of-band patch for this vulnerability asap. (they've done so before)
I have a project built around Subsonic 3.0.0.3 and have run into the dreaded medium trust issue, can anyone tell me is there a way I can mod the code myself to get this working or what the expected timescale for 3.1 version is? Its looking increasingly like I will have to ditch subsonic to get my system running
Regards
Mike
No timeframe for SubSonic 3.1 (or 3.0.0.4), but here are the current plans: http://groups.google.com/group/subsonicproject/browse_thread/thread/caae09418ce4d975/
The SubSonic Google discussion group is the best place to find out about the current development happenings for SubSonic.
Short answer, as soon as possible.
Long answer, there's a number of things planned for 3.1 these include (but are not necessarily limited to):
Oracle support
MediumTrust support
Automatic mapping of collections in SimpleRepository
These are all in development right now but before they become the main focus we need to get version 3.0.0.4 out the door with fixes for a lot of the outstanding issues listed on github. There's also a lot of more boring work going on behind the scenes which should make regular and stable releases easier.
The current release schedule is:
Version 3.0.0.4 - 22nd March 2010
Version 3.1 - 22nd May 2010