The module libxml2 contained in several components of GitLab version 14.9.x is vulnerable to out-of-bounds memory writes as described in https://security-tracker.debian.org/tracker/CVE-2022-29824. GitLab seems to not patching it or mitigating the risk in the latest stable version 14.10.x. Actually I even cannot find any article on the internet about this problem in relation to GitLab.
Does anyone know why? Is it because it just does not affect GitLab?
I am using the self managed version of GitLab.
Related
I have a self hosted gitlab-ce in a docker environment.
As upgrading GitLab is a pain, I did not do it for a while and now it looks way too complex.
Also there are no good material on how to do this step wise.
Has anyone done this before: what process are you following?
The main advice from the official documentation is to avoid skiping a major version.
In your case, upgrade first to 13.11.
Then 14.1.0.
That way, you can detect any specific setting to update fro one version to the next.
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.
Here's my project development process:
feature/feature1
feature/feature2
feature/etc..
master
production
I develop my features on the features branches, when I have finished with a branch, I merge it on master and delete it via github ui. CircleCI detect the merge and deploy the master on a staging server.
Later I merge manually the master branch onto the production one, and CircleCI deploy to my productions server.
I would like my package.json version to bump each time I merge a feature branch to the master branch (via github UI). But I have no idea if
Github allow to do so (if yes please can you explain to me?)
It's a good process
I'm aware I could do it via npm version command when I merge master onto production, but I do need the version to be updated on the master automatically when I merge a branch into it.
Don't hesitate to criticize my way to proceed and tell me yours. :)
Thank you
I don't think Github offers any such feature. But there are some grunt modules that do this during build time. You could probably script this or have a make file that does this for you as well.
I don't think this is good way of versioning. After you are done with a feature, you have to decide if the changes you have made are minor or major. Some times you might commit breaking changes. Just incrementing the version number form 1.0.1 to 1.0.2 or say 1.1.0 to 1.1.1 (every time) will not convey the magnitude of these changes. Best Practice: Software Versioning
The best practices for versioning are already covered here.
We manage versioning manually where I work. Before each release we create a tag (v1.0.3, v1.1.4..etc) and then create a release on Github. In the description of the release we put all new commits. Going through the commit message gives us a good idea of the changes that were made. If the changes only involve bug fixes and minor feature additions we will increment the minor number ie. 1.2.1 to 1.2.2.
If a major new feature is added, we increment the major version number ie. 1.2.2 to 1.3.0. When we add many breaking changes we go from 1.3.0 to 2.0.0.
Sometimes we are loose with versioning. Our API is not public and the only reason we use versioning is for deploying and for rolling back. If you are expecting to make you work open source and or expecting to make your work available through some kind of package manager, like say npm, you should follow semver versioning strictly.
When browsing the packagist.org repositories you see packages with these version numbers e.g. If you look at the Phpunit repo
There are a few instances
4.5.x-dev
4.3.x-dev
4.2.x-dev
Do these packages contain the current work the developers are performing towards basic updates, security and bugfixes etc on an otherwise basically stable package?
These are the dev branches. These are unstable and contain bug fixes, etc. This will eventually be released as 4.5.8 for instance (if the library is still supported).
You can get it by using 4.5.x-dev or 4.5.*#dev as version constraint.
I'm going to upgrade my company's subversion server from version 1.6 to 1.7. The server runs on linux (Ubuntu AFAIK).
I've read all those:
Subversion 1.7 release notes
I've also read those posts:
subversion-client-version-confusion
how-to-upgrade-svn-server-from-1-6-to-1-7
Here and now, I know how to perform this. It's not a big deal. What concerns me the most is the current hooks infrastructure. There are several scripts in bash and perl.
As for now I've found no information referring hooks infrastructure changes, but maybe there are some known issues I missed? Is there anything against the upgrade I should know?
PS: Try and see what comes method is absolutely unavailable. I'd like the upgrade to be as fluent as possible. Repository users shouldn't even notice any changes. I can't allow myself any failure in that matter.
The Subversion compatibility guarantees promise that your hook scripts are called exactly the same in 1.6 as in 1.7. In 1.7 (and future versions) more arguments can be passed to scripts, but the old arguments still match the old behavior. So if you created your scripts like the templates, to ignore 'extra' arguments you shouldn't see a difference.
Subversion 1.7 didn't change the repository format since 1.6, so you can even (accidentally) use the svnlook from 1.6 to access the repository after upgrading.
Try and see what comes method is absolutely unavailable...
Yes, the try and see what comes method is available. You build a copy of your Subversion 1.6 environment, make the Subversion 1.7 changes, and test until everything is correct.
I don't see how you can accomplish your goal of a quiet upgrade unless you copy and test.
I guess it depends what you do with your hooks...
If your hooks are using svnlook, you should have no issues. If you're using an API (like the Python API), you probably are also okay as long as you're doing svnlook type of stuff.
Where you might start heading into problems is if you poked and prodded where you weren't suppose to poke and prod. For example, instead of doing svnlook, you do svn. There are a couple of places where the parameters have changed. Also, if you did an svn checkout (an absolute no-no in a hook) and then looked in the .svn directories, you'll get a surprise. Follow the rules, color in the lines, and your hooks won't have any issues.
I don't know of any issues from Revision 1.1 to revision 1.7 that should affect well behaved hooks hooks, and I suspect that you will not have any issues as long as we are still in Subversion 1.x. When Subversion 2.x comes out, all bets are off.
Yes, there have been some changes in how hooks work. The start-commit hook has an extra field that wasn't in versions 1.4 and earlier (The capabilities field), but nothing that would affect current hooks. And, in either Subversion 1.5 or 1.6, users now can set revision properties when doing a commit. These don't affect current hooks, but might be features that you want to incorporate in your current hooks.
The upgrade has been performed and succeeded. Subversion server was updated without issues. Hooks were designed without any hacks or slashes, respecting the rules and common sense. It was risky but promising and came out profitable (checkouts are light-speed now).
Just for sake of completeness: there was a consecutive centrally managed client upgrade. And there were issues, however not critical and predictable. After transition svn client 1.6 -> 1.7.7 working copy format changed. Every existing working copy had to be manually upgraded (or wiped out and checked out clean again).
Server upgrade is safe though.