When I launch WSO2 API Manager, I get the following notice:
There are 177 updates available for the product 'wso2am-3.2.0'.[WARNING] There
are 13 critical security updates for the product 'wso2am-3.2.0'. WSO2 strongly
recommends to apply these updates in production as soon as possible.
WSO2 doesn't bundle security updates, so I head to the GitHub issues. The problem is that if I go to the security tag, I don't see anything relevant to the 3.2.0 release: https://github.com/wso2/product-apim/issues?q=label%3Asecurity+is%3Aclosed
There is one "critical for 3.2.0": https://github.com/wso2/product-apim/issues?q=label%3ASeverity%2FCritical+label%3AAffected%2F3.2.0
There are two more using this deprecated tag: https://github.com/wso2/product-apim/issues?q=label%3ASeverity%2FCritical+label%3A3.2.0
So, it seems like what you have to do is look at the 4.0 milestones and cherry-pick those fixes and backport them.
Is there a tag I am missing? Is someone bundling these?
Thanks!
You can find the security advisors in here https://docs.wso2.com/display/Security/2020+Advisories
Related
We have passed Apiman-2.0.0.final through security scans and came up with some critical/high vulnerabilities, mostly relevant to keycloak-core-10.0.2.
Fixes for this vulnerability are available in higher versions of keycloak.
I would like to know how do you handle these scenarios.
Should we repackage the war locally for us to use? We can create a pull request if it works.
Should we open a Jira item? I cannot see 2.0.0 being supported on red hat Jira. https://issues.redhat.com/projects/APIMAN/summary
Please post issues on our GitHub issue tracker, not stack overflow https://github.com/apiman/apiman/issues
We're using a newer version of Keycloak for the upcoming community release. You can indeed use your own separate Keycloak instance (recommended for a real deployment), rather than the one bundled in the quickstart.
Im use a Elasticsearch 5.1.2 (docker installation) and integrated with a project generated with jHipster 4.0.2.
After configure Elasticsearch, Elastic show the message:
java.lang.IllegalStateException: Received message from unsupported version: [2.0.0] minimal compatible version is: [5.1.2]
sn_elasticsearch |
Its posible to upgrade the client version of Spring Data Elastic integration in jHipster project? Someone knows how to?
[]s
spring-data-elasticsearch does not support version 5 yet. It is a work in progress by a team of volunteers (not driven by the Spring Data team).
According to the latest post on GitHub where you can track the issue:
Given that we will look into upgrading elasticsearch to latest version and as #olivergierke suggested it will be released with Kay if we will be able to merge changes before RC1 which is in mid March [2017].
This pull request still require major week or two of a work, its not straight forward merge. We are independent resource(s) willing to contribute on this project wherever we can, anyone who is willing to do the same is more than welcome to contribute.
We will keep posting update from our side about upgrade on the same thread.
I add all needed information about GitLab account in Sentry, but issues from Sentry didn't appear in Gitlab (repository is private and just for test without real code). Please help me to solve problem.
Sentry doesn't auto-publish issues to issue trackers like GitLab (as it would easily flood most issue trackers). Instead, once you've enabled the integration, your Sentry's issue view will have a "Create issue in GitLab" button.
Note that GitLab 11.8 (Feb. 2019) not offers Error tracking with Sentry
Keeping an eye on errors generated by your application helps maintain a good user experience by detecting problems before users report them and speeding up resolution when they occur.
GitLab 11.8 makes it more convenient and efficient to monitor errors by integrating with popular open source error tracker Sentry, and displaying the most recent errors right within your GitLab project.
Sentry has recently improved their GitLab integration, enabling detection of suspicious commits, release and commit tracking, and more. With the combination of both integrations you’ll have a simple path to Sentry from GitLab, as well as a clean way to get to GitLab from Sentry, so that you can always address errors contextually, staying within your existing workflow.
See documentation and issue 55178.
And, with GitLab 14.4 (October 2021):
Integrated error tracking inside GitLab without a Sentry instance
Prior to GitLab 14.4, you could integrate with Sentry Error Tracking by supplying an endpoint for a Sentry backend (either self-deployed or in their cloud service). With Gitlab 14.4, you now have access to a Sentry-compatible backend built into your GitLab instance. This allows you to quickly instrument your apps so your errors show up directly in GitLab without the need for a separate Sentry instance.
See Documentation and Issue.
See GitLab 15.5 (October 2022):
Error Tracking Open Beta
In GitLab 15.5, we are re-enabling GitLab integrated error tracking for GitLab.com in Open Beta. We’ve reworked the architecture so it uses our new Observability backend, leveraging the ClickHouse database as a unified data store. This improvement will enable scaling and a more performant system for the user.
In addition, this sets the groundwork to have errors in the same database as other observability data such as metrics, traces, and logs. We want to allow users to see errors on the same dashboard as other observability data, and enable them to be embedded into issues and incidents.
See Documentation and Issue.
I'm getting started with sonarqube (Version 3.7.2) and have installed
the Security Rules [securityrules] plug-in (version 0.3.2).
After deploying the plugin it seemed to activate OK (see Evidence for Successful Plugin Activation, below). I re-analyzed my project and then went to the dashboard, but i could not see
the 'security defects' icon which (according to this document: http://docs.codehaus.org/display/SONAR/Security+Rules+Plugin) is supposed to appear.
I was planning on using that 'view' to drill into a view of only security related issues.
My question is:
is there any other way to do this filtering (besides the security defects widget?)
is there any reason why that widget would not show up.
I understand the securityrules plugin is deprecated for later versions of sonar, but i'm using an older version which should be compatible.
Evidence for Successful Plugin Activation
after restart the plugin appears in the list of 'Installed Plugins' In the Update Center.
In 'sonar.log' i see this statement:
2014.12.17 07:35:57 INFO o.s.s.p.PluginDeployer Deploy plugin Security Rules / 0.3.2
thanks in advance !
-chris
You can create a quality profile which contains only rules of the security plugin. Then you execute the analysis with that profile.
The answer turns out to be very simple. After activating the plug-in I needed to configure the dashboard for the project i am analyzing so the security widget is added. This page describes the mechanics: http://docs.sonarqube.org/display/SONAR/Customizing+Dashboards
We have a liferay portal running on a hosting company, and We want to bring it to our own structure. So, I've downloaded the excellent bitnami stack and loaded it in our vmware server.
I've no experience on liferay whatsoever, all I know its that it uses mysql as database. Is there any docs on how to do it?
Tks!
Use the Liferay's Wiki:
5.0 to 5.1: http://www.liferay.com/community/wiki/-/wiki/Main/Upgrade+Instructions+from+5.0+to+5.1
5.1. to 5.2: http://www.liferay.com/community/wiki/-/wiki/Main/Upgrade+Instructions+from+5.1+to+5.2
I recommend to do a 2-step upgrade since direct upgrade from 5.0 to 5.2 is more troublesome.
There have been reports that it's some work to upgrade older versions to the latest and greatest, so you should be prepared for some efforts.
That said, the way you should go is to backup the previous installation (e.g. all directories, database entries etc) and deploy that on your own server. This installation then is updated to the latest version by installing the latest version and pointing it to the data from the previous installation. During the first startup, liferay will (given sufficient privileges on mysql) update the database structure and everything it needs. Keep your backup ready and test thoroughly if everything is upgraded the way you intended it to be.
Also you need to keep an eye on your customized stuff - if you have portlets or other components that use the liferay api, you might need to upgrade those manually to take changed APIs into account.
Theoretically that should be it. I've heard of people having had some problems with this - but it all depends on your level of customization and utilization of features in liferay.
The liferay folks intend to circumvent this in future with their EE environment, where you get better defined upgrade paths and long term support with minor upgrades to your environment, keeping APIs and database requirements stable. I'd hope that even upgrades between major versions will benefit from this, but have not yet tried it.