facing the below error during .fpr file upload.
"Exception: The version of rulepack "HPE Security Fortify Secure Coding Rules, Extended, JSP" in the uploaded scan (2015.4.0.0008) is older than the most recent version of this rulepack for this project version (2020.3.0.0009). Please download the current project file. Open the FPR that you intended to upload in Audit Workbench and migrate it to the downloaded FPR. Save the FPR and upload it again.""
As a workaround i am trying to update the rulepack from (2015.4.0.0008) to (2020.3.0.0009). Can anyone share the steps/wiki to follow for upgrading rulepack on the server where fortify client is installed.
Related
I have a Fortify SCA version 21.x in a linux machine, planning to upgrade the version to 22.x. But I would like to have both the versions in the same machine since I would take time to validate the working of 22.x version before uninstalling the 21.x version.
To install I have the command from the document : ./Fortify_SCA_and_Apps__linux_x64.run --mode
unattended
And it is to be noted that the below was mentioned in the document.
If you have multiple versions installed on the same system, the most recently installed version is
invoked when you run the command from the command line. Scanning source code from the Secure
Code Plugins also uses the most recently installed version of Fortify Static Code Analyzer.
So will it work if I intend to keep both the SCA installed in different locations of the same machine, then executing and validating the scans using 22.x.
&
I have scenario to be aware if SCA 21.x will work when SCA 22.x is uninstalled.
Submenu File -> New contains only "Other..." and "Customize" items.
How to correct this?
My OS is Windows 10.0.17763.107.
Old version is 10.2 with same problem.
Installed new version 10.4.2, in process of installation of Delphi Community, I have error at Roboto Font downloading:
[403] Forbidden
I pinged this address of Getit found in the registry: https://getit-104.embarcadero.com
It is not responding! Ok, changing to getit.embarcadero.com, the result is negative.
It seems that your Delphi installation hasn't finished properly. Either it was interrupted or Licence manager didn't manage to verify your Community licence properly.
You could try fixing your licence using Licence Manager that you can find inside Delphi folder. If my memory serves me correctly it is located withing BIN subfolder (don't have access to development machine at the moment to verify).
But if the installation proces itself is getting interrupted you might want to download ISO installation instead of Online installation. When installing latest version of Delphi I had to use ISO installation since Web installation kept loosing connection. I suspect my AV Software (ESET Internet Security) with integrated firewall might be the cause.
In Production, IBM MobileFirst server running with version 7.1.0.00.20180425-1124 and Project war file with version 7.1.0.00.20180425-1124.
Recent deployment of project war was deployed with 7.1.0.00.20161006-0540, unfortunately.
iOS throws below error:
{"error_description":"Client authentication failed","error":"invalid_client"}
Rolled back the deployment to avoid issues.
While investigating, there was an APAR with similar fix but the version used in the deployment doesn't include this APAR.
Question 1: If same version(7.1.0.00.20180425-1124) of MF Plugin used to build Project .war, will this issue be addressed.
Question 2: Where can I download the Eclipse Plugin of 7.1.0.00.20180425-1124?
Thanks in advance
It is not clear what steps you took to update your server. In your MobileFirst server Operations console , if you see the version as "7.1.0.00.20161006-0540" , then you should definitely update.
If that is the case, merely building a new project runtime war file in latest MobileFirst Eclipse Studio and deploying it will not help. The iFix level in the server will have to be updated too. You can use Server Config Tool or ANT scripts to update your iFix level as well to the latest while you deploy the new runtime war.
You can download the latest versions of the iFix ( Server and Studio plugin) in FixCentral.
Finally achieved by clearing out the keychain items and defaults which work light library has been internally maintaining.
So what's happening behind the scenes is the work light client is creating and maintaining some keychain items and also few user defaults. This is done for storing some information like session id's and stuff. Sometimes the data in the keychain or defaults is getting corrupted during the initial work light handshake with MFP server. In this scenario we get the above error. Once we clear them out and kill the app and launch again. the app will now behave as a new device.
As per this article,
http://www.ibm.com/developerworks/data/library/cognos/development/how_to/page565.html#download
the Cognos SDK for cognos 8 is located in folder:<cognos-directory>/sdk
This directory is not present in cognos 10. So where is the SDK component located?
The SDK is a separate component and must be downloaded and installed in addition to an existing Cognos product install. When you add it to an existing Cognos 10 installation it will create and unpack to an SDK folder under the root of the install.
Just to add to this, in case anyone finds this via search.
The SDK is now included with Cognos 11.1.X server installs. Up to this version, including 11.0.X, the SDK was a separate install.
And, the SDK works best when installed alongside the server. We have found it easier to develop using remote SSH via Visual Studio Code or running Eclipse remotely on our development Cognos servers. Both work well, and you only need to install and configure it server-side. All of your devs can then work with the one instance. If remote isn't possible, dev's will need to install and configure a local Cognos Server.
I am using Xcode 4.2.1 and I have this problem running an existing application on the iOS simulator:
svn: The path '.' appears to be part of a Subversion 1.7 or greater
working copy. Please upgrade your Subversion client to use this
working copy.
/Users/me/Library/Developer/Xcode/DerivedData/myproject-dxfzldckuqdmlrghowwkdrbgoigy/Build /Intermediates/myproject.build/Debug-iphonesimulator/MyProject.build/Script-9567AEA113C59633000AA291.sh: No Subversion revision found at /Users/me/Library/Developer/Xcode/DerivedData/myproject-dxfzldckuqdmlrghowwkdrbgoigy/Build/Intermediates/myproject.build/Debug-iphonesimulator/MyProject.build/Script-9567AEA113C59633000AA291.sh line 32.
Building revision
Command /bin/sh failed with exit code 1
I have a Subversion server 1.7.1 installed and also on the client side I upgraded to 1.7.1.
I did a svn upgrade and then I get this error in Xcode.
If I repeat the svn upgrade on the terminal I get the message Can't upgrade '...' as it is not a pre-1.7 working copy directory.
So what is wrong? How an I solve the problem?
Xcode doesn't yet support SVN 1.7. Only 1.6 is supported. In order to fix your problem, you'll need to switch to using an SVN 1.6 compatible working copy.
Since SVN 1.7 client is unable to work with 1.6 working copies at all, you'll need to remove SVN 1.7.x from your client and revert to 1.6. (Or perhaps just adjust your PATH so the SVN 1.6 tools are first.) Once 1.6 is back, delete or move aside your existing working copy and check out a fresh copy with SVN 1.6. Now Xcode should be able to work with your working copy.
Note that you can freely use SVN 1.6 client with an SVN 1.7 server. Some of the newer features won't be available, but it will work. There's no need to downgrade the server or your server-side repositories.
Keep an eye on the Xcode release notes in updates as I'm sure Apple will note when Xcode is capable of using SVN 1.7. When a 1.7 compatible release of Xcode becomes available, it should then be safe to upgrade your client to 1.7 and migrate your working copy again.
There is a post that appears to imply that you can fool XCode into using svn 1.7 client by changing your PATH and setting up a couple of soft links in strategic places. Unfortunately, the post is in Chinese. Fortunately, Google translate and the presence of UNIX commands make it possible to decrypt what the post is saying. I will try it in the next few days, and update the answer if anything useful comes out of this exercise.
EDIT: I tried the steps from the post, and it worked. Here is what I did:
Downloaded and installed svn client 1.7.2 into /opt/subversion
Added /opt/subversion/bin to my PATH in .bash_profile
Created a backup directory /Developer/usr/bin/orig.svn
Moved /Developer/usr/bin/svn* to /Developer/usr/bin/orig.svn
Ran ln -s /opt/subversion/bin/svn* /Developer/usr/bin/
After that I re-started XCode, went to Organizer, and was able to attach a working copy of a checkout created with svn 1.7.2 client. Organizer showed a green dot next to the repository, displayed a list of revisions, etc., so at this point I believe that the trick has worked.
You can download and install a binary package from http://www.wandisco.com/subversion/download#osx
The package will install to /opt/subversion while the xcode version of SVN is installed in /usr/bin. If you prepend /opt/subversion/bin to your path variable, it will be chosen instead of the xcode version.
If you don't want to mess with your path, you can just alias one version or the other. man alias for details.