Isolating JRE within an MSIX container.

TIMOTHY_MANGAN 

 

We can simply use this regex  ^SOFTWARE\\Classes\\CLSID\\(?!{CCAFEEFAC-0017-0000-0045-ABCDEFFEDCBA}) to hide all java versions except java 1.7.0.45
We can be more specific in the regex for custom use cases.

 

 

@mridulgupta 

 

I looked into your proposed fix.  The deletion marker you propose would block any java from running inside the container.  I do not believe this is what the requester wanted.

 

I believe that the requester wants to package up a version of java that will work inside the package, but to block the packaged app from access to any newer version of java that is locally deployed.  This is often necessary because newer versions of Java are not always backwards compatible, and the customer cannot get an updated application (and yet wants to prevent general use of an older and unsafer version of java).

 

This is why we target the deletion markers to all future keys of the Classes\{CAFFEEFAC- pattern, which encode the version of java into the key name.  So if the package includes up to {CCAFEEFAC-0017-0000-0045-ABCDEFFEDCBA}, which is java 1.7U45, we need to block classes keys above the 45, but also 18 and 19 ranges. 

 

mridulgupta 

 

It is interesting the area of the registry that mridulgupta is targeting in the prior reply. Traditionally we attack a subset of the Classes\{CAFFEEFAC- to solve the Java problem.  

 

Over the holidays I have worked on a different json approach, specifically for the java problem in my PSF fork that is in final testing.

 

That approach adds a different rule (JavaBlocker) that just lists the java version required, which will be simpler for customers to use.  Parameters are majorVersion, minorVerson, and updateVersion and hives and regex patterns not required.  As Java seems to be the primary need for registry blocking, this would be easier for people to understand how to use.  It just takes care of issues like whether the install was the 64- or 32- bit, or user or machine install, without having to embed that in the json.

 

I've also ported the DeletionMarker rule into my fork for consistency, although I really wish it didn't have a base hive and key and list of values, but a simpler list of values.  For general purpose use, I find the single hive/key implementation of this rule limiting.  I considered modifying this in my fork version, but opted to implement the same rule as used in the Microsoft fork for consistency.

 

I expect to release this to my GitHub fork soon, and in the next version of PsfLauncher/TMEditX shortly after that.

 

 

TIMOTHY_MANGAN 

 

MSIX Packaging Tool allows you to give a regex string for registry keys and values to avoid the overhead of adding too many entries and manually generating config.json for PSF.
SajidRavat you can use regex like ^MACHINE\\Software\\Classes\\(?!JAVAPLUGIN\.10627$)[^\\]+$ .   <modify path according to your use case>

 

Let us know if you have questions. 

I took a look at the hiding registry key fixup rule in the Microsoft branch. Technically, it should be able to do the job, but it will require a lot of manual effort to add all of the keys necessary by hand into the Json file. For a package with Java 1.6 it would be about 40 keys to type in.

SajidRavat 

There has been a new release of PSF (version 1.0.231110.2) with a way to support Deletion Markers for registries which allows hiding of specific registry keys or registry values in the virtual environment. Please try using that and let us know if that works for you.