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.
Related
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
I moved to Bolt 4 (from Bolt 3.7) and would like to implement front-end user to give them access to private contents of the website. Previously, I used the extension BoltAuth/Auth, which worked like a charm.
Now in Bolt 4, there is no easy way like in Bolt 3.x to install an extension from the back-end page. I found out I could use composer to do so, but I run in the following problem:
> composer require "boltauth/auth:3.0.1"
[InvalidArgumentException]
Could not find a matching version of package boltauth/auth. Check the package
spelling, your version constraint and that the package is available in a stability
which matches your minimum-stability (stable).
Either I do something wrong, or the extension is not compatible with Bolt 4.1.
Could someone tell me if there is a way to make this extension work? Or alternatives for front-end user management?
EDIT: I'm now using the bolt/users extension as it can be used to add a ROLE_MEMBERS and let users login for the frontend.
Yes, unfortunately the architecture for plugins (mainly driven by the move from Silex to Symfony) changed completely between 3.x and 4.x and it's not really feasible to release new 4.x compatible versions.
So for now there won't likely be updates to BoltAuth. It may be worth joining the Slack community and seeing if any other developers are working on 4.x compatible solutions to the client login scenarios.
SafeNuget (an OWASP project) audits a .NET project for vulnerable Nuget Packages from this github source
There is a misconception that because the package has an old date, that it consequently contains out of date package signatures... creating a circular issue where people don't use or issue pull requests to unsafepackages.xml.*
Screenshot of version history as of 1/17/17
Question
To address the usage and deployment issue, how do I ensure that all new projects leverage this package on File:New?
PS: I hope by asking this question I increase the visibility and viability of this potentially valuable resource.
What's the dealio on importing data from a legacy issue tracker system into Gitlab CE?
Do tools exist for this? Schemas? Suggestions?
Please notice that this is really a legacy issue tracker system. It predates bugzilla, and runs on an old IIS server and SQL Server 2000).
(Say whatever you want about this setup, but it's nothing we haven't already heard.)
You should be using the REST APIs to create your migrations.
Generally recommendation questions are off topic, so if I mention
there is a redmine issue importer and there are issue tracker issues on the gitlab ce issue tracker requesting this. This sounds like a good kind of thing to make as a community contribution if it's a popular tool.
But if it's not, and you're the only person in the world using your tracker, you probably will want to study the python based redmine issue importer it may server as an example for you to write your own REST-api based tool that reads your db and creates the Gitlab Issue Tracker issues. You don't want and don't need to know the Gitlab side's PostGres schema. It will change over time anyways.
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.