IcedTea-Web icon indicating copy to clipboard operation
IcedTea-Web copied to clipboard

add support for deploymentruleset

Open dhirenjoshi opened this issue 3 years ago • 13 comments

dhirenjoshi avatar Aug 03 '21 21:08 dhirenjoshi

Hi Dhiren

Thank you for this contribution. I see one main problem which you need to address before we can merge this. Your Change adds 5 new dependencies to icedtea-web. This is problematic as all these dependencies will end on the classpath of each and every application launched with icedtea-web. Therefor the more dependencies icedtea-web has the bigger is the risk of conflicting dependencies with an application.

If you look at the XmlParser and the Parser class you see that so far icedtea-web is using classes included in the JRE to parse the JNLP file, which is also an XML file.

Can you change your code in such a way that it no longer requires new dependencies.

sclassen avatar Aug 05 '21 09:08 sclassen

I commented out all 5 dependencies . Looks like I can still use.

import javax.xml.bind.JAXBContext; import javax.xml.bind.JAXBException; import javax.xml.bind.Marshaller; import javax.xml.bind.Unmarshaller; import javax.xml.bind.annotation.*;

They're seemingly a part of JRE libs so for minimal impact to code, I will use JAXB if that is all right .

Thanks -Dhiren

On Thu, Aug 5, 2021 at 4:23 AM sclassen @.***> wrote:

Hi Dhiren

Thank you for this contribution. I see one main problem which you need to address before we can merge this. Your Change adds 5 new dependencies to icedtea-web. This is problematic as all these dependencies will end on the classpath of each and every application launched with icedtea-web. Therefor the more dependencies icedtea-web has the bigger is the risk of conflicting dependencies with an application.

If you look at the XmlParser and the Parser class you see that so far icedtea-web is using classes included in the JRE to parse the JNLP file, which is also an XML file.

Can you change your code in such a way that it no longer requires new dependencies.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/AdoptOpenJDK/IcedTea-Web/pull/816#issuecomment-893305896, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZX4URD5CHIHZ4KEWLP3SLT3JJ77ANCNFSM5BPU2MLQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

dhirenjoshi avatar Aug 05 '21 16:08 dhirenjoshi

JAXB has been removed in Java11.

Am 5. August 2021 18:13:19 MESZ schrieb dhirenjoshi @.***>:

I commented out all 5 dependencies .

Looks like I can still use.

import javax.xml.bind.JAXBContext;

import javax.xml.bind.JAXBException;

import javax.xml.bind.Marshaller;

import javax.xml.bind.Unmarshaller;

import javax.xml.bind.annotation.*;

They're seemingly a part of JRE libs so for minimal impact to code, I will

use JAXB if that is all right .

Thanks

-Dhiren

On Thu, Aug 5, 2021 at 4:23 AM sclassen @.***> wrote:

Hi Dhiren

Thank you for this contribution.

I see one main problem which you need to address before we can merge this.

Your Change adds 5 new dependencies to icedtea-web. This is problematic as

all these dependencies will end on the classpath of each and every

application launched with icedtea-web. Therefor the more dependencies

icedtea-web has the bigger is the risk of conflicting dependencies with an

application.

If you look at the XmlParser and the Parser class you see that so far

icedtea-web is using classes included in the JRE to parse the JNLP file,

which is also an XML file.

Can you change your code in such a way that it no longer requires new

dependencies.

You are receiving this because you authored the thread.

Reply to this email directly, view it on GitHub

https://github.com/AdoptOpenJDK/IcedTea-Web/pull/816#issuecomment-893305896,

or unsubscribe

https://github.com/notifications/unsubscribe-auth/ABZX4URD5CHIHZ4KEWLP3SLT3JJ77ANCNFSM5BPU2MLQ

.

Triage notifications on the go with GitHub Mobile for iOS

https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675

or Android

https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email

.

-- > You are receiving this because you commented.

Reply to this email directly or view it on GitHub:

https://github.com/AdoptOpenJDK/IcedTea-Web/pull/816#issuecomment-893584461

sclassen avatar Aug 05 '21 23:08 sclassen

Hi Stephen,

I removed jaxb and re submitted the code. There are no dependent XML parsers now.

-Dhiren

On Thu, Aug 5, 2021 at 6:23 PM sclassen @.***> wrote:

JAXB has been removed in Java11.

Am 5. August 2021 18:13:19 MESZ schrieb dhirenjoshi @.***>:

I commented out all 5 dependencies .

Looks like I can still use.

import javax.xml.bind.JAXBContext;

import javax.xml.bind.JAXBException;

import javax.xml.bind.Marshaller;

import javax.xml.bind.Unmarshaller;

import javax.xml.bind.annotation.*;

They're seemingly a part of JRE libs so for minimal impact to code, I will

use JAXB if that is all right .

Thanks

-Dhiren

On Thu, Aug 5, 2021 at 4:23 AM sclassen @.***> wrote:

Hi Dhiren

Thank you for this contribution.

I see one main problem which you need to address before we can merge this.

Your Change adds 5 new dependencies to icedtea-web. This is problematic as

all these dependencies will end on the classpath of each and every

application launched with icedtea-web. Therefor the more dependencies

icedtea-web has the bigger is the risk of conflicting dependencies with an

application.

If you look at the XmlParser and the Parser class you see that so far

icedtea-web is using classes included in the JRE to parse the JNLP file,

which is also an XML file.

Can you change your code in such a way that it no longer requires new

dependencies.

You are receiving this because you authored the thread.

Reply to this email directly, view it on GitHub

< https://github.com/AdoptOpenJDK/IcedTea-Web/pull/816#issuecomment-893305896 ,

or unsubscribe

< https://github.com/notifications/unsubscribe-auth/ABZX4URD5CHIHZ4KEWLP3SLT3JJ77ANCNFSM5BPU2MLQ

.

Triage notifications on the go with GitHub Mobile for iOS

< https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675

or Android

< https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email

.

-- > You are receiving this because you commented.

Reply to this email directly or view it on GitHub:

https://github.com/AdoptOpenJDK/IcedTea-Web/pull/816#issuecomment-893584461

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/AdoptOpenJDK/IcedTea-Web/pull/816#issuecomment-893886914, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZX4USFIJITVZ54QY6GJPTT3MMOPANCNFSM5BPU2MLQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

dhirenjoshi avatar Aug 12 '21 20:08 dhirenjoshi

Hi Stephen, Please let me know if I need to create another pull request for the changes as well or if the existing pull request works ? Thanks -Dhiren

On Thu, Aug 12, 2021 at 3:16 PM Dhiren Joshi @.***> wrote:

Hi Stephen,

I removed jaxb and re submitted the code. There are no dependent XML parsers now.

-Dhiren

On Thu, Aug 5, 2021 at 6:23 PM sclassen @.***> wrote:

JAXB has been removed in Java11.

Am 5. August 2021 18:13:19 MESZ schrieb dhirenjoshi @.***>:

I commented out all 5 dependencies .

Looks like I can still use.

import javax.xml.bind.JAXBContext;

import javax.xml.bind.JAXBException;

import javax.xml.bind.Marshaller;

import javax.xml.bind.Unmarshaller;

import javax.xml.bind.annotation.*;

They're seemingly a part of JRE libs so for minimal impact to code, I will

use JAXB if that is all right .

Thanks

-Dhiren

On Thu, Aug 5, 2021 at 4:23 AM sclassen @.***> wrote:

Hi Dhiren

Thank you for this contribution.

I see one main problem which you need to address before we can merge this.

Your Change adds 5 new dependencies to icedtea-web. This is problematic as

all these dependencies will end on the classpath of each and every

application launched with icedtea-web. Therefor the more dependencies

icedtea-web has the bigger is the risk of conflicting dependencies with an

application.

If you look at the XmlParser and the Parser class you see that so far

icedtea-web is using classes included in the JRE to parse the JNLP file,

which is also an XML file.

Can you change your code in such a way that it no longer requires new

dependencies.

You are receiving this because you authored the thread.

Reply to this email directly, view it on GitHub

< https://github.com/AdoptOpenJDK/IcedTea-Web/pull/816#issuecomment-893305896 ,

or unsubscribe

< https://github.com/notifications/unsubscribe-auth/ABZX4URD5CHIHZ4KEWLP3SLT3JJ77ANCNFSM5BPU2MLQ

.

Triage notifications on the go with GitHub Mobile for iOS

< https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675

or Android

< https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email

.

-- > You are receiving this because you commented.

Reply to this email directly or view it on GitHub:

https://github.com/AdoptOpenJDK/IcedTea-Web/pull/816#issuecomment-893584461

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/AdoptOpenJDK/IcedTea-Web/pull/816#issuecomment-893886914, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZX4USFIJITVZ54QY6GJPTT3MMOPANCNFSM5BPU2MLQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

dhirenjoshi avatar Aug 16 '21 15:08 dhirenjoshi

Hi Dhiren

I finally found some time to look into the code. I took the liberty to delete a lot of code which was not reachable. Also many of your comments and log statements.

I hope you are not intrigued by this. If you want I can always restore your original code.

Regarding the Ruleset implementation: 1) I am not sure how you handle the case with no ruleset. This should still be the default case. From my understanding of the code currently no ruleset -> empty list of rules -> empty list of URLs -> nothing is allowed. 2) The current implementation is creating a logical disjunction with the whitelist from the deployment properties. But in most cases this white list will be empty and thus any URL will pass it. Maybe a logical conjunction over the two whitelists would be the correct approach. 3) Also I am not sure why you added a configuration option since the Oracle specification is very clear on where the file need to be located on the file system (see https://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/deployment_rules.html#package)

There are also some implementation specific things to look at but let us first tackle the conceptual points mentioned above.

sclassen avatar Aug 30 '21 22:08 sclassen

Hi Stephen, Thanks for your feed back and suggestions. I am fine with all the changes you have done.

Regarding the Ruleset implementation: Here are answers to some of your questions. 1) I am not sure how you handle the case with no ruleset. This should still be the default case. From my understanding of the code currently no ruleset -> empty list of rules -> empty list of URLs -> nothing is allowed.

Yes sorry my bad on this one.. Change the current method in class UrlDeploymentRulesSetUtils to this.

public static List<Rule> loadRuleSetFromConfiguration(final String deploymentRuleSetJarPath) { List<Rule> rulesSetList=null; if (!isRuleSetInitialized) { initRulesSet(deploymentRuleSetJarPath); } rulesSetList=rulesSet.getRuleSet();

return rulesSetList;
 }

Now the explaination,

In ResourceHandler.java

/**
 * @author DJ 03-02-2021
 * Validates the resource URL with the deploymentRuleSet jar file
 */
private boolean validateWithDeploymentRuleSet() {
    final URL url = resource.getLocation();
    Assert.requireNonNull(url, "url");

    // Validate with whitelist specified in DeploymentRuleSet.jar

localhost is considered valid. final boolean found = UrlDeploymentRulesSetUtils.isUrlInDeploymentRuleSetlist(url); return found; }

Mainly in ResourceHandler.java, I modified the original call validateWithWhitelist() found=validateWithDeploymentRuleSet() ; existed. I added an extra. if not found ..verify whitelisting against DeploymentRuleSet . If the URL is found within the Deployment Rule parsed URL's , its whitelisted. If not found ..it follows default path of what the original ITW followed.

Now if no DeploymentRulelset.. then no URL's are loaded with whitelisted URLS and it continues on default behaviour of original ITW otherwise if URL is parsed and added to List in DeploymentURLs, it will check against that and if found found =true. IF found is already true.. then no extra whitelisting is needed since the URL is already whitelisted and DeplyomentRuleSet URLs do not even need to be checked against.

if (!found) {
    LOG.debug("----------------------BEGIN DEPLOYMENT RULESET

CALL------------------------------------------", found); LOG.debug("Resource URL call inside (!found) before calling found=validateWithDeploymentRuleSet()", found); found=validateWithDeploymentRuleSet() ; LOG.debug("Resource URL call inside (!found) after calling found=validateWithDeploymentRuleSet()", found); }

private void validateWithWhitelist() { final URL url = resource.getLocation(); Assert.requireNonNull(url, "url");

    // Validate with whitelist specified in deployment.properties.

localhost is considered valid. //commented out by DJ -final key word so that URL can be checked against whitelist as well as deploymentRuleset. /final/ boolean found = UrlWhiteListUtils.isUrlInApplicationUrlWhitelist(url); //If not found in the serverWhitelisting , check in DeploymentRuleSet.jar file. LOG.debug("Resource URL not In Whitelist: {} found before calling Deployment rule set", found); if (!found) { LOG.debug("----------------------BEGIN DEPLOYMENT RULESET CALL------------------------------------------", found); LOG.debug("Resource URL call inside (!found) before calling found=validateWithDeploymentRuleSet()", found); found=validateWithDeploymentRuleSet() ; LOG.debug("Resource URL call inside (!found) after calling found=validateWithDeploymentRuleSet()", found); } LOG.debug("Resource URL not In Whitelist: {} found after calling Deployment rule set", found); if (!found) { BasicExceptionDialog.show(new SecurityException(Translator.R("SWPInvalidURL") + ": " + url)); LOG.error("Resource URL not In Whitelist: {}", resource.getLocation()); JNLPRuntime.exit(-1); } }

At this point if this method is getting called, the whitelisting request is still returning false and so it invokes deplyment ruleset to check if the URLis deploymentruleset so it can be whitelisted. If ArrayList is empty, it returns false otherwise it gets a match returns back true.

public static boolean isUrlInDeploymentRuleSetUrl(final URL url, final

List<String> deploymentRuleSetList) { Assert.requireNonNull(url, "url"); Assert.requireNonNull(deploymentRuleSetList, "whiteList");

    if (deploymentRuleSetList.isEmpty()) {
        return false; // empty deploymentRuleSetList == allow none.

Nothing is whitelisted }

    return deploymentRuleSetList.stream().anyMatch(wlEntry ->

wlEntry.matches(url.getHost())); } 2) The current implementation is creating a logical disjunction with the whitelist from the deployment properties. But in most cases this white list will be empty and thus any URL will pass it. Maybe a logical conjunction over the two whitelists would be the correct approach. I am not sure .Can you please elaborate on this.

Also I am not sure why you added a configuration option since the Oracle specification is very clear on where the file need to be located on the file system (see https://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/deployment_rules.html#package ) I was not sure where in ITW the properties of the DeploymentRuleSet was defined .Since ITW can be installed in any directory ,even though DeplymentRuleSet gets installed when Oracle Java is installed. If there already exist a value that can be re-used, we can remove this config and reuse the same ITW value from config.

Thanks -Dhiren

On Mon, Aug 30, 2021 at 5:22 PM sclassen @.***> wrote:

Hi Dhiren

I finally found some time to look into the code. I took the liberty to delete a lot of code which was not reachable. Also many of your comments and log statements.

I hope you are not intrigued by this. If you want I can always restore your original code.

Regarding the Ruleset implementation: 1) I am not sure how you handle the case with no ruleset. This should still be the default case. From my understanding of the code currently no ruleset -> empty list of rules -> empty list of URLs -> nothing is allowed. 2) The current implementation is creating a logical disjunction with the whitelist from the deployment properties. But in most cases this white list will be empty and thus any URL will pass it. Maybe a logical conjunction over the two whitelists would be the correct approach. 3) Also I am not sure why you added a configuration option since the Oracle specification is very clear on where the file need to be located on the file system (see https://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/deployment_rules.html#package )

There are also some implementation specific things to look at but let us first tackle the conceptual points mentioned above.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/AdoptOpenJDK/IcedTea-Web/pull/816#issuecomment-908745038, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZX4UQMPPACEOJK2YJ4273T7QACDANCNFSM5BPU2MLQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

dhirenjoshi avatar Aug 31 '21 17:08 dhirenjoshi

Hi Dhiren, I read most of the specification from https://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/deployment_rules.html

There are still a few crucial parts missing in the implementation. I can support you in implementing this but I cannot do all the remaining work by myself.

What are your plans with this feature? Do you have the time to continue on this?

sclassen avatar Sep 10 '21 14:09 sclassen

I can help with this . I think at most a week's effort will be needed. Mostly its String compares with wild cards , https that has been left. It would greatly help if you could highlight the features that you think are crucial . The feature of the java-console option is not something I am comfortable implementing as that could violate Oracle patent of User interface . Other than that, the rest , I can help with coding. Would you prefer, I pull down your latest codebase and work with that where you have changed the file names Xml... and work with that version ?

Thanks -Dhiren

On Fri, Sep 10, 2021 at 9:21 AM sclassen @.***> wrote:

Hi Dhiren, I read most of the specification from https://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/deployment_rules.html

There are still a few crucial parts missing in the implementation. I can support you in implementing this but I cannot do all the remaining work by myself.

What are your plans with this feature? Do you have the time to continue on this?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/AdoptOpenJDK/IcedTea-Web/pull/816#issuecomment-916942930, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZX4UV7HMV4APAXIJO5IZ3UBIH7ZANCNFSM5BPU2MLQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

dhirenjoshi avatar Sep 10 '21 18:09 dhirenjoshi

OK, so let's do this.

I was thinking a bit and I would like to propose the following:

  • I will open issues for the things which need improvement or are missing. Mainly to avoid a big chaos in this PR.
  • All code should go into the branch dhirenjoshi:deploymentruleset-add
  • I will also commit code to this branch but feel free to change all my code. My code is not perfect and I have absolutely no problems with you changing my code

But before we start one last question: When reading the specification of the deploymentruleset I understand it that you define rules for RIA (rich internet applications) so the rules apply to the entire application and not the single resources they are composed of. So in my understanding if I add a rule for host.example.com then any RIA at this URL is allowed to run. And they can also download resources from opensource.someSite.net without me adding this second address to the ruleset.

So my question is: Can the ruleset be applied as a whitelist to the resources or should it be applied earlier (i.e. directly after parsing the JNLP file)

sclassen avatar Sep 13 '21 09:09 sclassen

Stephen, I looked into details about the RIA resources and it looks like how it is implemented currently is the way the specs expect it. From the oracle doc specs. Rules for all artifacts of RIA are required to be in the ruleset failing which the URL becomes inaccessible.

rule

Identifies a RIA or set of RIAs and the action taken. A rule element contains one id and one action element. Rules are processed sequentially until a rule is matched. When a match is found, no further rules are processed. If no rule is matched, then default processing is used, and any relevant security prompts or warnings are shown. The valid child elements are id and action.

*When a RIA has artifacts that are signed with a different certificate or that are in a different location, ensure that the rule set contains rules for all artifacts of the RIA. *For mixed code cases, which are calls between JAR files with different permission levels or calls from JavaScript code to privileged Java code, see Set Up Rules for Mixed Code https://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/deployment_rules.html#mixedcode for additional information.

The valid parent element is ruleset. The valid child elements are id and action. So based on the bold underlined specs , I think the rule set is defined at resource/artifact level. Thoughts.. ? Thanks -Dhiren

On Mon, Sep 13, 2021 at 4:36 AM sclassen @.***> wrote:

OK, so let's do this.

I was thinking a bit and I would like to propose the following:

  • I will open issues for the things which need improvement or are missing. Mainly to avoid a big chaos in this PR.
  • All code should go into the branch dhirenjoshi:deploymentruleset-add
  • I will also commit code to this branch but feel free to change all my code. My code is not perfect and I have absolutely no problems with you changing my code

But before we start one last question: When reading the specification of the deploymentruleset I understand it that you define rules for RIA (rich internet applications) so the rules apply to the entire application and not the single resources they are composed of. So in my understanding if I add a rule for host.example.com then any RIA at this URL is allowed to run. And they can also download resources from opensource.someSite.net without me adding this second address to the ruleset.

So my question is: Can the ruleset be applied as a whitelist to the resources or should it be applied earlier (i.e. directly after parsing the JNLP file)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/AdoptOpenJDK/IcedTea-Web/pull/816#issuecomment-918013407, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZX4UUIF4PXCGQF6OXVMOTUBXAZLANCNFSM5BPU2MLQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

dhirenjoshi avatar Sep 13 '21 15:09 dhirenjoshi

Hi Stephen, Appreciate any feedback you have on my previous email about discussion on the RIA whitelisting? What are your thoughts and are you putting new features that need to be addressed in ITW .

Thanks -Dhiren

On Mon, Sep 13, 2021, 10:31 AM Dhiren Joshi @.***> wrote:

Stephen, I looked into details about the RIA resources and it looks like how it is implemented currently is the way the specs expect it. From the oracle doc specs. Rules for all artifacts of RIA are required to be in the ruleset failing which the URL becomes inaccessible.

rule

Identifies a RIA or set of RIAs and the action taken. A rule element contains one id and one action element. Rules are processed sequentially until a rule is matched. When a match is found, no further rules are processed. If no rule is matched, then default processing is used, and any relevant security prompts or warnings are shown. The valid child elements are id and action.

*When a RIA has artifacts that are signed with a different certificate or that are in a different location, ensure that the rule set contains rules for all artifacts of the RIA. *For mixed code cases, which are calls between JAR files with different permission levels or calls from JavaScript code to privileged Java code, see Set Up Rules for Mixed Code https://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/deployment_rules.html#mixedcode for additional information.

The valid parent element is ruleset. The valid child elements are id and action. So based on the bold underlined specs , I think the rule set is defined at resource/artifact level. Thoughts.. ? Thanks -Dhiren

On Mon, Sep 13, 2021 at 4:36 AM sclassen @.***> wrote:

OK, so let's do this.

I was thinking a bit and I would like to propose the following:

  • I will open issues for the things which need improvement or are missing. Mainly to avoid a big chaos in this PR.
  • All code should go into the branch dhirenjoshi:deploymentruleset-add
  • I will also commit code to this branch but feel free to change all my code. My code is not perfect and I have absolutely no problems with you changing my code

But before we start one last question: When reading the specification of the deploymentruleset I understand it that you define rules for RIA (rich internet applications) so the rules apply to the entire application and not the single resources they are composed of. So in my understanding if I add a rule for host.example.com then any RIA at this URL is allowed to run. And they can also download resources from opensource.someSite.net without me adding this second address to the ruleset.

So my question is: Can the ruleset be applied as a whitelist to the resources or should it be applied earlier (i.e. directly after parsing the JNLP file)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/AdoptOpenJDK/IcedTea-Web/pull/816#issuecomment-918013407, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZX4UUIF4PXCGQF6OXVMOTUBXAZLANCNFSM5BPU2MLQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

dhirenjoshi avatar Sep 30 '21 18:09 dhirenjoshi

@dhirenjoshi see #830

sclassen avatar Oct 04 '21 20:10 sclassen