add support for deploymentruleset #816
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
sclassen
changed the title
|
Hi Dhiren Thank you for this contribution. If you look at the Can you change your code in such a way that it no longer requires new dependencies. |
|
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
<#816 (comment)>,
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>
.
|
|
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
> <#816 (comment)>,
> 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:
#816 (comment)
|
Removed reference to jaxb . Only plain XML parsing is being done now.
|
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
>
>> <
#816 (comment)
>,
>
>> 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:
>
>
#816 (comment)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#816 (comment)>,
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>
.
|
|
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
> >
> >> <
> #816 (comment)
> >,
> >
> >> 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:
> >
> >
> #816 (comment)
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <#816 (comment)>,
> 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>
> .
>
|
sclassen
force-pushed
the
deploymentruleset-add
branch
from
456a30e
to
c5f641b
Compare
|
Hi Dhiren I finally found some time to look into the code. I hope you are not intrigued by this. If you want I can always restore your original code. Regarding the Ruleset implementation: There are also some implementation specific things to look at but let us first tackle the conceptual points mentioned above. |
|
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.
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
)
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
<#816 (comment)>,
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>.
|
|
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. What are your plans with this feature? Do you have the time to continue on this? |
|
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
<#816 (comment)>,
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>.
|
|
OK, so let's do this. I was thinking a bit and I would like to propose the following:
But before we start one last question: 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) |
|
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
<#816 (comment)>,
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>.
|
|
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
> <#816 (comment)>,
> 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 see #830 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.