I want to collect some buggy files.
So, I found data-set that present which file has a bug.
In data set, document said that Tomcat,6.0.389418,org.apache.jasper.compiler.Compiler file has a bug
In order to get bug file, i visit apache svn repository. And I found archive tomcat version 6_0_38 (http://svn.apache.org/repos/asf/tomcat/archive/tc6.0.x/tags/TOMCAT_6_0_38)
But I cant get file more detail version (6.0.389418) there is only 6_0_38
Can I think of two versions as the same?
Thank you.
Most importantly, you should know that Tomcat 6 has seen its end of life in December 2016, and the latest version that I can find in the archives is 6.0.53.
Based on this alone: Upgrade! First to the latest version in the 6.0 branch, then to a version that actually will continue to get security fixes. I've never seen any problems when upgrading within the same major version - the tomcat developers do a great job keeping their upgrades compatible.
And last, to the letters of your question instead of the spirit: The third digit of Tomcat version numbers is counting up, one by one. There is no 6.0.389418. As Tomcat uses Subversion, and subversion counts up the commits one by one, you might be lucky to find something around commit #389418 or #9418. Note: I've not even looked at their SVN to check if these are legitimate commits in the time that you're referring to (not even what the current commit is).
Eh, it might be quite hard to really nail this build number, but there is also a good chance this is a build you are asking for. Read for explanation.
You are asking for version: 6.0.389418
If you look into this file:
https://svn.apache.org/repos/asf/tomcat/archive/tc6.0.x/tags/TOMCAT_6_0_38/dist.xml
You can learn how build number is being built:
<property name="version.number" value="${version.major}.${version.minor}.${version.build}.${version.patch}"/>
values are taken from:
https://svn.apache.org/repos/asf/tomcat/archive/tc6.0.x/tags/TOMCAT_6_0_38/build.properties.default
# ----- Version Control Flags -----
version.major=6
version.minor=0
version.build=38
version.patch=0
version.suffix=
So the missing part of your version is 9418 which is should correspond to ${version.build} or (more unlikely) to ${version.patch}
In either case it might be not unambiguous, because often there is a build script used which performs multiple actions and as a result, appends its own version at the end of real package. I'd lean towards this explanation, because if this were to be a patch number, there would be some /patches directory in SVN, which I don't see in any other directories for more recent development.
But then, there is:
https://svn.apache.org/repos/asf/tomcat/archive/tc6.0.x/tags/TOMCAT_6_0_38/bin/version.sh -> running function from:
https://svn.apache.org/repos/asf/tomcat/archive/tc6.0.x/tags/TOMCAT_6_0_38/bin/catalina.sh
elif [ "$1" = "version" ] ; then
"$_RUNJAVA" \
-classpath "$CATALINA_HOME/lib/catalina.jar" \
org.apache.catalina.util.ServerInfo
else
Try to download it and run ./bin/version.sh
Related
In order to patch RedHat 7 machines to version 7.9, I've created an RPM repository with RPMs extracted from a DVD.iso file of the patch (example source guide), and updated said machines using yum.
The patch has succeeded with many of the machines (RHEL 7.7 only), but the rest (7.0, 7.2 and some 7.7 as well) have failed the with the following error:
Error: requested datatype filelists not available
I've also tried to gradualize the process and patch the 7.0 and 7.2 ones to 7.7 first by the same process, but yielded the same result. I've made sure I got each and every file in the Packages folder.
It is rather puzzling for me that some succeed and some fail, especially those with the same version. But I'm assuming they were created differently as I don't have the information to say otherwise. So my best direction would be to go by the error.
In this github post, lr1980 says:
https://blog.packagecloud.io/eng/2015/07/20/yum-repository-internals/
this means the "filelists.xml.gz" is missing on repo => it's a packager.io problem
Indeed, browsing my repository's repodata folder reveals only other.xml.gz and primary.xml.gz files, which are also the only files pointed to in the repomd.xml.
I've tried uploading the filelists.xml.gz file from the dvd.iso and reindexing, but it gets removed (admittedly am not familiar with this area of knowledge.. at all). What does "it's a packager.io problem" mean?
How can I force the repo to have such a file, assuming that's what I need? Or what can I do to solve this issue otherwise?
Many thanks
We've got OpenSSL 1.1.1d installed on a windows server 64 Bit running Apache 2.4.*. Everything was working fine until recentlly (Jan 2020) when our daily PCI scan failed with the following synopsis: The remote service is affected by Multiple Vulnerabilities. Obviously the natural thing for me to do was to upgrade to the most recent version of OpenSSL and when I checked https://www.openssl.org/ I found that 1.1.1d is the latest version, I still reinstalled it just to be safe. This did not change anything, the Scan still failed.
The Scan report had a long paragraph at the bottom giving more details about the impact, this text caught my attention...
*"OpenSSL versions 1.1.1, 1.1.0 and 1.0.2 are affected by this issue. Due to the limited scope of affected deployments this has been assessed as low severity and therefore we are not creating new releases at this time".*
Can anyone out there help me understand what I would need to do to stop this failure? I've had a look around on the internet and no one is reporting the issue in the same context as me. Please help!
UPDATE TO QUESTION - ADDED THE FULL REFERENCED PARAGRAPH
Impact
The version of tested product installed on the remote host is prior to tested version. It is, therefore, affected by the following vulnerabilities : - Normally in OpenSSL EC groups always have a co-factor present and this is used in side channel resistant code paths. However, in some cases, it is possible to construct a group using explicit parameters (instead of using a named curve). In those cases it is possible that such a group does not have the cofactor present. This can occur even where all the parameters match a known named curve. If such a curve is used then OpenSSL falls back to non-side channel resistant code paths which may result in full key recovery during an ECDSA signature operation. In order to be vulnerable an attacker would have to have the ability to time the creation of a large number of signatures where explicit parameters with no co-factor present are in use by an application using libcrypto. For the avoidance of doubt libssl is not vulnerable because explicit parameters are never used. OpenSSL versions 1.1.1, 1.1.0 and 1.0.2 are affected by this issue. (CVE-2019-1547) - OpenSSL 1.1.1 introduced a rewritten random number generator (RNG). This was intended to include protection in the event of a fork() system call in order to ensure that the parent and child processes did not share the same RNG state. However this protection was not being used in the default case. A partial mitigation for this issue is that the output from a high precision timer is mixed into the RNG state so the likelihood of a parent and child process sharing state is significantly reduced. If an application already calls OPENSSL_init_crypto() explicitly using OPENSSL_INIT_ATFORK then this problem does not occur at all. OpenSSL version 1.1.1 is affected by this issue. (CVE-2019-1549) - OpenSSL has internal defaults for a directory tree where it can find a configuration file as well as certificates used for verification in TLS. This directory is most commonly referred to as OPENSSLDIR, and is configurable with the --prefix / --openssldir configuration options. For OpenSSL versions 1.1.0 and 1.1.1, the mingw configuration targets assume that resulting programs and libraries are installed in a Unix-like environment and the default prefix for program installation as well as for OPENSSLDIR should be '/usr/local'. However, mingw programs are Windows programs, and as such, find themselves looking at sub-directories of 'C:/usr/local', which may be world writable, which enables untrusted users to modify OpenSSL's default configuration, insert CA certificates, modify (or even replace) existing engine modules, etc. For OpenSSL 1.0.2, '/usr/local/ssl' is used as default for OPENSSLDIR on all Unix and Windows targets, including Visual C builds. However, some build instructions for the diverse Windows targets on 1.0.2 encourage you to specify your own --prefix. OpenSSL versions 1.1.1, 1.1.0 and 1.0.2 are affected by this issue. Due to the limited scope of affected deployments this has been assessed as low severity and therefore we are not creating new releases at this time. (CVE-2019-1552) Note that SecurityMetrics has not tested for these issues but has instead relied only on the application's self-reported version number. See also : http://www.nessus.org/u?c46dca59 https://www.openssl.org/news/secadv/20190910.txt https://www.openssl.org/news/secadv/20190730.txt
It's a false positive. You need to file a dispute with the vendor, showing them that version 1.1.1d does not have the vulnerability found in the other versions. All PCI scan vendors have a process to dispute false positives. If they agree with the results of your dispute, they will remove the vulnerability from your report. They should resolve this issue for you quickly. Send them https://www.openssl.org/news/secadv/20190910.txt, and evidence of the actual version that you have.
I'm now having to answer my own question thanks to the responses by Kapish M and Rodrigo M who gave me crucial information and led me on the right path.
As it turns out, the OpenSSL version installed on a windows server does not supersede version of OpenSSL which is part of the Apache bundle installed as part of XAMPP. The Vulnerability Scanner scans against OpenSSL which is inside Apache (or possibly both but definitely the apache one).
The OpenSSL I had installed on the server version 1.1.1d is completely separate from the one which is part of the XAMPP package (in my case 1.1.1c). The issue I found was that despite having the most up to date version of Apache 2.2.41, the version of OpenSSL shipped with it is not the latest version of OpenSSL and there's no officially documented way of updating just the OpenSSL within the XAMPP package. In fact, the official XAMPP website does say that they do not yet have the 1.1.1d ready for windows, except for Linux (correct at the time of this answer) https://www.apachefriends.org/blog/new_xampp_20191227.html explicitely says OpenSSL 1.1.1d (UNIX only).
Below is what I did to resolve my issue after having had a better understanding thanks to the responses received. I'm still not sure if my approach is safe as this isn't my area of expertise but it definitely got my PCI-Scan to pass.
Installd the latest version of OpenSSL on the Sever
Navigate to the location of the Binaries folder i.e. YourDrive:\Program Files\OpenSSL-Win64\bin
Copy the following files (credit to Edmoncuaft for this list of files)
libcrypto-1_1.dll
libssl-1_1.dll
openssl.exe
Navigate to your apache binaries folder
YourDrive:xampp\apache\bin
[VERY IMPORTANT] Create backup copies of the 3 files mention in step 3 in case you need to revert.
Stop the Apache Server
Copy the 3 files from YourDrive:\Program Files\OpenSSL-Win64\bin to YourDrive:xampp\apache\bin
(Re)Start the Apache Server
These are the steps I followed and when we run the PCI Scan again, it passed with no Vulnerabilities!
I hope this is useful to someone else out there.
I am trying to move Trac data from an old server at my workplace to a new server but I am stuck on the last step of migrating our wiki data. We use Trac 1.0.1 and are trying to update to Trac 1.2. The part I am stuck on is dumping the wiki. I have been trying to use
trac-admin wiki dump
This works for my tests but when I try to use it on the actual wiki I get an error saying that the filename is too long. This happens because the hierarchical files try to make a filename like this
child1%2child2%2child3%2child4%2child5%2.....
instead of
child1/child2/child3/child4/child5/.....
Since linux is seeing this path as one name it throws an error saying that the file name is too long. Has anyone ran into this problem before and have a solution for it????
I have also tried making a hotcopy of trac and transfering it but this doesnt work either. If anyone knows where the wikis are stored and how to copy that from our old server to our new server that would be the most optimal solution I am looking for
There is allready another Thread about this which isn't really answered:
How to Convert a Maxmind .MMDB to .DAT?
Here Greg Oschwald, working at Maxmind, said that "The Legacy GeoIP builds (.dat) are not going away in the near future". Yeah, but the future is now, and they are going away on 1. April 2018 which is in a month ;) I really liked my current Apache-Configuration (Debian) using mod_geoip2 and GeoIP .dat-Databases. Works like a charm. So it's kind of anoying to change everything now. Especialy because there is no native Apache-Module like mod-geoip2 to use, but I have to build a module from source, install libraries and mess with my whole apache-config to enable apxs. And I don't have an automatic Update of the new module by repository but have to update it manually with new libraries and new tarballs when they are available. This is not very convenient.
Well, I could download the CSV-release, Add the IP-Ranges with Maxminds provided CSV-Converter (https://github.com/maxmind/geoip2-csv-converter/releases) write a script which transforms the bunch of csv-Files into a single "Legacy-Like" csv-File and transform this with the Debian Program (https://github.com/dankamongmen/sprezzos-world/blob/master/packaging/geoip/debian/src/geoip-csv-to-dat.cpp) to a .dat File. >Maybe< this could work for some time. But it's very ugly. Isn't there a better solution?
If not: Will there be a native Apache Module in the Debian Repository which removes the "build/install it yourself" part? Then I would have no issue with the new format.
Greetings daily
I would like to run a local Monticello HTTP repository at work, so that we can share code easily among colleagues.
Is there a way to run something similar to SmalltalkHub privately?
EDIT:
I have tried all the options here and neither of them seems to work smoothly. Let me recap the options:
1) WebDAV on Apache, following Stuart. I have tried it, following some online guides. My current dav.conf looks like this:
DavLockDB /tmp/DavLock
Alias /pharo /opt/data/pharo
<Location /pharo>
Order Allow,Deny
Allow from all
Options Indexes MultiViews
Dav On
AuthType None
</Location>
I worked for a few days. Then suddenly I am not able to read new versions of a certain package. Whenever I write a version in an image and read it in another one, I get an exception ZnInvalidUTF8. I am not sure why, it may be that WebDAV has issues listing too many files?
2) Setting up my FTP. It seems to work, but when I try to set this repository as a remote in the versionner I get MCFtpRepository doesNotUnderstnd: #koRemote
3) SqueakSource3, following Tobias. I have tried running the two Gofer commands in both Pharo2 and Pharo3. In Pharo2 it does not load at all. In Pharo3, more or less everything works. I had to fix a few errors due to deprecated or removed messages, but in the end I am able to create projects and write to them.
The problem arises when I read. Apparently SS3 keeps some kind of internal cache. The result is that the list of packages I see on the project page is different from the list of packages that the client gets. The difference seems to be that the client requires a short version of the page, like http://localhost:8080/ss/MyProject/?C=M;O%3DD, and the results there are consistently less than in the full page http://localhost:8080/ss/MyProject.
Moreover, even on the project page, the list of versions remains cached until I navigate on a different project.
4) SmallTalkHub, following Sean. I have tried both using images from the INRIA server and images suggested from the Pharo-VM-loader (they may be the same).
I had to install Seaside again, since there was no ZnZincAdaptor in the downloaded image. I am now able to start SmallTalkHub, but as soon as I try to register a user, I get an error MessageNotUnderstood: receiver of "new" is nil. I am not able to track where this error comes from (is there a way to open a server-side debugger instead of returing 500 in Seaside?).
After this error, I can see a user both in mongodb and in the interface, but I am not able to login.
5) Git using filetree, as suggested by Kylon. This would prevent me from using MetaCello to handle dependencies and looks even more compelx than the other options.
At this point I am at a loss. :-( If I want to use Pharo, I will need to be able to collaborate with my colleagues. Using open source repositories is not an option, at least right now.
Is there a simple, tried and tested way to set up such a repository?
SqueakSource3 or SmallTalkHub would be even better, thanks to their user interfaces, but I really need at least basic collboration. Having an option that can run on a headless server would also be a big plus, as if this becomes a tool we use, it will not be doable to host the repository on my laptop.
Per this thread on the Pharo Dev mailing list:
Setting up the Server:
Download a SmalltalkHub image (https://ci.inria.fr/pharo-contribution/job/SmalltalkHub/)
Install mongodb on your computer (for Debian: apt-get install mongodb)
Launch the SmalltalkHub image
Evaluate: ZnZincServerAdaptor startOn: 8080
Visit http://localhost:8080/tools/hub, create an account and a project
In addition to Sean's answer - if you just want a Metacello repository, and don't necessarily need the full SmalltalkHub stuff, then you just need a WebDav server. Apache will work fine, and I've even used Confluence's WebDAV support (with some tweaking) successfully in the past.
In addition to the other answers:
Just storing your versions in DropBox work very well!
You can also install SqueakSource3 (like SmalltalkHub, doesn't need MongoDB):
Gofer new
url:'http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main';
package: 'ConfigurationOfSeaside3';
load.
((Smalltalk at: #ConfigurationOfSeaside3) project version: #stable) load.
Gofer new
url:'http://www.squeaksource.com/MetacelloRepository';
package: 'ConfigurationOfSqueakSource';
load.
((Smalltalk at: #ConfigurationOfSqueakSource) project version: #bleedingEdge) load: #('All').
Then start your Adaptor (eg ZnZincServerAdaptor startOn: 8080) and goto http://localhost:8080/instalSS
Another way is go down the popular route of Git. I am using Github for my projects and it works great while Git itself works very well locally too. So if are already familiar with Git then its a very good choice
You can find more information here https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSuccessfulBuild/artifact/GitAndPharo/GitAndPharo.pier.html
Sorry about the bad smalltalkhub experience. I have made some fixes to the configuration, and need to check if that is enough